Severity Daily

IT and AI security incidents, checked against the primary source

Tag: ShinyHunters

  • McKesson confirms a cybersecurity incident and files it under Item 7.01, not the SEC’s cybersecurity item

    McKesson confirms a cybersecurity incident and files it under Item 7.01, not the SEC’s cybersecurity item

    McKesson told the SEC on Friday that it discovered a cybersecurity incident on 25 August. The filing does not say whether any data left the company — the statement the company gave reporters the same day does.

    What happened

    McKesson Corporation filed a Form 8-K on 28 August 2026, accession number 0000927653-26-000247, timestamped 16:05 UTC. The period of report is 25 August 2026. It is signed by Michele Lau, Executive Vice President and Chief Legal Officer. The SEC header lists two items: Regulation FD Disclosure and Financial Statements and Exhibits. Those are Item 7.01 and Item 9.01. The only exhibit is 104, the cover page iXBRL tag set.

    The disclosure itself is three sentences. “On August 25, 2026, McKesson Corporation discovered a cybersecurity incident affecting its information systems.” “An investigation of the incident is in its early stages.” And, on materiality: “As of the date of this filing, the company has not determined that the incident is material or that the incident has had, or is reasonably likely to have, any material impact on the company, including its financial condition or results of operations.” Readers are pointed to mckesson.com/cybersecurity for updates.

    What the filing does not do is describe anything. It names no affected system, product, business unit, or customer, and does not say whether data was accessed, whether data left the company, or whether operations were interrupted. It confirms that something happened and that the company has not yet concluded it matters.

    The same day, McKesson gave a more specific account to the press. CyberInsider quotes the company describing itself as “in the early stages of investigating a cybersecurity incident involving third-party applications and unauthorized access and exfiltration of data.” BleepingComputer quotes a statement beginning “We take the security and privacy of our partners, customers and their patients very seriously. Upon discovery, we immediately activated our incident response protocols.” Those are quotations in secondary coverage, not text McKesson filed. But the first of them concedes unauthorized access and exfiltration of data — language that appears nowhere in the 8-K.

    Separately, the group that calls itself ShinyHunters has claimed responsibility. Severity Daily treats that as a claim. The group told BleepingComputer it took roughly 284 million records, and — to its own credit on this point — clarified that the number is a raw count of lines, not of unique individuals, and that it does not know how many people are represented. CyberInsider reports a ransom demand of $55,236,150 and says it reviewed samples the actor provided privately, along with a screenshot of what appeared to be an accessed Snowflake database. BleepingComputer‘s account does not mention samples. The claimed method, again per the actor: voice phishing of employees using a lookalike domain, mckesson[.]claims, to capture credentials, then compromise of Okta single sign-on accounts and extraction of roughly a terabyte from Salesforce and Snowflake tenants between 21 and 25 August. None of the claimed mechanism is confirmed by McKesson, and attribution to any group is not established by anything in the record.

    Why it matters

    Form 8-K has three plausible homes for this disclosure and McKesson used the one nobody suggests. Item 1.05, “Material Cybersecurity Incidents,” is the item the SEC added in 2023 and is reserved for incidents the registrant has determined to be material. Item 8.01, “Other Events,” is the catch-all. In a May 2024 statement, Erik Gerding, then Director of the SEC’s Division of Corporation Finance, addressed exactly this situation: if a company chooses to disclose an incident “for which it has not yet made a materiality determination, or a cybersecurity incident that the company determined was not material,” the Division “encourages the company to disclose that cybersecurity incident under a different item of Form 8-K (for example, Item 8.01).” The stated reason was to let investors distinguish material incidents from the rest.

    Item 7.01 is Regulation FD Disclosure, and it is not the same instrument. Form 8-K’s General Instruction B.2 says information furnished under Item 7.01 “shall not be deemed to be ‘filed’ for purposes of Section 18 of the Exchange Act or otherwise subject to the liabilities of that section,” unless the registrant says otherwise or incorporates it by reference. McKesson did neither. So the disclosure sits in the category of information the company furnished rather than filed, carrying less liability exposure than an Item 8.01 disclosure of the same three sentences would have carried.

    There is a benign reading. Reg FD exists to stop selective disclosure, and if McKesson had already told partners or analysts something, furnishing a public statement under 7.01 is the mechanically correct response. We cannot rule that out. It does not change the effect: the version of events that reached EDGAR is thinner than the version that reached reporters, and the thinner one is the one not subject to Section 18.

    That inversion is the part worth carrying forward. An investor who monitors McKesson’s filings learned on Friday that an unspecified incident occurred and that materiality is undetermined. A reader of a security news site learned the same day, from the company itself, that the investigation involves third-party applications and the unauthorized access and exfiltration of data. When the press release and the filing diverge in specificity, the filing is not the more careful document — it is the more protected one.

    Note also what “has not determined that the incident is material” is not. It is not a finding that the incident is immaterial. Under the 2023 rules the four-business-day clock runs from the materiality determination, and that determination is required to be made without unreasonable delay. Discovery was 25 August; the filing is 28 August. If the determination flips, the correct next artifact is an Item 1.05 8-K, and its absence to date should not be read as a conclusion.

    If the claimed mechanism turns out to be accurate — and it is claimed, not confirmed — it belongs to a pattern that has now repeated across a long run of large-enterprise incidents this year. Credentials are taken by phone, not by exploit. A lookalike domain costs a few dollars. The data is then read out of SaaS tenants using valid sessions, so the vendor is never breached in any sense the vendor would recognize, and the customer’s own perimeter is not involved. There is no CVE, no patch, and no vendor advisory to wait for. The controls that would have mattered are help-desk identity verification, phishing-resistant authentication on the SSO tier, and tenant-side query and export logging in Salesforce and Snowflake that someone actually reads.

    On the number: treat 284 million as a row count and nothing more, which is what the group that produced it says it is. Any figure approaching the population of the United States, offered for a single company, is almost certainly counting records or lines rather than people. McKesson has not published a figure at all.

    What to do

    This is not a patch story and there is nothing to install. For organizations that use the same class of infrastructure, the checks that follow from the claimed pattern are worth running regardless of whether that claim is confirmed. Audit Salesforce and Snowflake tenants for large or unusual export and query activity in the past two weeks, and confirm export volume is alerted on, not merely logged. On the identity tier, verify that high-privilege accounts use phishing-resistant authentication and that a stolen session cannot be reused from a new device or network without re-authentication. Review the help-desk procedure for password and MFA resets, since a voice call is the documented failure point in this class of incident. Search certificate transparency logs and your registrar feeds for domains that mimic your own — the claimed domain here was an ordinary registration under a common new gTLD.

    If you are a McKesson customer or trading partner: the 8-K gives you nothing actionable. Watch mckesson.com/cybersecurity, which is where the company said updates will appear, and ask your account contact in writing for scope, affected systems, and whether any of your data is implicated. A written answer is worth more than a filing that declines to name a system.

    Sourcing note

    The primary source for this story is McKesson’s Form 8-K, accession 0000927653-26-000247, filed 28 August 2026 for a period of 25 August 2026, read directly from EDGAR; all quoted disclosure language and item designations come from that document and the SEC header. The Item 7.01 furnished-versus-filed language is quoted from General Instruction B.2 of Form 8-K on sec.gov. The Division of Corporation Finance guidance on Item 8.01 is quoted from Erik Gerding’s 21 May 2024 statement on sec.gov.

    McKesson’s statements to the press are quoted as they appear in CyberInsider and BleepingComputer, both published 28 August 2026. We could not reach mckesson.com directly — the site returned HTTP 403 to our fetches — so the company’s own incident page has not been read, and any content on it is unverified here. All claims about record count, ransom amount, method, exfiltration volume, and the involvement of Okta, Salesforce, and Snowflake originate with the threat actor and are reported as claims. The two outlets differ on samples: CyberInsider says it reviewed data provided privately by the actor, BleepingComputer‘s report does not mention samples. Attribution to ShinyHunters rests on the group’s own assertion and is not confirmed by McKesson or any agency.

    Unresolved: whether McKesson will file an Item 1.05 8-K, whether regulated health information is implicated, and whether the claimed SaaS-tenant vector is accurate. No state attorney general breach filing or HHS Office for Civil Rights entry had appeared at the time of writing.

  • 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.