The IT Nerd

A 2025 cyberattack targeting Oracle’s healthcare business compromised personal and medical information belonging to nearly 20 million people, including approximately 3 million Texans, according to newly released information from the Texas attorney general, Bloomberg reports.

The stolen information included Social Security numbers, addresses and medical information. Healthcare providers affected by the incident have said compromised records could also include patient names, diagnoses, medications, doctors and test results. Oracle initially notified customers of the breach in March 2025 but did not disclose how many patients were affected.

Attackers gained access to older servers belonging to Cerner, the electronic health records company Oracle acquired for $28 billion in 2022. Oracle told customers that the affected data had not yet been migrated from those legacy systems to Oracle’s cloud infrastructure.

The attack occurred sometime after January 22, 2025 and affected numerous Oracle healthcare customers, including hospitals and health systems. The FBI investigated the breach and attempts by the hackers to extort affected healthcare organizations. The newly disclosed figure provides the first indication of the nationwide scale of the incident.

Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:

“A cloud migration can increase breach risk when the migration server still holds the records attackers want. Oracle Health told affected customers in March 2025 that attackers had used compromised customer credentials to access older Cerner servers after January 22 and copy patient data to a remote location.

“Those servers sat outside Oracle Cloud because the data had not yet been migrated. Oracle acquired Cerner for $28 billion in 2022, but moving the destination did not remove the older copy. That is a data-lifecycle failure.

“I would treat every migration server holding patient data as a live clinical system until its access is separately controlled, its activity is logged, and its final copy is deleted. “Legacy” describes ownership and age. It does not describe the value of the data.

“The scale makes the lesson harder to ignore. Information belonging to nearly 20 million people was compromised, including about 3 million Texans. Hospitals also faced extortion attempts connected to the stolen records.

“Healthcare providers will keep moving records between vendors, platforms, and acquisition-era systems. If temporary migration environments receive weaker controls than production systems, attackers will target the copy that organizations have already stopped watching.”

Damon Small, Board of Directors, Xcape, Inc.:

“Exfiltrating nearly 20 million patient records proves that technical debt in healthcare M&A presents immediate, catastrophic operational liability. When Oracle acquired Cerner for $28 billion, inherited legacy systems remained unmigrated, leaving Social Security numbers and medical histories exposed to credential compromise and cyber extortion. The market reality directly refutes Larry Ellison’s bold assertion that “Oracle is unhackable.” Healthcare IT data is just as critical as the patients themselves, meaning software vendors and healthcare providers must treat electronic health records (EHR) as life-safety biomedical devices rather than basic back-office IT assets. Compromised EHR data unleashes severe risks, including long-term identity theft, medical insurance fraud, and targeted extortion. Security leadership must mandate multi-factor authentication, rigid network isolation, and deep logging across all unmigrated environments while treating legacy infrastructure as high-risk untrusted enclaves.”

“Critical Takeaways:

• Classify EHR systems as mission-critical biomedical devices rather than standard back-office IT infrastructure.
• Treat legacy systems inherited during M&A as untrusted enclaves with enforced multi-factor authentication, zero-trust network isolation, and centralized logging.
• Prepare incident response strategies for high-impact post-exfiltration risks, including patient extortion, insurance fraud, and identity theft.

“It turns out “unhackable” legacy servers are surprisingly easy to hack.”

John Strand, Owner, Black Hills Information Security, Inc.:

“This news story should serve as a warning for anybody looking to acquire another company. Security due diligence absolutely needs to be part of the mergers and acquisitions process. It’s something we spend a lot of time doing for our customers. I don’t like the fact that Oracle is kind of hand-waving this away by saying these were legacy systems that hadn’t been migrated to their secure cloud services yet. They’re still responsible. The moment you acquire a company, you become responsible for all aspects of that company, and that includes its security vulnerabilities.”

I would love to say that Oracle learned its lesson from this. But the cynic in me says not so much. And that’s a shame.

Oracle’s latest Critical Patch Update comes as many security teams continue to struggle with vulnerability fatigue and competing guidance on what to patch first.

Fortra’s Associate Director of Security Research and Development, Tyler Reguly had this to say:

