The Worst Data Breaches of 2026: What a Pentest Catches

On 15 September, TechCrunch published its roundup of the worst hacks and data breaches of 2026 so far. If you run security at a mid-market company, there is a reasonable chance it reached your inbox from someone above you, with three words attached: could this happen?

The honest answer is harder than any vendor blog will admit, and the reason is not modesty. In three of the four headline incidents on that list, the root cause was never made public. DentaQuest has not disclosed how the intruders got in. Boston Scientific has not disclosed what hit its manufacturing estate. Coca-Cola's fairlife filed an 8-K describing the impact and said nothing about the ingress path. Only the Instructure Canvas breach has a reported initial access vector, and even that comes with a conflicting account.

So when a board member forwards you the worst data breaches 2026 has produced and asks whether you are exposed, you cannot answer by patching whatever the coverage names. There is nothing to patch. What you can do is work out which class of attack each incident belongs to, then check whether your own testing has ever covered that class. That question has a real answer, and this post walks through it for all four.

What TechCrunch's 2026 roundup actually says

Start with scale, because scale is the part that travels. The Instructure Canvas incident alone involved a claimed 275 million records from 8,809 institutions worldwide, on a platform widely used across US higher education. One incident, one vertical, one platform: a fair proxy for how large a single well-placed compromise of a shared SaaS layer gets in 2026.

The four incidents this post examines are DentaQuest, Instructure Canvas, Boston Scientific and fairlife (a Coca-Cola company). They are worth taking together for a specific reason: four different attack classes across four different industries. One is mass exfiltration of health and identity data from a benefits administrator. One is a multi-tenant SaaS compromise with an extortion campaign bolted on. One is a destructive attack that stopped a medical device manufacturer's factories rather than stealing a database. One is ransomware that halted food production and was disclosed to the SEC.

If your mental model of "a breach" is a single shape, these four break it in four different directions, and they map onto four different testing disciplines, only some of which most mid-market organisations have ever bought. Laid out on a single line, the year also makes one thing obvious: these were not a wave. They were four separate events spread across four months, and with the exception of ShinyHunters surfacing in two of them, nothing connects them but the calendar.

The four incidents, and what is actually known

A discipline note first, because it decides what you can act on. What follows separates what has been confirmed by the affected organisation or a regulator from what has been reported by press or claimed by an attacker. Treating a claim as a fact is how teams end up building controls against a threat that was never in the story.

DentaQuest: 15 million records, and a root cause that was never disclosed

DentaQuest, a large dental benefits administrator, experienced unauthorised network access between 17 and 20 May 2026. Breach notices began on 17 July 2026. The number reported to the US Department of Health and Human Services exceeded 15 million individuals; an independent researcher cited by HIPAA Journal put it at 23.4 million after analysing unique name and date-of-birth combinations. Both are in circulation and neither has superseded the other, so quote both with attribution rather than picking the more dramatic one.

The exposed data is the part that matters for affected individuals. According to reporting from HIPAA Journal, SecurityWeek and BankInfoSecurity, it included names, addresses, Social Security numbers, member IDs, Medicaid and Medicare numbers, and dental and vision health information covering provider, diagnosis, treatment and billing. That combination is close to a complete identity and health record, which is why the incident tops most 2026 lists regardless of which headcount you use.

The extortion group ShinyHunters claimed responsibility and reportedly leaked around 234 GB of data. What has not been published, at the time of writing, is how the intruders obtained network access in the first place. That absence is not an oversight by reporters. It recurs across all four incidents, for a reason worth coming back to once you have seen the rest of the list.

Instructure Canvas: when the low-friction signup path is the attack path

The Canvas incident is the one with a reported vector, and it is instructive because of where that vector sits. Unauthorised access began on 25 April 2026, was detected on 29 April and was described as resolved on 6 May. A second wave on 7 May defaced Canvas login portals at roughly 330 institutions with extortion messages, setting a ransom deadline of 12 May. The attackers claimed 3.65 TB of data, approximately 275 million records, spanning 8,809 institutions.

