McKesson Confirmed the Data Left. ShinyHunters Claims 284 Million Patient-Data Rows.
McKesson has confirmed unauthorised access to third-party applications and the exfiltration of data, while warning customers about intermittent service degradation. ShinyHunters says social engineering opened the path into Okta, Salesforce and Snowflake and claims it stole roughly 284 million patient-related data rows. That figure is an unverified count of database rows, not a confirmed number of patients.
The US healthcare and pharmaceutical distributor disclosed the incident to the Securities and Exchange Commission after discovering it on 25 August 2026. In a customer notice dated 28 August, McKesson said the investigation remained at an early stage and that it was still determining the scope and nature of the data involved.
The company has confirmed two consequential facts: unauthorised access reached third-party applications, and data left the environment. It has not publicly identified the affected applications, the stolen data fields or the number of people involved. The more detailed account comes from the alleged attacker and has not been independently verified.
What is confirmed and what remains a claim
| Status | What is known |
|---|---|
| Confirmed by McKesson | The incident involved third-party applications, unauthorised access and data exfiltration. McKesson also reported intermittent service degradation that it believed was related to the incident. |
| Reported by ShinyHunters | The group says it used voice phishing against employees, compromised multiple Okta single sign-on accounts, reached Salesforce and Snowflake and removed about one terabyte of data between 21 and 25 August. |
| Not independently verified | The claimed 284 million patient-related data rows, the specific data fields, the exact applications reached, the ransom demand and the attacker’s account of McKesson’s response. |
| Still unknown | The number of unique people affected, the organisations whose data was involved, whether every claimed data type was present and the incident’s financial or operational impact. |
That separation matters. An attacker can possess a large export without its public description being accurate, and one person can generate many rows across prescriptions, appointments, claims and other records. McKesson’s own notice confirms theft, but it does not validate the attacker’s figures.
The claimed path began with identity, not malware
According to ShinyHunters, the intrusion began with voice phishing directed at several McKesson employees. The group says it used a lookalike domain, mckesson[.]claims, and compromised multiple Okta accounts before moving into data-rich cloud services.
This description matches a pattern Health-ISAC has been warning healthcare organisations about: callers impersonate staff or support personnel, manipulate help desks or users into resetting authentication factors, take over an identity provider account and then pivot into connected software-as-a-service platforms. The objective is rapid data theft and extortion, not necessarily endpoint encryption.
Microsoft, Google or another cloud platform does not need to be technically exploited for this chain to work. Once a trusted identity and active session are obtained, legitimate access paths can carry the attacker into systems that hold far more data than the original account suggests.
Why 284 million rows does not mean 284 million patients
BleepingComputer reported that ShinyHunters described approximately 284 million raw records or lines containing patient-related information. The group also said it had not analysed how many unique people those rows represented.
BlackTree therefore does not describe this as 284 million victims or 284 million patient records. A single patient may appear in many rows, and the same data may be duplicated across tables, exports or customer environments. Until McKesson completes its investigation and notifications, the responsible formulation is that an attacker claims 284 million patient-data rows.
The distinction does not make the incident minor. McKesson sits in a highly concentrated healthcare supply chain. A compromise involving shared platforms can expose information belonging to many providers, pharmacies, insurers and patients even when the attackers never breach each organisation separately.
The operational risk sits in the SaaS control plane
The reported chain illustrates why identity providers and connected SaaS applications should be treated as critical infrastructure. Salesforce, Snowflake and similar platforms can aggregate data from many business units and customers. A compromised single sign-on account can turn that concentration into an efficient collection point.
A separate Health-ISAC alert described an attempted ShinyHunters-linked intrusion in which stolen credentials and a valid multifactor prompt were not enough. The target’s managed-device restrictions blocked access to the SaaS environment. That result is operationally important: phishing-resistant authentication helps, but device trust and conditional access can still stop a compromised session from reaching the data.
What healthcare organisations should do now
- Treat the identity provider as Tier 0. Restrict administrative functions, require phishing-resistant FIDO2 or WebAuthn credentials and monitor every factor reset, enrolment and account-recovery event.
- Harden help-desk resets. Use out-of-band identity proofing through a known number, require a second approver for sensitive accounts and do not complete a reset solely on the same inbound call that requested it.
- Require managed devices for data-rich SaaS. Conditional access should evaluate device compliance, network context and session risk, not only a password and successful multifactor prompt.
- Revoke the whole session after suspected compromise. Resetting a password is not enough. Revoke active sessions and refresh tokens, remove attacker-enrolled factors, rotate exposed API credentials and review OAuth grants.
- Hunt in the cloud audit trail. Review Okta system logs, new sessions and factor changes, Salesforce bulk exports and API activity, Snowflake query and access history, unusual egress and newly authorised integrations.
- Prepare for data-extortion incidents. Response plans should cover SaaS evidence preservation, customer data mapping, notification decisions and business continuity even when endpoints are not encrypted.
- Monitor the claimed lookalike domain as one indicator. The reported
mckesson[.]claimsdomain is relevant to this incident, but defenders should also hunt for other newly registered domains imitating company brands, login portals and help-desk workflows.
The BlackTree view
The central risk is not only that McKesson may hold an enormous volume of sensitive healthcare data. It is that modern enterprises concentrate trust in an identity layer and then connect that layer to applications designed to make data easy for authorised users to reach.
When a help-desk process can create a trusted session, the attacker may not need malware, a zero-day or noisy lateral movement. The normal cloud control plane becomes the intrusion path, and legitimate export functions become the exfiltration tool.
McKesson has confirmed enough to justify urgent defensive review, but not enough to validate the attacker’s scale claims. Organisations should respond to the demonstrated identity and SaaS risk while resisting the temptation to turn 284 million unverified database rows into 284 million confirmed victims.
Sources
- McKesson Form 8-K, reporting an incident discovered on 25 August 2026 and filed on 28 August 2026. The filing page does not provide a publication time.
- McKesson Customer Cybersecurity Information Center, dated 28 August 2026. No publication time was provided.
- BleepingComputer report, published 28 August 2026 at 18:40. The page does not identify a timezone.
- Health-ISAC guidance on ShinyHunters’ healthcare tactics, published 24 July 2026. No publication time was provided.
- American Hospital Association and Health-ISAC incident alert, published 24 August 2026. No publication time was provided.