It’s hard not to sound like a broken record these days when talking about security updates. We’re continually seeing large numbers of vulnerabilities and we’re all starting to feel a little burnt out. It’s really making it obvious that there are various camps within our industry that are at odds when it comes to how to address these issues. On one hand, you have the patch-everything crowd. Their polar opposite is the patch-minimally crowd that insists you should focus on only things that are exploited. Finally, you have the prioritize everything, but patch only what is critical. I’m sure there are people that sit at various points across that spectrum as well. 

On top of that, you have the security vendors, AI vendors, standards bodies, and governments dictating prioritization methods, patching speeds and more. What is a person to do? 

Step back and find your calm. I’ve said it before and I say it again, there is a light at the end of this tunnel and the record numbers of patches for record numbers of vulnerabilities will not last. I’m confident of this. Do everything you can to avoid burning out and just work on surviving this onslaught. 

My biggest problem with Oracle has always been the complexity of their installs and their patches. They are not a sysadmin’s best friend. When it comes to applications this complex, tooling is your friend. Whether that is vendor-provided tools or in-house applications, ensure that you can identify your assets, determine their patch level, and easily prioritize what needs to be patched first. If your tooling isn’t helping you achieve this, find new tooling. If you’re chopping wood and the axe just isn’t splitting the log, you don’t keep bashing it into the log hoping it will work. You get a wedge and a sledgehammer, or you sharpen the axe. The same thing is true with your security tools, if they aren’t working for you, fix them or replace them. 

I can’t help but wonder how many people truly understand where risk lies. I think that CISA BOD 26-04 did a great job of helping people to understand how to prioritize based on risk. I think that a 3-day turnaround is very tight when you need to also test your patches, but it helps lay out priorities that make a real difference – is it publicly exposed, is it on the Known Exploited Vulnerabilities list, can it be automated, and does it give complete control. When you can answer these questions, you can start to identify the risk that it plays. Are there other components you can include? Sure, but this is a great start if you don’t really know what risk looks like for your organization. Once you know what risk looks like, you can start to prioritize your patches more appropriately. 

Besides my usual advice of patch all the things, there needs to be a bit of a rethink about the patch regime that exists right now. Until that changes, patching all the things is the best advice that anyone has to go with.

Threat intel company Defused has reported that attackers are exploiting a critical vulnerability which is named CVE-2026-46817 in the Oracle E-Business Suite (EBS) financial application.

The vulnerability in the File Transmission component of EBS’s Oracle Payments product lets unauthenticated malicious actors with HTTP network access to take over vulnerable systems through low-complexity attacks.

Oracle released security updates to address the vulnerability in the May 2026 Critical Security Patch Update and urged that customers patch immediately. The vulnerability has no known previous exploitation or POC, according to Defused.

Sunil Gottumukkala, CEO of Averlon had this comment:

“This is an unauthenticated, low-complexity takeover of Oracle E-Business Suite, which runs many companies’ financials and payments, so the value to an attacker is obvious. EBS is already a known extortion target.

“Oracle shipped the patch in May, there is still no public proof-of-concept, yet attackers are already exploiting it, most likely by reverse-engineering the patch itself. A released fix can become the attacker’s roadmap, which is why the exposure window, the gap between when a patch ships and when it’s actually deployed, is where the real risk lives. Every day a critical vulnerability sits unpatched is another day inside that window.

“Organizations running EBS Payments on affected versions have no time to spare. Patch now, take the File Transmission component off the open internet, and hunt for compromise.”

Denis Calderone, CTO, Suzu Labs had this to say:

“The Cl0p campaign that exploited CVE-2025-61882 across more than a hundred Oracle EBS environments proved two things. First, that Oracle EBS is a target-rich environment full of financial, HR, and procurement data worth serious extortion money. And second, that a lot of organizations are running internet-exposed EBS instances and not patching fast enough. CVE-2026-46817 looks like what follows when that kind of spotlight gets put on a platform. Different actors, different component, but the same exposed attack surface. And this time, the target is Oracle Payments’ File Transmission module, the component that formats and transmits payment instructions, ACH batches, wire transfers, and EFT files directly to financial institutions.