The reported initial access was a vulnerability "regarding support tickets" in the Free-for-Teacher (FFT) environment, the free tier any educator can sign up for. Instructure maintains its own security incident update page, the US Department of Education issued a technology security alert to Federal Student Aid partners, and there is a Wikipedia entry on the 2026 Canvas data breach. One caveat: several outlets attribute ShinyHunters campaigns generally to voice phishing, with attackers impersonating IT support. That is the group's established tradecraft, and we have covered how their Oracle PeopleSoft campaign maps to pentest scope, but it is not a confirmed fact about Instructure.

The structural lesson survives regardless: the free, self-service corner of a multi-tenant platform is part of the attack surface of the paid, enterprise, contractually-protected corner. They are the same system.

Boston Scientific: a destructive attack that stopped a factory, not a database

On 25 August 2026, Boston Scientific detected a network outage. It disclosed the incident on 26 August, describing a "global disruption" affecting manufacturing, customer order processing and shipping. The company published its own update on the cybersecurity incident, and MedTech Dive and HIPAA Journal covered the operational and financial fallout.

Two clarifications matter more than the headline, both of them the company's own statements rather than independent findings. Boston Scientific has said that existing implanted cardiac rhythm management devices were not affected, and that new remote activations for some cardiac monitors were disrupted. The second is a real patient-experience consequence but a different thing from devices being compromised, and the distinction is worth stating carefully given what is being described. CrowdStrike was engaged for the response, and on 8 September the company told the SEC the incident was likely to be material to its third-quarter and full-year results, withdrawing its 2026 sales growth and adjusted EPS guidance. Manufacturing, order fulfilment and shipping were subsequently restored. Roughly two weeks of degraded operations is the number to take to your own resilience conversation.

Boston Scientific has not attributed the attack to anyone, and the root cause has not been made public.

fairlife: ransomware that halted production, disclosed via 8-K

fairlife, a Coca-Cola company, disclosed a ransomware incident through an SEC Form 8-K on 16 July 2026. The attack disrupted production; US production at fairlife was suspended and later mostly resumed across four US plants. Coverage appeared in BleepingComputer, Help Net Security and SecurityWeek.

The Anubis ransomware-as-a-service operation claimed the attack, asserting around 1 TB of stolen data and setting a 27 July deadline. Anubis emerged in late 2024 as a rebrand of Sphinx, per Arctic Wolf; the lineage is read from the change in encrypted file extension. Coca-Cola confirmed data was taken but declined to state volume, categories, or the number of individuals affected. The ingress path has not been made public.

One property of Anubis is worth carrying into your own resilience planning, because it changes the arithmetic. The payload ships an optional wipe mode that zeroes file contents in place, reported by Trend Micro, and it can be invoked regardless of whether a victim pays or is still negotiating. Against an operator with that option, "we would restore from backup" is only true if the backups are genuinely out of reach of the same intrusion. That is a testable property of your backup design, not an assumption.

Side by side, the confirmed-versus-reported split is the whole story. Here is each incident with the line drawn explicitly.

The pattern nobody is naming

Line the four up and the most useful fact about the 2026 roundup is not in any of the individual stories. It is the shape they form together: three of four root causes are unpublished, and the fourth is contested.

This is not a failure of journalism. It is a predictable consequence of how disclosure law works. Public companies and regulated entities are compelled to disclose impact: Item 1.05 of SEC Form 8-K for material cybersecurity incidents, HIPAA notification to HHS and affected individuals with categories and headcounts, state breach notification letters. Every one of those instruments is about what happened to whom.

Almost none require you to publish how the attacker got in, and in the SEC's case that is deliberate rather than accidental: the adopting release is explicit that a registrant need not disclose specific technical detail about its incident response, systems or vulnerabilities in a way that would impede remediation. There are strong reasons for that. An ingress description is live evidence in litigation, a factor in an insurance claim, and a roadmap for the next attacker while remediation is still in flight. So organisations disclose impact precisely and ingress approximately, or not at all.

