Nearly 20 Million Patients Exposed: Stolen Credentials Unlocked Oracle Health's Unmigrated Cerner Servers

For more than a year, the federal breach portal at HHS listed the Oracle Health incident at 501 people. That number is a placeholder. Covered entities use it when they know a breach crossed the reporting threshold but don't yet know how far. On October 2, 2026, the Texas Attorney General's office received an updated figure, and Bloomberg reported what it said: almost 20 million people affected, about 3 million of them in Texas.

So the count went from 501 to nearly 20 million. The break-in itself was simple: someone had a working customer login, and two old Cerner servers that were still waiting to move to Oracle Cloud accepted it.

I've spent a lot of incident response hours inside migrations that ran long. This one deserves a slow read, because what failed wasn't exotic. It's the situation most hospital IT teams are in right now.

What's actually confirmed

A lot of the 2025 coverage was muddled, so it's worth separating what the filings say from what was claimed on forums.

The access. According to Oracle's notices to providers, as summarised by HIPAA Journal and CyPro, an unauthorised person used stolen customer credentials to log in to two legacy Cerner servers that had not yet been migrated to Oracle Cloud. Nobody has reported a zero-day or exploit chain. It was a valid login on the wrong machine.

The window. Access began as early as January 22, 2025. Oracle has said it became aware around February 20, 2025, while its breach notice cites March 7. Oregon's regulatory filing lists the breach period as January 22 to April 1, 2025. If that end date reflects attacker activity and not just a reporting convention, someone may have had access for about six weeks after Oracle first noticed.

The data. Names, Social Security numbers, and medical record content: diagnoses, medications, test results, medical images, record numbers and physician names. Christus Health's patient letter, quoted by Teiss, lists most of the same fields.

The count, state by state. HIPAA Journal has tallied the state filings so far:

• Texas: 2,992,244
• Oregon: 1,978,661
• South Carolina: 283,903
• Washington: 69,238

That's about 5.3 million across four states. The rest of the roughly 20 million is spread across states that haven't published or don't require numeric filings. Oracle has not disclosed a total.

The blast radius. CyPro counts at least 29 hospital and health systems that have reported being affected. A plaintiff's lawyer said Oracle's own attorneys put the possible number at up to 80 hospitals. Munson Healthcare in Michigan confirmed more than 100,000 patients on its own.

The extortion. HIPAA Journal reports that a hacker calling themselves "Andrew" demanded cryptocurrency from providers to keep the data unpublished, and said they weren't tied to any known ransomware group. Don't confuse this with "rose87168," who separately claimed in March 2025 to have stolen about 6 million records from Oracle Cloud's login servers. Oracle has consistently denied that Oracle Cloud was breached. Some outlets, Teiss included, have merged the two stories. From what's in the filings, they're separate threads, and the Cerner incident is the one with the 20 million figure.

The migration gap nobody budgets for

Oracle bought Cerner for $28.3 billion in 2022, then started moving customers from Cerner's legacy hosting to Oracle Cloud Infrastructure. That kind of migration takes years, and while it runs, a provider's data lives in two places with two very different levels of care.

I've watched the same thing happen at three hospital groups I've worked with, and it goes like this. The new environment gets the security budget, the architecture reviews, the logging pipeline, and the conditional access policies. The old environment gets a date. Once a server has a decommission date, nobody wants to spend on it. You don't onboard a box into the new SIEM if it'll be gone in two quarters. You don't rotate service credentials on a system you're about to delete. You don't redo network segmentation for hardware that's leaving.

Then the date slips. It always does. And the server sits there, still holding production patient records and still accepting the old logins, while the team that understood it has moved on to the new platform.

That's my reading of "not yet migrated." It doesn't mean nobody cared. It means a deadline made everyone treat the server as already gone. The lawsuit filed in the Western District of Texas by Michael Toikach alleges inadequate segmentation and a lack of monitoring. Those are allegations, not findings. They are still the failures I'd expect on a server that has been half-retired for a year.

Whose credential was it?

This is the part I keep coming back to. These were customer credentials. A hospital, or someone working for one, had a login that reached a server Oracle operated. Oracle told providers that each covered entity has to decide for itself whether the incident counts as a reportable HIPAA breach and send its own notifications. The provider owned the identity. The vendor owned the server. Neither side fully owned the question of whether that identity should still be able to reach that server, from that location, at that hour.

We wrote about the same seam earlier this month in Veradigm's second vendor-credential breach, and the pattern repeats in Florida's DAVID portal compromise, where one police department's login opened a statewide database. Shared platforms authenticate the customer and then assume the customer's credential hygiene is the customer's problem. The customer assumes the platform watches for misuse. The attacker lives in that gap.

