Six Supplier Breaches in One Week, and ShinyHunters Is in Two of Them. The Metabase Bug That Took ShipMonk Was Exploited Five Days Before CISA Listed It.
- Patrick Duggan
- 2 hours ago
- 5 min read
Six organisations disclosed breaches this week and not one of them was breached. Their suppliers were.
Listed separately they read as an unlucky week. Put the dates and the mechanisms side by side and two things fall out: the same crew is behind at least two of them, and one of the entry points is a vulnerability we wrote about on Tuesday — exploited five days before CISA got around to cataloguing it.
The week
Trezor — 13,689 customers exposed. Not through Trezor. Through ShipMonk, a shipping provider, which was breached on August 6 through a vulnerability in Metabase, a third-party analytics platform. So: a hardware-wallet company's customers were exposed by their fulfilment partner's business-intelligence tool. 11,742 had name, email, phone and full shipping address taken; 1,947 had name, city and email. Everyone who ordered between May 10 and August 8.
Read that impact list again if you sell hardware wallets. It is a target package for physical attacks — names and home addresses of people who verifiably own cryptocurrency hardware.
RingCentral — 1.6 million accounts. ShinyHunters claimed it, said they got in by voice-phishing an employee out of their password, claimed 623 GB. RingCentral did not pay. The data was dumped on August 14. The same leak site now also lists EY and Brinks Home.
Beacon CRM — the entire customer database of a platform serving more than 1,000 UK charities. Root cause: an AWS access key exposed in publicly accessible JavaScript build artifacts on their own website. First malicious activity at 01:20:16 UTC on July 27. The attacker held access for one hour and twenty-seven minutes and exported the whole database plus file attachments — not a subset. Supporter names, phone numbers, emails, postal addresses.
Shell is investigating a potential incident after Clop data-theft claims. The Scottish prosecution service had staff data exposed through a supplier. The French tax authority admitted a data heist after a criminal advertised two million records.
Six disclosures. Six different front doors, none of them belonging to the organisation whose customers got hurt.
The connection nobody has drawn
ShinyHunters is in at least two of these. They claimed RingCentral outright. And ShipMonk — the shipping provider whose breach exposed Trezor's customers — has also received extortion emails from ShinyHunters.
That is the same crew arriving through two completely different doors in the same week: a phone call to a RingCentral employee, and a software vulnerability at a logistics provider.
We keep a standing profile on them, and this is exactly the shape it describes — a data-theft and extortion operation whose defining move is breaching the platform rather than the target, then monetising everyone downstream. They do not need a technique. They need a supplier with a customer list.
The part that makes this our beat
ShipMonk was breached through Metabase, on August 6.
We wrote about Metabase on Tuesday. It was one of exactly three CVEs CISA added to the Known Exploited Vulnerabilities catalog on August 11 — CVE-2026-72898, with a three-day federal remediation deadline of August 14. At the time we noted it had a single public repository claiming a proof-of-concept, created August 12.
So the sequence is:
August 6 — attackers exploit Metabase at ShipMonk and take order data for 13,689 Trezor customers. August 11 — CISA adds the Metabase CVE to KEV, five days later. August 12 — the first public PoC repository appears. August 14 — the federal deadline lands.
The catalogue is not early warning. It is a record of things that have already happened to someone. By the time CVE-2026-72898 became a federal must-patch item, it had already cost a hardware-wallet company its customer address book — and that victim was not a federal agency and would never have been reading KEV anyway.
This is the weaponization-latency measurement we run, arriving with a named victim attached. Usually we can only show the gap between exploitation and cataloguing as a distribution. Here it has a face.
Four mechanisms, one lesson
Look at how these entries were made:
A phone call to an employee. A vulnerability in a third-party analytics tool used by a shipping company. An AWS key left in front-end JavaScript by a build process. And whatever Clop is doing to Shell.
There is no common technical control. No patch stops all four. No EDR, no WAF, no MFA rollout covers a supplier's BI tool and your own build pipeline and a vishing call.
What they share is position. Every one of these organisations held other people's data because a business relationship required it — fulfilment, telephony, donor management, tax administration. The attacker did not pick them for their security posture. They picked them for their customer list.
That is the uncomfortable reframe. Your third-party risk assessment asks whether a supplier is secure. The better question is how many of your customers are in their database, and what happens to those people if it all leaves at once — because at Beacon that took eighty-seven minutes, and at ShipMonk it arrived through a piece of software Trezor had never heard of and had no relationship with.
What to actually do
Inventory by data, not by contract. Most third-party registers are lists of vendors with a risk score. The useful list is: for each supplier, exactly which of my customers' fields do they hold, and how many people. That list tells you what a disclosure email will have to say, which is the only thing that matters on the day.
Ask suppliers what their suppliers run. Trezor's exposure came through ShipMonk's Metabase. Two hops. A questionnaire that stops at your direct vendor cannot see it.
Scan your own build artifacts for credentials. The Beacon key was in public JavaScript, which means it was reachable by anyone who viewed source, and it stayed reachable long enough to be found and used. This is a five-minute check against your own production bundle and almost nobody runs it as a standing control.
Assume the vishing call is coming. RingCentral is a telephony company and ShinyHunters got a password out of an employee by phone. If that works there, it works at you.
And if you sell anything that signals wealth — hardware wallets especially — treat your fulfilment partner's security as a physical safety dependency for your customers, not a data-protection one.
Credit and caveats
None of this is our discovery. The Beacon timeline is their CTO's disclosure, the Trezor numbers are Trezor's and ShipMonk's, the RingCentral attribution is ShinyHunters' own claim reported by others. What we are adding is the arrangement: the shared actor, the two-hop Metabase path, and the exploitation-before-cataloguing gap we already had a measurement for.
One honest limit — the ShinyHunters link to ShipMonk is an extortion email, which establishes contact and not necessarily the intrusion. Crews routinely extort breaches they did not perform. Treat "ShinyHunters is in two of these" as strongly indicated for RingCentral and as claimed-but-unconfirmed for ShipMonk, and we will correct it if the forensics say otherwise.
Ninety-five percent, as always.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=six-supplier-breaches-in-one-week-and-shinyhunters-is-in-two-of-them-the-metabase-bug-that-took-sh
Comments