The consequence for you is direct. You cannot build your defence by reading breach coverage and patching what it names, because the coverage does not name a thing to patch. The reflex of "what CVE was it, do we have it, patch it" has nothing to bite on. Even when a CVE is named, as in the Fortinet advisories we covered in our post on perimeter scope, patching answers that advisory and not the next one, and the window between disclosure and exploitation keeps compressing, which we looked at in the 48-hour exploit window.

What is left is the only thing that was ever going to work: test your own equivalent surface, and know which parts of it your testing actually reaches. Which means being specific about where testing stops.

Which of these an external penetration test actually catches

This is where most security vendor posts quietly overclaim, so here is the honest version. The framing question is not "would a pentest have stopped this", which is unanswerable without a root cause. It is: does a scoped external assessment test the attack class this incident belongs to?

DentaQuest: partially in scope. The root cause is unknown, so nobody can say whether a specific test would have surfaced it. What can be said is that the incident's class, internet-facing exposure leading to mass exfiltration of health and identity data, is what external attack surface and exfiltration-path testing address. A scoped external assessment tests for this class: it enumerates what is reachable from the internet, checks authentication and authorisation on those endpoints, and tests object-level authorisation, whether an authenticated user can reach records that are not theirs by manipulating an identifier. Where it stops is equally clear. If the intrusion began with a compromised credential used against a legitimate remote access service, an external test may flag the exposed service and its authentication posture, but cannot confirm that a valid credential is already in an attacker's hands.

Instructure Canvas: in scope, but only with authenticated application testing. This is a scoping lesson rather than a capability boast, and it is the most transferable finding in the roundup. An unauthenticated external scan does not reach a support-ticket flaw inside a free-tier account. It cannot. The tester has to hold an account in that tier, use the feature, and try to cross the boundary from it. Tenant isolation, privilege boundaries between account tiers, and low-friction provisioning paths all require authenticated application and API testing, with credentials issued for each role and tier under test. If your last engagement was an unauthenticated external network test and your product is multi-tenant SaaS with a free or trial tier, the Canvas attack class was not covered. That is not a criticism of the test. It is a description of what that scope buys.

Boston Scientific: largely out of scope. A destructive attack against a manufacturing estate is an OT and ICS segmentation problem plus an operational resilience problem. The questions that decide the outcome are whether the corporate network can reach the plant network, whether the plant can run degraded, how quickly order processing and shipping recover, and whether segmentation holds against an attacker who already has a foothold. An external web and network penetration test is the wrong instrument for all of those. To be explicit: CyberOrbit does not test OT or ICS environments. If your risk concentrates in a plant, a warehouse or a production line, the engagement you need is an OT security assessment from a specialist, and no amount of external testing substitutes for it.

fairlife: partly in scope, mostly not. Ransomware ingress is commonly identity, endpoint and lateral movement: a phished or purchased credential, a foothold on a workstation, escalation, then movement toward the systems whose encryption hurts most. None of that is external assessment work.

The honest qualifier is that "commonly" is not "always", and this actor is the example. Arctic Wolf's own reporting on Anubis, the same source cited above for its lineage, documents affiliates taking initial access by exploiting an internet-facing remote access appliance, CitrixBleed 2 in Citrix NetScaler, before any identity or endpoint step. That front door is class 1 and it is squarely externally testable. So external exposure reduction is not a footnote for this attack class; for some Anubis intrusions it is the step that mattered. What remains true is that nobody has published how fairlife itself was entered, so this is a statement about the actor's documented tradecraft rather than about this incident.

Past ingress, the outcome is decided by MFA coverage, endpoint detection and response, credential hygiene, privileged access management, backup integrity and segmentation, and none of those are things an external test measures. To be explicit: CyberOrbit does not perform internal penetration tests, assumed-breach exercises or purple teaming, and our external assessment does not cover internal lateral movement. Testing that class means engaging a provider who does that work, with an internal foothold granted by design.

So: one class fully in scope, one in scope only with credentials, two outside it entirely. That is the honest ratio, and it is more useful to you than a claim of four for four.

The four attack classes, and how to check your own estate

Strip the company names off and four testable classes remain. For each: the question to ask, what surfaces it, and whether an external assessment reaches it.