It also explains why detection took about a month and notification took much longer. HIPAA Journal reports that some providers, including OSF Saint Clare and NKC Health, didn't receive their lists of affected patients until November 2025. That's roughly eleven months after access began. A login from a real customer account looks like normal work, so nothing alerted on it. Once the team knew something was wrong, they still had to rebuild which records belonged to which customer, on servers nobody had fully documented.

What the 501 placeholder tells you

That HHS number deserves more attention than it got. A 501 entry means "we know it's big and we don't know how big." This one stayed at 501 through most of 2025 and well into 2026.

There's a practical lesson for IR teams. If you can't scope a breach of a system in months, you couldn't have monitored it either. Scoping needs the same things detection does: knowing what data sits where, who can reach it, and what normal access looks like. A server that takes a year to scope after the fact was never in a state where anyone would notice a stranger reading it.

In my experience, when a scoping effort takes this long, it's usually because the data model on the legacy side is undocumented and the people who knew it have left. Neither problem is fixed by a patch.

Where a tripwire would have fired

Here's the uncomfortable part for anyone who sells detection, us included. A valid login doing what valid logins do will get past most controls. EDR has nothing to flag. MFA, if it was ever configured on those servers, was either missing or already satisfied. The SIEM sees an authenticated session from a known customer account. Behaviour analytics might catch a big export, but only if the legacy box ships logs to the analytics platform. On a server waiting to be decommissioned, it probably doesn't.

So the only signal that doesn't depend on catching the attacker behaving oddly is the attacker touching something nobody legitimate should touch. On a legacy system in migration limbo, that's cheap to set up, and it doesn't need the server's logs to flow anywhere new.

Sentinel records. Put a small number of fake patient records in each legacy database: realistic names, plausible MRNs, SSNs from ranges that are never issued. No clinician will ever open them, because no real patient matches. If one is queried, exported, or shows up in an extortion sample, you know which server leaked and roughly when. In a case like this, a sentinel record in the extortion sample would also have shortened the eleven-month scoping fight, because the provider could have matched it to a specific server on day one.

Honeytoken credentials on the box. Legacy servers collect old config files, connection strings, and service account passwords in scripts. Seed a few that look exactly like those, pointing at nothing real. An intruder who has a foothold and goes looking for the next hop will try them. A real admin won't, because no real process uses them. That's the property that matters: zero false positives, because the only person who'd ever use the bait is someone who shouldn't be there. It's the same reason forgotten service accounts made such good targets in the Chilean password spray: an account nobody owns is one nobody is watching, unless you plant it on purpose.

Decoy services next to the legacy segment. If an attacker gets onto the network the old servers sit on, they'll scan for what else is nearby. A MineField decoy that looks like another unmigrated database or file share gives them something to probe, and gives you an alert that doesn't depend on whether anyone ever wired the legacy segment into the new monitoring stack.

None of this needs the legacy server to be "modern." That's the point. You don't have to bring a server into the new tooling, which nobody will approve for a box with a decommission date, to make it noisy when the wrong person touches it.

If you're mid-migration right now

You almost certainly are. Most health systems have at least one EHR, imaging archive, or billing platform somewhere between "old hosting" and "new cloud." A short list of things I'd do this week:

1. List every system with a decommission date that has already slipped. Not the planned ones. The overdue ones. Those are your Cerner servers.
2. For each one, find out which identities can still log in. Include vendor accounts, customer accounts, and service accounts set up during the migration itself. Migration projects create credentials and almost never clean them up.
3. Check whether its logs reach anyone. If authentication events from that server don't reach a human or an alerting rule today, treat it as unmonitored, whatever the architecture diagram says.
4. Seed it. Sentinel records in the data, a couple of honeytoken credentials on disk, a decoy on the segment. This takes about an hour per system, and it's the cheapest monitoring you'll ever add.
5. Agree on who calls whom. Before an incident, settle with your vendor who gets alerted when a customer credential is used somewhere odd. In this case, that question took months to answer.

The number will move again

Twenty million probably isn't final. The HHS portal still needs updating, more state filings will land, and the class actions in Missouri and Texas will produce discovery that may revise the timeline. I'd bet on the count rising, not falling.

The lesson is already clear, though. Nobody exploited a bug here. A real login reached a server that everyone had stopped thinking about, and patient records for a population bigger than most US states walked out. If you have servers waiting on a migration date, and want to see how sentinel records and decoy credentials fit into infrastructure you can't afford to rebuild, book a walkthrough with our team.