McKesson is one of the largest pharmaceutical distributors in the world. On 28 August 2026 it filed a Form 8-K describing, in its own words, "a cybersecurity incident involving third-party applications and unauthorized access and exfiltration of data."

The exfiltration ran from 21 to 25 August 2026 — four days — and moved roughly one terabyte. It was detected on 25 August, which is to say on the last day of it.

Nothing in the chain was a vulnerability

The sequence, as reported, has three steps, and not one of them is a flaw in a product.

ShinyHunters ran vishing — voice phishing, an actual phone call — against multiple employees, and came away with their Okta SSO credentials. With those credentials the group signed in to Salesforce and Snowflake. Then it queried, and it exported.

There is no CVE here. No exploit, no patch to apply, no vendor at fault. Single sign-on did precisely what it exists to do: take one successful authentication and turn it into access to everything behind it. That is the feature. It is the reason organisations deploy it, and it is the reason a phone call was worth making.

JSCeal had the same shape: nothing cryptographic failed, an attacker simply held something they should not have held.

Snowflake could not have alerted on this, and that is not a defect

The obvious question is how a terabyte left over four days without setting anything off.

Because bulk export is the product.

Snowflake exists so that people can run large queries and pull large results out. A quarterly reporting job and an exfiltration job are, on volume alone, the same event: an authorised identity asking for an enormous number of rows and being given them. There is no threshold to set. Any number low enough to catch the second one buries the analytics team in alerts about the first, and a month later somebody turns it off.

The difference between the two is not in the volume. It is in the context around it:

  • Which identity ran it, and whether that identity has ever run anything resembling it before
  • From where — which network, which device, which country
  • At what hour, measured against that person's own normal working pattern
  • Which tables were touched, and whether that person has any business reason to touch them
  • In what sequence — enumeration followed by extraction looks nothing like a scheduled report

Every one of those signals is available. None of them is a number on a dashboard, which is exactly why they so often go unwired.

284 million is a row count, and the attackers said so

ShinyHunters claims 284 million records. That figure is going to travel as 284 million people, and it should not.

The group said themselves that these are raw database rows, not unique patients. In a pharmaceutical distribution system, one person generates a row per prescription, per shipment, per appointment, per claim line. A single patient on a long oncology regimen can account for dozens or hundreds of rows without anything unusual happening.

So the number is real and the unit is wrong, and the unit is doing all the work. The APIS figure had the identical problem — a record count read as a headcount.

The population actually named in the filing is narrower: a subset of customers of the Oncology and Multispecialty and Medical-Surgical business units.

The claimed contents are not narrow at all: names, dates of birth, Social Security numbers, medical record numbers, Medicaid numbers, medications, allergies and diagnoses.

A ransom demand of more than 55 million dollars has been reported by others. McKesson has not confirmed it.

Material is a test about the company, not about you

The 8-K says the investigation "is in its early stages", and that McKesson has not determined the incident is not material.

That phrasing gets read as a severity rating. It is not one.

SEC materiality asks whether an incident is significant to a reasonable investor — a financial question about the company's business, results and prospects. A distributor of McKesson's size can absorb a very large amount of human harm before that answer is yes.

For a person whose cancer diagnosis, medication list and Social Security number are somewhere in that terabyte, the severity was fixed on 25 August and has nothing whatsoever to do with McKesson's balance sheet. Both things are true at the same time. The filing is answering the first question honestly. It was never asked the second one, and no filing anywhere will be.

The perimeter that failed was identity, and it failed to a phone call

Every technical control in this story worked. Okta authenticated the person who presented the credentials. Salesforce authorised the session. Snowflake served the query. Each did its job correctly.

The failure happened before any of that, on a phone call, in the few minutes it takes to talk somebody through a login prompt.

That is why the fix is not a patch, and why being fully patched is not an answer to this incident.

What to do

  • Move to phishing-resistant authentication. Passkeys or hardware security keys, cryptographically bound to the origin. Push approvals and one-time codes are both readable aloud to a caller on the phone, which is the entire technique here.
  • Assume your help desk is the target. Vishing works on people whose job is to be helpful under time pressure. Give them a verification procedure they are explicitly permitted to follow when the caller is senior, urgent and annoyed.
  • Wire up context rather than volume in your data platforms. Identity, source, hour, tables, sequence. The volume alarm you are tempted to build will be switched off within a month.
  • Inventory which SSO identities can reach bulk data, and remove the ones that do not need it. Single sign-on multiplies the blast radius of every individual credential by design, so the only lever left is what sits behind each one.
  • If you are a patient, freeze your credit and treat unexpected calls about your prescriptions or your coverage as hostile until proven otherwise. Diagnoses and medication lists make extremely convincing pretexts, and that is the second-order use of this data.

What is not established

  • How many people are affected. The 284 million figure is rows, on the attackers' own account.
  • Whether the ransom demand is accurate. Reported by third parties, unconfirmed by McKesson.
  • Which third-party applications the filing means, beyond the Salesforce and Snowflake reporting.
  • How the vishing calls were framed, or how many employees the callers had to reach.
  • Why detection took until the fourth day, and what finally produced it.
  • Whether McKesson will conclude the incident is material. The investigation is in its early stages.