Class 1: internet-facing exposure and exfiltration paths. The question: what of ours is reachable from the internet right now, and which of those things can return records in bulk? Surfaced by attack surface enumeration, subdomain and asset discovery, and authentication testing on exposed endpoints. Fully in scope for an external assessment. Run your domain through a subdomain finder and compare the output to your asset inventory, because the gap between those two lists is where this class lives. Then put the hosts you find through a security header checker and an SSL and TLS checker to see how each one answers an unauthenticated request from outside. A free external security check runs the same passes together across your domain.

Class 2: low-friction account provisioning and tenant isolation. The question: can someone who signs up for our free tier, trial or partner sandbox reach another tenant's data, or an internal support or admin surface? Surfaced by authenticated application and API testing with accounts in every tier, explicit tenant isolation test cases, and abuse testing of support and ticketing features. In scope for an external assessment only when the scope includes credentials for each tier, which most engagements do not unless you ask.

Class 3: operational and OT resilience. The question: if our production, manufacturing or fulfilment environment stopped today, how long until it restarts, and can an attacker on the corporate network reach it? Surfaced by OT and ICS assessment, segmentation testing, and resilience exercises. Not in scope for an external web and network test, at CyberOrbit or anywhere else.

Class 4: identity and lateral movement containment. The question: from one compromised laptop and one valid credential, how far can an attacker move before something stops them? Surfaced by internal penetration testing, assumed-breach exercises, purple teaming, and identity review covering MFA gaps, service accounts and privileged access. Not in scope for an external assessment.

Four classes, four questions. Answer them from the report rather than from memory, because memory is reliably generous about what was tested.

Writing the scope statement that covers these classes

Scope language is where good intentions turn into a contract, and where most of the gaps above are quietly created. Three distinctions worth writing down precisely.

An external network penetration test is scoped as a list of public IP ranges and hostnames, tested without credentials. Good scope language names the ranges, states whether cloud-hosted assets and third-party SaaS are in or out, and says explicitly whether newly discovered assets become in scope once found. That last clause is the one people forget, and it decides whether the forgotten staging subdomain gets tested.

An authenticated application penetration test is scoped by application, role and tenant. Good scope language names the application and its API, lists every role including the free or trial tier, states that credentials will be provided for at least two separate tenants so isolation can be tested in both directions, and names the support, ticketing and admin features in scope. If the words "tenant isolation" do not appear in your statement of work, assume it was not tested.

An OT or ICS assessment is scoped by site, network segment and protocol, usually with strict rules about what may be touched while a line is running. Different engagement, different testers, different risk profile. Treat a vendor who offers it as a bolt-on to a web application test with caution.

A single engagement rarely spans all three, and that is fine as long as it is a decision rather than an accident. The failure mode is buying one, believing you bought three, and learning the difference during an incident. The other gap is time: a point-in-time test describes the estate on the day it ran, and class 1 changes weekly as teams deploy. Continuous testing between engagements closes that gap, which we broke down in continuous versus annual testing.

Turning that into a scope statement takes about an hour, and it is the cheapest hour in this whole exercise.

Frequently asked questions

What to do this week

Three actions, ordered by what they cost.

Free: enumerate what is actually internet-facing. Run your primary domain through asset discovery and compare the output to the inventory you believe is accurate. The delta is your class 1 exposure, and finding it costs an afternoon.

Free: confirm which classes your last test covered. Open the statement of work, not the executive summary, and look for the words that distinguish unauthenticated external testing from authenticated multi-tenant testing. Write the answer somewhere your successor will find it.

Paid: book the engagement for the class you have never covered. For most mid-market organisations that is class 2 or class 4; for manufacturers it is class 3. Whichever it turns out to be, buy it from a party with no stake in the grade, because the auditor and the customer questionnaire both ask who ran the test before they ask what it found.

One caveat belongs before a purchase rather than after it. An external assessment covers two of the four classes above, and if your exposure sits in the other two, the engagement you need is a different one. A vendor willing to tell you that at scoping is the one worth trusting with the two it does cover.