“Some months back we all witnessed Cl0p’s Oracle EBS campaign hit over a hundred organizations using a sophisticated five-step exploit chain through BI Publisher that required SSRF, CRLF injection, path traversal, and malicious XSLT template processing just to get to code execution. That was a fairly sophisticated chained attack. CVE-2026-46817 looks far less complex, more like the front door was just left wide open. There is no authentication on the HTTP endpoint, and no complex exploit chain required. A crafted HTTP request gets you from zero access to full control of the system that formats and transmits ACH batches, wire transfers, and EFT files to financial institutions. Oracle EBS has a definite spotlight on its back. Now we have different actors picking different components, and we’d argue this is potentially much worse.

“The way the File Transmission component handles file operations can be exploited to execute arbitrary code on the server, and the attacker lands with enough privilege to take over Oracle Payments entirely. Oracle scored it a 9.8. File Transmission is the component that opens connections with banks and payment systems to send formatted payment instruction files. Full takeover of that system means potential access to read, modify, or redirect financial transactions.

“What’s got our attention is the exploitation timeline. There is no public proof-of-concept code for this vulnerability. Defused observed active exploitation on their Oracle EBS honeypots over the weekend. This probably means that someone reverse-engineered Oracle’s May patch, built a working exploit, and deployed it operationally in under six weeks. That tells you something about the caliber of actor going after this and how much value they see in owning a payment processing system.

“Oracle EBS is self-hosted, so the attack surface is entirely in your hands. If your Oracle Payments File Transmission endpoints are reachable over HTTP from untrusted network segments, restrict that access immediately to trusted internal sources only. Apply the May 2026 Critical Patch Update. The affected version range is 12.2.3 through 12.2.15, nearly identical to the Cl0p campaign’s target set. And given the six-week window between patch availability and confirmed exploitation, assume compromise and hunt for indicators of unauthorized access to your payment processing infrastructure going back to late May. If you’re running these versions, treat this as an emergency, not a quarterly maintenance item.”

Since organizations are in control, it is up to organizations to patch all the things. And I recommend that organizations do so before there is an attack that comes of this.

A threat actor using the alias “rose87168” claimed responsibility for breaching Oracle Cloud systems, allegedly stealing 6 million user records containing encrypted passwords, authentication keys, and directory credentials. Oracle has denied any breach occurred, stating no customer data was compromised.

To investigate these claims, SOCRadar contacted the threat actor, who provided the below 10,000-record sample. This dataset appears consistent with real Oracle Cloud user information, including structured fields like user IDs, encrypted credentials, and company-specific domains. While SOCRadar cannot confirm the full 6 million record claim, the sample’s format and content seem legitimate and not easily fabricated.

According to Ensar Seker, CISO at SOCRadar:

“Several other security researchers and vendors have also analyzed the sample. At least three Oracle Cloud customers reportedly confirmed their information was present in the leaked data, further supporting its authenticity. These confirmations, along with observed Indicators of Attack (IOAs) such as irregular logins and suspicious file activity, suggest that the breach may indeed be real.

The hacker continues to provide screenshots and additional data fragments to prove the claim. The screen shot illustrates structured user data likely sourced from an identity management system. The actor also claims to have exploited a known vulnerability (potentially CVE-2021-35587), though this has not been confirmed.

Despite the mounting evidence, Oracle maintains its stance that no breach occurred. The company has provided no technical explanation or alternative theory for the leaked data’s origin. This leaves many Oracle Cloud customers in a difficult position—unable to fully assess their exposure without further guidance.

In cybersecurity, even unconfirmed incidents should be treated with seriousness when multiple independent sources identify potential compromise. We recommend organizations remain vigilant, monitor their environments closely, and follow trusted updates from Oracle and the security community.

We urge all Oracle Cloud users to take precautionary steps, including:

• Reviewing security logs from mid-February onward for unusual login attempts or access patterns.
• Auditing user accounts, especially those with administrative privileges.
• Rotating sensitive credentials such as SSO and LDAP passwords or keys.
• Ensuring multi-factor authentication (MFA) is enabled across all accounts.”

Much as I said in this post, this might be the breach that we’re all talking about in 2025. So far, my hunch on this is proving correct.