McKesson Cyber Incident: Confirmed Exfiltration, Unverified Patient-Data Counts

McKesson has confirmed a cybersecurity incident involving third-party applications, unauthorized access and data exfiltration. The healthcare and pharmaceutical distributor says it discovered the incident on 25 August 2026 and is still determining its full scope. Separate claims about voice phishing, compromised Okta accounts, Salesforce and Snowflake access, a ransom demand and 284 million patient-related records come from the ShinyHunters extortion group. McKesson has not confirmed those details, and BleepingComputer says it has not independently verified them.

What McKesson has actually confirmed

In an SEC filing, McKesson said it discovered an incident affecting its information systems on 25 August and that the investigation was in its early stages. As of the filing, the company had not determined that the incident was material or reasonably likely to materially affect its financial condition or operating results.

That wording is a current securities-law assessment, not a declaration that no data was taken or that no individual could be affected. On its incident page, McKesson separately confirms unauthorized access and exfiltration involving third-party applications. It also warns customers of intermittent service degradation that it believes is related to the incident. The company has not publicly identified the applications, the data fields or the number of people involved.

What ShinyHunters claims—and what is not established

ShinyHunters told BleepingComputer that it used voice phishing against multiple employees to compromise Okta single sign-on accounts, then accessed Salesforce and Snowflake. The group claims it removed about one terabyte of data over four days and demanded more than $55 million.

The group also claims the stolen Snowflake material contains roughly 284 million patient-related records. That is not the same as 284 million patients. ShinyHunters told the publication that the number is a raw count of records or lines and that it does not know how many unique people they represent. The alleged data categories and the authenticity and completeness of the dataset remain unverified publicly.

Until McKesson, a regulator or another authoritative source confirms the attack path and scope, the safe description is simple: the incident and exfiltration are confirmed; the attribution, vishing path, affected platforms, record count and ransom details are attacker claims.

Helpdesk recovery can become the access path

The claimed vishing technique is plausible and consistent with a broader pattern of attackers impersonating internal support personnel, but plausibility is not proof that it caused this incident. The defensive lesson still matters: an identity platform can enforce strong authentication after enrollment while a weak recovery or support workflow lets an attacker persuade a human to reset, enroll or reveal the factor that grants access.

Treat password resets, MFA enrollment, device registration and emergency access as privileged operations. A caller knowing an employee's name, role, manager or recent ticket details should not be enough. Use a second verified channel, require explicit approval for high-impact accounts and record who authorized the recovery—not the recovered secret itself.

Contain the identity plane before distributing new secrets

Invalidate active sessions. Changing a password alone may leave SSO, OAuth and SaaS sessions usable.
Review recovery events. Look for factor resets, new devices, helpdesk overrides and newly enrolled authenticators.
Audit connected SaaS applications. Determine what each compromised identity could reach, export or administer.
Rotate privileged credentials from a clean environment. Prioritize identities capable of resetting or issuing other access.
Reduce third-party standing access. Scope service accounts and integrations to the minimum data and actions required.
Communicate uncertainty accurately. Do not turn an attacker's raw record count into a patient count.

Where Secretus helps—and where verification comes first

Once the recipient's identity and device are independently verified, Secretus can be used to hand off a temporary recovery password, replacement token or one-time access value without leaving plaintext in email, chat or a support ticket. Short expiration and one-time access reduce the exposure window; Team Split can add dual control for organization-wide or break-glass credentials.

Secretus does not authenticate a caller or make a compromised workstation clean. If the recovery process sends a protected secret to an attacker-controlled person or endpoint, encryption has protected delivery to the wrong destination. Identity proofing and a known-clean endpoint must come first.

What customers and partners should do now

McKesson says its investigation is ongoing. Customers and partners should rely on the company's official incident page for updates and treat unexpected password-reset, invoice, patient-record or support messages with caution. Do not provide credentials or approve an MFA prompt because a caller cites details that may have come from a support case or another data source. Verify through a known contact path before acting.