Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Carhartt

  • The vendor record understated the day, and a federal clock runs out tomorrow

    The vendor record understated the day, and a federal clock runs out tomorrow

    The most consequential item on the site today is a Citrix flaw that Citrix still describes as a crash. CVE-2026-8452 is in CISA’s Known Exploited Vulnerabilities catalog with a federal remediation deadline of tomorrow, Saturday 29 August, and two research teams have taken it from an unauthenticated SAML request to a root shell. Citrix’s bulletin CTX696604 has not been updated since 20 July and still calls it a denial-of-service bug. Internet-facing, pre-authentication, a clock that expires in hours, and a vendor description that invites you to defer it — that combination outranks the two items that sound bigger. McKesson filed an 8-K this afternoon and Carhartt’s breach is being counted in the millions. Neither gives anyone anything to do tonight. The NetScaler appliance does.

    The day had a real thread, and it is not a comfortable one: the vendor record kept failing to carry the risk. Citrix labels a root shell a denial of service. Broadcom’s vCenter advisory is at its third revision and still says nothing about exploitation, while a German DFIR firm has mapped 361 victim IP addresses across 47 countries. Microsoft published a CVSS 10.0 Entra ID flaw as exploited and then filed a one-line retraction that much of the coverage never followed. PaperCut’s emergency builds do not appear on PaperCut’s own release history. JFrog’s Artifactory flaw is on a federal clock that the July version most people patched to does not satisfy. And a CVSS 10.0 in ByteDance’s UI-TARS-desktop is remediated by a commit hash rather than a release. Six stories, one failure mode: anyone who triaged today from vendor severity text triaged it wrong.

    Order of business after NetScaler. If you run N-central on premises, or you buy from an MSP that does, that is your first item instead — N-able says in its own words that attackers used Take Control to reach managed endpoints and left Cloudflare tunnels behind, and two rounds of patching were insufficient. Then vCenter, where the persistence chain outlives the patch. Then the rest of the weekend’s clocks: a 2019 SQL Server bug also due tomorrow, though it needs a privileged login to work, and an ownCloud authentication bypass from 2023 plus a Linux kernel container escape due Sunday. PaperCut is under active attack with no CVE at all, which means no KEV entry and no deadline to force it onto anyone’s list.

    Below the clocks: three Langflow code-execution CVEs landed at NVD this evening with no workaround offered and 1.11.2 as the only fix. GPUThor is the day’s best research and the day’s most oversold coverage; it beat NVIDIA’s ECC on four workstation cards, not on the AI fleet. The GitLab exploitation claim rests on one firm’s honeypot data and GitLab has not addressed it; patch anyway, but do not carry the claim as confirmed. And two pieces on the record itself: BOD 22-01 has been dead since June, and this week’s KEV entries carry identical required-action text whether the deadline is three days or fourteen.

    Still open. McKesson’s filing does not say whether data left the company; the statement it gave reporters the same day does, and the two have not been reconciled. Carhartt has said nothing publicly, and the 12.9 million figure is a researcher’s correction, not a company number. Broadcom’s vCenter advisory has been revised twice since the first victim callbacks and still does not mention exploitation. PaperCut still has no CVE. Two federal deadlines land Sunday, on a weekend, which is its own kind of answer about how the three-day band is working.

  • Carhartt’s breach is 12.9 million records, not 25 — and the gap is benchmark data someone left in production

    Carhartt’s breach is 12.9 million records, not 25 — and the gap is benchmark data someone left in production

    Every headline today puts the Carhartt breach at 12.9 million accounts. That number did not come from Carhartt, which has said nothing publicly, and it did not come from the attackers, who claimed roughly twice as many. It is a researcher’s downward correction — and the reason nearly half the dump evaporated under scrutiny is a lesson worth more than the breach itself.

    What happened

    ShinyHunters published data attributed to Carhartt in mid-August, claiming more than 50GB compressed covering customer, employee, and corporate records. The raw dump contained 24.8 million unique email addresses.

    Troy Hunt’s analysis, now loaded into Have I Been Pwned, puts the real figure at 12.9 million accounts, after discarding approximately 11.9 million records — about 47% of the dump — as not corresponding to real people.

    The bulk of the discard, some 11.25 million records, was synthetic TPC-DS benchmark data. TPC-DS is a standard decision-support benchmark used to test the performance of analytics and data warehouse systems. Its generated rows are identifiable once you know what to look for: fabricated email domains and birth years distributed uniformly across 1924 to 1992. The remainder of the discard was Microsoft 365 routing aliases and internal accounts with names like perftest and deactivate- prefixes.

    What survived is real, and it is not trivial. The verified records include names, email addresses, phone numbers, physical addresses, dates of birth, salutations, birth countries, and first-purchase dates. More than 15,000 @carhartt.com employee addresses are in there too.

    Carhartt has said nothing

    This is the part that should shape how you read every version of this story. There is no Carhartt statement. There is no breach notification on the company’s site. There is no entry on the California Attorney General’s breach notification portal. Reporters have asked; The Register noted the company “is yet to comment on the breach anywhere publicly,” and BleepingComputer reported a spokesperson was not immediately available.

    So the chain of custody for the number in every headline runs: attackers published a dump → a researcher analyzed it and revised the count downward → publications reported the researcher’s figure. At no point does the affected company appear. If you are briefing anyone on this, the correct phrasing is “researcher analysis of data published by ShinyHunters indicates approximately 12.9 million accounts,” not “Carhartt disclosed.”

    Several claims attached to this story come from ShinyHunters alone and have no corroboration: that the entry point was a compromised Databricks analytics platform, that a $3.3 million extortion demand was made, and that it was refused. We are not printing those as fact. They may well be true. Nothing confirms them.

    Why it matters

    The interesting question is not how big the breach was. It is why nobody — including, apparently, the attackers — could tell.

    Eleven and a quarter million rows of database benchmark data were sitting in the same environment as real customer records. Someone ran a TPC-DS workload to size or test an analytics platform, and the generated dataset was never cleaned out. When that environment was taken, the synthetic rows left with everything else, indistinguishable from real people until a researcher who knew the benchmark’s fingerprint went looking.

    Work through the consequences of that for a moment. If this had gone the ordinary route — a regulator asking how many people were affected, a notification obligation with a deadline attached — the honest answer would have been that the company could not say. Not because forensics were incomplete, but because the data itself could not be sorted into real and fake without specialist analysis of a benchmark schema. Every downstream decision depends on that number: who gets notified, in which jurisdictions, on what clock, at what cost.

    There is a second-order problem too. Test and benchmark data in production analytics environments does not just inflate breach counts. It skews the models trained on it, corrupts the metrics computed from it, and — because it looks like customer data — tends to inherit whatever access controls customer data has, which is to say fewer than it should.

    The 15,000 employee addresses deserve their own line. Corporate email addresses in a public dump are raw material for credential stuffing and for targeted phishing against a company that has not yet acknowledged it has a problem.

    The verification gap

    Step back from Carhartt for a second and look at who did the work here.

    An attacker published a dump and made a claim about its size. The affected company said nothing. No regulator has said anything. The number that every publication is now using, and that will end up in the running tallies of “biggest breaches of 2026,” was established by one independent researcher who recognized a database benchmark schema by its birth-year distribution.

    That is not a criticism of the researcher. It is an observation that breach scale — the input to notification obligations, regulatory exposure, and every “how bad was it” conversation in the industry — is increasingly established by whoever bothers to look, on no particular timeline, with no obligation to look at all. Roughly 47% of this dump was fictional. Nothing in the process that produces breach headlines would have caught that.

    The practical takeaway for anyone running IT: if your organization ends up in this position, the count that sticks is the one that gets published first and analyzed best, and it will not necessarily be yours. Being able to produce a defensible number quickly is a capability, and it starts with knowing what is actually in your data stores before anything goes wrong.

    What to do

    • Audit what synthetic and benchmark datasets are sitting in your production analytics environments. TPC-DS, TPC-H, generated load-test fixtures, anonymized-but-not-really exports. If you cannot answer where they are, you cannot answer how many people a breach affected.
    • Check whether test data inherits production access controls. It usually does, in the wrong direction — it gets the same permissive treatment as the real thing while receiving none of the scrutiny.
    • Make “can we count the victims” part of your incident response tabletop. Most exercises assume the number is knowable. This one wasn’t.
    • If you are downstream of Carhartt as a supplier or partner, note that 15,000 employee addresses are public and act accordingly on inbound mail purporting to come from them.

    Sourcing note

    The 12.9 million figure and the composition analysis are Troy Hunt’s, published on his site and reflected in the Have I Been Pwned breach entry. Carhartt has issued no statement of any kind, and no notification appears on the California AG portal; we did not check Maine, Texas, or Washington. The 50GB volume, the 24.8 million raw email count, the Databricks attack vector, the $3.3 million demand and its refusal are all ShinyHunters’ claims, and only the data volume has been independently examined. No regulator has confirmed anything about this incident.