Severity Daily

IT and AI security incidents, checked against the primary source

Tag: McKesson

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

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