Status: this post reflects information available as of September 3, 2026. The investigation is ongoing and details may change.
On August 25, 2026, McKesson detected a cybersecurity incident. Three days later, it told customers what it had found: unauthorized access to third-party applications and data taken. The company filed a Form 8-K with the SEC, said the investigation was in its early stages, and pointed to a subset of customers in its Oncology & Multispecialty and Medical-Surgical business units. The extortion group ShinyHunters claimed responsibility and put the number at 284 million records. McKesson has confirmed no such figure.
The detail worth pausing on is in McKesson’s own wording. Third-party applications. The company wasn’t breached through a hole in its data center. Attackers reached software McKesson uses but doesn’t build or run, and the data inside it went out the door.
That matters because of who McKesson is to everyone else. It moves roughly a third of the prescription medicines going to North American hospitals, pharmacies and clinics, supplies medical products, supports oncology and specialty care, and runs the Health Mart pharmacy franchise. Founded in 1833, it serves more than 40,000 corporate and institutional customers.
So a very large number of healthcare organizations are now dealing with a breach that happened two steps away from them, in software they never chose, at a supplier they can’t direct.
Key takeaways
McKesson has confirmed that attackers reached third-party applications and exfiltrated data, and that early findings point to a subset of customers in two business units. It has not confirmed how many people are affected or exactly what was taken.
ShinyHunters claims 284 million records and a ransom demand over $55 million. Neither is verified, and reporting notes the record figure counts rows of raw data rather than unique patients, so the number of affected individuals will almost certainly be far lower.
This group has spent more than a year getting into cloud applications without exploiting a single software flaw. Microsoft’s research found the attackers abused trust the organization had already granted, mainly through OAuth connections, and that the activity evaded conventional authentication detections.
For downstream organizations, exposure came from a supplier’s dependencies rather than the supplier’s own security posture. That’s a gap most vendor risk programs aren’t built to see.
What McKesson has confirmed
McKesson announced on August 28 that it had launched an investigation into a cybersecurity incident involving third-party applications and unauthorized access and exfiltration of data. It activated incident response protocols and engaged outside cybersecurity experts. Customers were warned about possible impact on system availability, including intermittent service degradation, though the company said it wasn’t proactively disconnecting systems.An August 29 update said McKesson continues to serve customers across all lines of business, orders are being accepted, and distribution centers remain open with products shipping. Early results pointed to data relating to a subset of customers in the Oncology & Multispecialty and Medical-Surgical units, and steps taken to block further unauthorized access appeared to have worked, with no further activity detected. A spokesperson told TechCrunch the company believes there’s no ongoing unauthorized activity in its systems.The SEC filing gives August 25 as the detection date and states the company hasn’t yet determined whether the incident is material.
What the attackers claim
Everything here comes from ShinyHunters through security reporting, and McKesson has confirmed none of it.
Roughly a terabyte of data was taken between August 21 and 25, with a ransom demand above $55 million, according to BleepingComputer, which has been in contact with the group. ShinyHunters says the material includes names, contact details, Social Security numbers, dates of birth, medical record numbers, Medicaid numbers, medication and allergy information, diagnoses and appointment data, drawn from Salesforce and Snowflake environments. The hackers told TechCrunch they got in by tricking employees into granting access using phishing and social engineering, and TechCrunch said it verified a small subset of a data sample against public records. McKesson employee information, including home addresses, was reportedly included.The group set a September 1 deadline to begin payment negotiations.
How this class of attack actually works
McKesson hasn’t described the method. But this group’s tradecraft is unusually well documented, and understanding it explains why so many large organizations have lost data the same way this year.
There’s no malware in the typical version of this attack. No exploit. No stolen password replayed against a login page.
Instead, someone calls. Mandiant’s January 2026 research describes operations built on voice phishing and victim-branded credential harvesting sites, used to collect single sign-on credentials and multi-factor authentication codes, after which the attackers move into cloud SaaS applications to pull out data and internal communications for extortion.
The more interesting variant works through OAuth, the mechanism that lets applications talk to each other on your behalf. Analysts at EclecticIQ described attackers impersonating IT staff, calling corporate support desks, and walking employees to a legitimate Salesforce connection page where they were talked into entering a code that authorized an attacker-controlled application, often a modified version of Salesforce’s own Data Loader tool. Once that consent was granted, the attackers had bulk export capability and a path into Okta, Microsoft 365 and Amazon S3.
Microsoft published research in July 2026 mapping a year of this activity. Its finding is the part every security leader should sit with: the campaigns didn’t stem from a vulnerability in the platform. Attackers abused authorized applications, third-party integrations and weak guest-user configurations to operate inside legitimate cloud workflows. The access inherited user and application privileges, allowing the attackers to enumerate and query CRM records while evading conventional authentication detections, and it often produced persistent access and exfiltration at scale.
Sit with that last clause. The traffic looked legitimate because it was legitimate, in the sense that the platform had been told to allow it. An employee approved a connection. The application then worked through the API as that user, without hitting multi-factor authentication again. Sign-in logs show a normal day.
Why your questionnaire wouldn’t have caught this
Follow that mechanism to its conclusion and the implications for vendor assessment are uncomfortable.
A supplier can hold current certifications, pass your security review, patch on schedule, encrypt everything at rest, and still lose your data this way. There’s no unpatched system to find. No misconfigured firewall. No failed control that shows up in an audit.
The controls that would have mattered are ones standard questionnaires rarely ask about clearly. Can a person under pressure on a phone call approve access? How does the help desk verify identity before a credential reset? Who reviews which connected applications have API access to your CRM, and how often? Does anyone notice when a legitimate integration suddenly exports far more data than usual?
Most vendor assessments were designed for a world where breaches came from software weaknesses. This class of attack targets the trust relationships between systems and the people who administer them. Those are different questions, and asking the old ones with more rigor doesn’t get you to the new ones.
One compromise, hundreds of victims
Here’s where the third-party problem stops being abstract.
When attackers compromise a company, they get that company’s data. When they compromise a SaaS integration that hundreds of companies have connected to their systems, they get a position they can work across every one of those customers.
Public reporting compiled by Huntress traces exactly that pattern. Stolen OAuth tokens from the Salesloft Drift integration were reportedly used to reach roughly 760 downstream Salesforce customer organizations in August 2025. Token abuse involving Gainsight in November 2025 affected more than 200 Salesforce instances, with Salesforce revoking the related OAuth access during response. Microsoft’s mapping identified supply chain compromise through trusted workflows and integrations as one of the primary intrusion paths, naming Salesloft and Gainsight among them.
Seven hundred and sixty organizations. One compromised integration.
None of those 760 had a security failure. Most of them probably had good programs. What they had in common was a shared dependency that sat one layer below the vendor relationships they were actually assessing, and that layer was where the risk lived.
If your vendor risk program evaluates suppliers one at a time, it will never show you this. Concentration risk is a portfolio property. You only see it if you’re looking at the portfolio.
The impact, layer by layer
For McKesson, the operational damage looks contained so far. The company says it’s shipping, taking orders and serving customers. What remains open is the cost of the investigation, notification obligations once affected individuals are identified, the identity protection services it has said it will provide, likely litigation, and whatever regulatory attention follows. Its SEC filing hasn’t determined materiality yet, which is a genuine statement about an early investigation rather than a dodge.
For downstream healthcare organizations, the position is harder in some ways. Patient-linked data they sent to a distributor as part of normal operations may have been in the accessed systems. They didn’t select the applications involved. They can’t inspect the forensics. They will get their information on McKesson’s timeline. And depending on what the investigation finds, some of them may carry their own notification duties toward patients who have never heard of McKesson and won’t understand why their pharmacy is calling.
For patients, health data is durable in a way payment data isn’t. You can reissue a card. You can’t reissue a diagnosis, a medication history or a Social Security number. Criminals use health information in social engineering precisely because it creates urgency: a prescription problem, an unpaid claim, an insurance verification request. Those messages land because they’re plausible.
For regulators and the sector, this joins a run of incidents that has made healthcare an obvious target. ShinyHunters’ previous healthcare victims include Medtronic, Abbott Laboratories, iRhythm, AdaptHealth and DentaQuest, and the group recently claimed a data theft incident at Baxter International. Separately, Boston Scientific was hit in late August, Stryker had thousands of employee devices remotely wiped in March, and CareCloud and TriZetto each disclosed breaches affecting over three million patients. Read that list as a hospital and you’ll likely find several of your own suppliers on it.
What this changes about vendor risk work
Six things follow directly from how this attack works.
Ask suppliers about identity, not just infrastructure. Whether multi-factor authentication can be approved by a person on a phone call. How help desk identity verification works before a credential reset. Who holds administrative access to the identity provider. These map to the actual attack path.
Ask what’s connected to your data. Which third-party applications have API access to the systems holding your information, who approved them, and when that list was last reviewed. Most suppliers can’t answer quickly, and the difficulty of the question is itself informative.
Map concentration across your portfolio. If forty of your suppliers store customer data on the same handful of platforms, you have one risk, not forty.
Assume you’ll be assessing suppliers who can’t talk to you. An organization in active incident response is not filling out your questionnaire. That’s the exact week you most need an answer about them, and the assessment methods that depend on cooperation stop working right when they matter.
Watch criminal channels rather than waiting for letters. This group publicizes victims on leak sites and Telegram before most notifications go out. Extortion is a publicity business by design, and that publicity is a signal available to anyone monitoring for it.
Separate confirmed facts from claims in everything you report upward. Boards, auditors and regulators are following this too. The distinction is doing real work.
Where Sling fits
Sling’s scoring is built on a different premise than most vendor risk tools: what attackers already know about a company tells you more than what an external scan shows. The Sling Score draws on darknet and criminal intelligence collected in-house over more than a decade, attack surface mapping and historical breach data, and it estimates the probability of a company being attacked.
Three parts of that are directly relevant to an incident like this one.
The first is where the intelligence comes from. Groups running data extortion operate in the open on leak sites, forums and Telegram channels, because pressure is the product. Stolen credentials from vishing campaigns surface in criminal markets. Monitoring those channels is Sling’s core function, not a feature bolted onto a scanner, and it’s the layer where warning tends to appear before disclosure does.
The second is that assessment doesn’t require the supplier’s participation. Sling starts from a domain name, needs no agent and no vendor cooperation, and returns a full picture within 24 hours. When a supplier is in the middle of an incident and unreachable, that’s the difference between having an answer and waiting for one.
The third is portfolio visibility. A dashboard showing every monitored supplier and an aggregate exposure view is how concentration becomes visible at all.
Frequently asked questions
What happened in the McKesson data breach?
McKesson detected a cybersecurity incident on August 25, 2026 and disclosed it on August 28, confirming unauthorized access to third-party applications and the exfiltration of data. Early findings point to a subset of customers in its Oncology & Multispecialty and Medical-Surgical business units. The investigation is ongoing.
How many records were stolen?
McKesson has not confirmed a number. ShinyHunters claims 284 million records, but reporting indicates that figure counts rows of raw data rather than unique patients, and the claim remains unverified.
How did the attackers get in?
McKesson hasn’t described the method. The attackers told TechCrunch they used phishing and social engineering against employees. Microsoft’s research on this group’s broader campaigns found attackers abused authorized applications, third-party integrations and weak guest-user settings rather than exploiting a platform vulnerability.
Why does this affect organizations that weren’t breached themselves?
Because their data was in McKesson’s systems. Hospitals, pharmacies and clinics send patient-linked ordering and billing information to distributors as a matter of routine, and that data ends up in applications those organizations never selected or reviewed.
Would a security questionnaire have caught this?
Unlikely. Attacks that work through approved application connections and social engineering leave no failed control for an audit to find. The relevant questions are about identity verification, connected application governance and data export monitoring, which most standard questionnaires don’t cover clearly.
What should healthcare organizations do now?
Confirm scope directly with your McKesson account contact, since the company has named specific business units. Then document what data actually flows to them, check which other suppliers depend on the same cloud platforms, and make sure you can learn about supplier incidents without waiting for a notification letter.
The pattern underneath the headline
Every few weeks another large healthcare supplier discloses a breach, and every time a long list of organizations finds out they were exposed through software they never evaluated, holding data they’d stopped thinking about, at a company they don’t have a contract with. The names change. The structure doesn’t.
The uncomfortable part of the McKesson data breach isn’t that a big company got hit. It’s that the way in was ordinary. Trusted applications, granted access, a convincing phone call. There was nothing to patch.
You can’t audit your way to the bottom of that chain. What you can do is know where your data actually sits, watch the suppliers holding the most of it, and pay attention to the places attackers talk about their targets before the press release goes out.