Oracle's Dual Breach: 6M Cloud SSO Records Stolen, 80 Hospitals Compromised and a Denial That Collapsed Under Evidence

• .What: Two simultaneous breaches of Oracle legacy infrastructure - one targeting Oracle Cloud's federated SSO/LDAP authentication systems via CVE-2021-35587, the other targeting Oracle Health's legacy Cerner electronic health record servers via compromised customer credentials.
• .Who: Oracle Corporation ($57.4B FY2025 revenue). Cloud breach affects 140,000+ tenants across 90 countries. Health breach affects up to 80 hospitals, with 16+ health systems publicly confirmed.
• .How: Cloud breach exploited CVE-2021-35587 (CVSS 9.8) in Oracle Access Manager on a server running Oracle Fusion Middleware 11G last updated September 2014. Health breach used compromised customer credentials against legacy Cerner servers not yet migrated to Oracle Cloud.
• .Data (Cloud): 6 million records - encrypted SSO passwords, LDAP credentials, OAuth2 keys, Java KeyStore (JKS) files, Enterprise Manager JPS keys, usernames, email addresses, tenant configuration data.
• .Data (Health): Patient names, Social Security numbers, dates of birth, medical record numbers, diagnoses, medications, test results, clinical images, treatment details.
• .Actors: rose87168 (Cloud breach - possible Turkish/Azerbaijani regional connections per OSINT, unconfirmed). "Andrew" (Health breach - solo operator, no known group affiliation).
• .Impact: CISA formal guidance issued. FINRA advisory issued. FBI investigating both breaches. CrowdStrike engaged on Cloud breach. Class action lawsuit filed. 262,831 individuals confirmed affected at Union Health alone. Oracle also faces a separate securities fraud class action (Barrows v. Oracle, deadline April 6, 2026) related to AI infrastructure revenue misrepresentations - distinct from the breach litigation but compounding legal exposure.

In January 2025, threat actor rose87168 exploited CVE-2021-35587 - a critical pre-authentication remote code execution vulnerability in Oracle Access Manager - to gain access to Oracle Cloud's Gen 1 (Oracle Cloud Classic) login infrastructure.

The targeted endpoint was login.us2.oraclecloud.com, a production SSO server running Oracle Fusion Middleware 11G with components last updated in September 2014 - more than a decade without a security update on a system handling authentication for 140,000+ enterprise tenants.

CVE-2021-35587 was disclosed in January 2022 with a CVSS score of 9.8. It allows an unauthenticated attacker with network access via HTTP to completely compromise Oracle Access Manager instances.

CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on November 28, 2022, confirming active exploitation in the wild. Oracle did not patch its own server.

According to CybelAngel's investigation, the attacker used a 2020 Java exploit to deploy a web shell and additional malware targeting Oracle's Identity Manager (IDM) database.

The malware exfiltrated data from the IDM database including usernames, email addresses, hashed passwords, SSO credentials, LDAP passwords, OAuth2 keys, Java KeyStore (JKS) files, key files, and Enterprise Manager JPS keys.

The total haul: 6 million records belonging to over 140,000 tenants.

In early March 2025, rose87168 demonstrated access by uploading a file containing their ProtonMail email address to the login.us2.oraclecloud.com endpoint - proof that the server was not only accessible but writable.

CloudSEK confirmed this file upload through archived snapshots dated March 3, 2025.

On March 5, 2025, rose87168 registered an account on BreachForums.

On March 20-21, 2025, rose87168 posted the stolen data for sale on BreachForums, listing over 140,000 affected tenant domains and providing sample data files including a database excerpt, LDAP information, and a company list.

The attacker demanded payment for data removal from affected tenants and offered to exchange data for zero-day exploits.

Oracle responded to the BreachForums post on March 21, 2025, with a categorical denial: "There has been no breach of Oracle Cloud. The published credentials are not for the Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data."

On March 25, rose87168 released an additional 10,000-line sample dataset containing data from 1,500+ unique organizations, including tenant naming patterns ({tenant}-dev, {tenant}-test, {tenant}) that indicated access to development, testing, and production environments.

Oracle took the compromised login.us2.oraclecloud.com server offline approximately 30 days before CloudSEK's March 21 disclosure.

Oracle also used the archive.org exclusion process to remove cached evidence of the compromised server - an action security researcher Kevin Beaumont noted was designed to erase proof of the breach rather than address its consequences.

VALIDATION AND ORACLE'S DENIAL COLLAPSES

Multiple independent security firms validated the breach in the days following Oracle's denial.

CloudSEK published a two-part investigation. Part 1 identified the compromised endpoint and the CVE-2021-35587 attack vector.

Part 2 validated the breach through three independent evidence chains: (1) an archived GitHub repository from Oracle's own "oracle-quickstart" account containing scripts that referenced login.us2.oraclecloud.com for OAuth2 token generation, confirming this was a production endpoint; (2) cross-referencing five organizations from the leaked domain list against publicly accessible GitHub repositories with hardcoded Oracle Cloud credentials, confirming they were genuine Oracle Cloud customers; and (3) OneLogin knowledge-base articles and Rainfocus deployment guides documenting the endpoint in production SAML SSO configurations for Oracle Fusion environments.

Trustwave SpiderLabs stated: "Based on our research and analysis, and that of other researchers, we feel that it is likely that this is a legitimate breach."

Hudson Rock reported hearing directly from Oracle Cloud customers who recognized the leaked data as their own. Security researcher Alon Gal received a 10,000-record sample from rose87168, and three Oracle Cloud customers independently confirmed the data was genuine.

Jake Williams, IANS Research faculty and VP of R&D at Hunter Strategy, stated he had "little doubt" that a compromise of Oracle's environment took place.

Kela, a threat intelligence firm, identified affected organizations across approximately 90 countries, with the highest concentrations in the United Kingdom, United States, Italy, France, and Germany.

Government entities in the US, UK, Italy, Sweden, Norway, Denmark, Finland, Portugal, Belgium, Austria, and Brazil were among the affected tenants.

On April 2, 2025 - 12 days after the public denial - Oracle privately began confirming the breach to select customers in verbal-only communications. Oracle informed clients that CrowdStrike and the FBI were investigating.

The company characterized the compromised environment as a "legacy environment" last used in 2017 and claimed the compromised credentials posed little risk.

BleepingComputer contradicted this claim, confirming that rose87168 had shared data from late 2024 and posted newer records from 2025 on BreachForums. The stolen data was not limited to legacy records.

" The letter did not explain how the breach occurred, what vulnerability was exploited, why sensitive data remained on obsolete infrastructure, or why Oracle waited 18 days after public disclosure to notify customers. No apology was offered.

Kevin Beaumont identified the semantic strategy: "Oracle rebadged old Oracle Cloud services to be Oracle Classic. Oracle Classic has the security incident. Oracle are denying it on 'Oracle Cloud' by using this scope - but it's still Oracle cloud services that Oracle manage.

In a simultaneous but separate incident, a threat actor using the alias "Andrew" breached Oracle Health's legacy Cerner electronic health record servers - systems Oracle acquired through its $28.3 billion purchase of Cerner Corporation in June 2022 and had not yet migrated to Oracle Cloud infrastructure.

The unauthorized access began on or after January 22, 2025, using compromised customer credentials. Oracle discovered the breach on February 20, 2025. The attacker copied data from the legacy Cerner servers to a remote server.

" The notification was signed by Seema Verma, Executive Vice President and General Manager of Oracle Health, but was printed on plain paper without Oracle's official letterhead.

Oracle instructed hospitals to communicate exclusively with Oracle's Chief Information Security Office by phone - not by email or in writing - preventing the creation of documented guidance and establishing a pattern of avoiding written records.

Oracle Health asked healthcare organizations to delay patient notifications.

While Oracle agreed to pay for credit monitoring services and the mailing vendor, the company refused to send notification letters on behalf of affected hospitals - placing the operational and reputational burden of disclosure on the victims rather than the responsible party.

The stolen data includes patient names, Social Security numbers, dates of birth, medical record numbers, diagnoses, medications, test results, clinical images, and treatment details - protected health information under HIPAA.

Up to 80 hospitals were affected. At least 16 health systems have publicly confirmed impact: Union Health (Terre Haute, Ind. - 262,831 individuals), Munson Healthcare (Traverse City, Mich.

), Christus Health (Irving, Texas), LifeBridge Health (Baltimore), Tallahassee Memorial Healthcare, North Kansas City Hospital, Glens Falls Hospital (N.Y.), and Mosaic Life Care (St. ), among others.

The threat actor "Andrew" - who has not claimed affiliation with any known ransomware or extortion group - is demanding millions of dollars in cryptocurrency from affected hospitals and has created clearnet websites to pressure victims into paying. The FBI is investigating.

rose87168 (Oracle Cloud breach): A previously unknown threat actor who joined BreachForums on March 6, 2025. Researcher Louis Hur conducted OSINT analysis through deep and dark web sources and identified potential indicators of Turkish or Azerbaijani regional connections, including Turkish language usage and participation in Azerbaijani chat rooms, as well as possible affiliation with the Telegram channel "Illegal Team" (a Turkish black-hat community).

This attribution is assessed as unconfirmed - it is based on dark web data that may not be reliable, and no authoritative source has validated it. rose87168 has no documented prior campaigns.

Motivation appears to be financial: the actor demanded payment from tenants for data removal and offered to exchange stolen data for zero-day exploits.

"Andrew" (Oracle Health breach): An individual threat actor with no claimed affiliation to any known ransomware or extortion group.

Andrew is conducting direct extortion against individual hospitals, demanding millions in cryptocurrency and operating clearnet websites to increase pressure. No attribution has been established.

The use of compromised customer credentials - rather than a technical exploit - suggests either credential purchasing from dark web markets or targeted credential harvesting.

Oracle Cloud Breach:

• .Encrypted SSO passwords - if the encryption is broken or the keys are obtained (JKS files were also stolen), these passwords grant access to every Oracle Cloud service the tenant uses
• .LDAP credentials - directory service passwords enabling enumeration and access to entire corporate directory structures
• .OAuth2 keys - authentication tokens enabling API-level access to connected applications and services without additional authentication
• .Java KeyStore (JKS) files - containing private keys, certificates, and signing credentials used for cryptographic operations
• .Enterprise Manager JPS keys - Oracle's Java Platform Security keys, used for encrypting and decrypting sensitive configuration data
• .Usernames and email addresses - for 6 million users across 140,000+ tenants
• .Tenant configuration data - development, test, and production environment identifiers exposing organizational infrastructure

The combination of encrypted passwords and the encryption keys themselves (JKS files, JPS keys) means the attacker may possess both the ciphertext and the means to decrypt it.

Calling these passwords "encrypted" provides false assurance when the encryption keys were stolen alongside the passwords.

Oracle Health Breach:

• .Patient names - full legal names tied to medical records
• .Social Security numbers - permanent identifiers that cannot be changed and enable identity theft, tax fraud, and medical identity fraud
• .Dates of birth - combined with SSNs, sufficient for identity theft
• .Medical record numbers - internal identifiers enabling targeted access to patient histories
• .Diagnoses and medications - protected health information with no expiration; disclosure can affect insurance, employment, and personal reputation permanently
• .Test results and clinical images - laboratory, imaging, and diagnostic data
• .Treatment details - surgical procedures, therapy records, and care plans

The healthcare data is irreversible. Unlike passwords or credit card numbers, medical histories cannot be reset. A patient whose cancer diagnosis, psychiatric treatment, or HIV status is exposed faces permanent privacy loss.

1. A four-year-old CVSS 9.8 vulnerability remained unpatched on Oracle's own production server.

CVE-2021-35587 was disclosed in January 2022 and added to CISA's Known Exploited Vulnerabilities catalog in December 2022. Oracle - the vendor that issued the patch - did not apply it to its own infrastructure.

The compromised server was running Oracle Fusion Middleware 11G with components last updated in September 2014. This is a decade-old software stack running a known-exploited vulnerability on a production SSO server handling authentication for 140,000+ enterprise tenants.

This is not a sophisticated attack. It is a configuration management failure at a company that sells security products.

2. Legacy Cerner servers remained exposed three years after acquisition.

Oracle acquired Cerner for $28.3 billion in June 2022. Nearly three years later, legacy Cerner servers containing protected health information had not been migrated to Oracle Cloud infrastructure and were accessible via compromised customer credentials.

The migration timeline failure converted a routine integration project into a data breach affecting 80 hospitals.

3. No multi-factor authentication on the compromised Oracle Cloud endpoint. The login.us2.oraclecloud.com server was accessible via HTTP without MFA enforcement on administrative access.

CVE-2021-35587 is a pre-authentication vulnerability - MFA on user-facing authentication would not have stopped this specific exploit.

But MFA on the administrative and management interfaces of the SSO infrastructure would have limited post-exploitation lateral movement and data exfiltration.

4. Credential hygiene failure at Oracle Health customer sites. The Health breach was initiated through compromised customer credentials - not a vulnerability in Oracle Health's software.

This indicates either weak credential policies at customer sites, absence of MFA on Cerner server access, or credentials obtained from prior compromises and dark web markets.

Oracle Health bears responsibility for not enforcing MFA on access to servers containing PHI, regardless of the customer's credential practices.

5. No data loss prevention or exfiltration detection. The Cloud breach went undetected from January to late February 2025 - a minimum dwell time of approximately 30 days. Six million records were exfiltrated from the Identity Manager database.

The Health breach went undetected from on or after January 22 to February 20 - a 29-day window. Neither breach triggered automated exfiltration alerts on systems containing the most sensitive data Oracle manages: authentication infrastructure and patient health records.

6. Evidence destruction instead of transparency. Oracle used the archive.org exclusion process to remove cached evidence of the compromised login.us2.oraclecloud.com server.

Beaumont noted Oracle "forgot to remove the second URL." This action prioritized narrative control over customer protection and directly undermined the security community's ability to assess the breach's scope.

7. Verbal-only breach communications. For both breaches, Oracle prioritized avoiding documented liability over informing affected parties. The Cloud breach was confirmed only through verbal calls.

The Health breach notification instructed hospitals to communicate exclusively by phone. This pattern is designed to minimize discoverable evidence in litigation - not to protect customers.

CVE IDs:

• .CVE-2021-35587 - CVSS 9.8, Pre-auth RCE in Oracle Access Manager (CISA KEV since Nov 2022)

Compromised Endpoints:

• .login.us2.oraclecloud[.]com - Oracle Fusion Middleware 11G, last updated September 2014

Threat Actors:

• .rose87168 (Cloud breach) - Registered BreachForums March 5, 2025
• ."Andrew" (Health breach) - Solo operator, cryptocurrency extortion via clearnet sites

Data Exposed (Cloud):

• .6 million records from Oracle Identity Manager database
• .140,000+ tenants across ~90 countries
• .Encrypted SSO passwords, LDAP credentials, OAuth2 keys, JKS files

Data Exposed (Health):

• .Patient SSNs, diagnoses, medications, clinical images from up to 80 hospitals

Evidence Destruction:

• .Oracle used archive.org robots.txt exclusion to remove cached evidence

Validation Sources:

• .CloudSEK, Trustwave SpiderLabs, Hudson Rock, CybelAngel independently confirmed

United States:

• .HIPAA (Oracle Health breach) - 45 CFR 164.400-414 requires covered entities and business associates to notify affected individuals within 60 days of discovering a breach of unsecured PHI. Oracle Health is a business associate to the affected hospitals. The instruction to delay notifications may itself constitute a HIPAA violation. HHS OCR fines range from $100 to $50,000 per violation, with an annual maximum of $2.1 million per violation category. With 80 hospitals and hundreds of thousands of patients affected, aggregate exposure is substantial.
• .SEC Regulation S-K / 8-K - Material cybersecurity incidents require disclosure within four business days. Oracle has not filed an 8-K for either breach. Given the scale (6 million records, 140,000 tenants, 80 hospitals), materiality is difficult to argue against. A class action lawsuit filed March 31, 2025, alleges Oracle failed to meet disclosure obligations.
• .FTC Act Section 5 - Oracle's public denial of the Cloud breach while privately confirming it to customers, combined with evidence destruction via archive.org, could constitute deceptive practices under Section 5. The FTC has previously pursued companies for misleading breach-related statements.
• .CCPA/CPRA - California residents among the 6 million affected Cloud users and hospital patients have rights to notification and may pursue statutory damages of $100-$750 per consumer per incident. With affected individuals potentially numbering in the hundreds of thousands in California alone, exposure could reach nine figures.
• .State breach notification laws - SSN exposure triggers mandatory notification in all 50 states. The Health breach confirmed SSN exposure. The Cloud breach exposed encrypted passwords and encryption keys. Multiple states have 30-to-60 day notification deadlines. Oracle's instruction to delay notifications creates compounding legal exposure for every day of delay at every affected hospital in every state.
• .FINRA - FINRA issued a specific advisory to member firms about the Oracle Cloud breach, indicating financial services organizations are among affected tenants. Gramm-Leach-Bliley Act Safeguards Rule obligations apply to any financial institution whose authentication credentials were compromised.

European Union:

• .GDPR Article 5(1)(f) - Integrity and confidentiality principle. Oracle, as a data processor for EU-based tenants, failed to ensure appropriate security of personal data. Running a decade-old unpatched server as the authentication gateway for EU customer data is a prima facie violation.
• .GDPR Article 32 - Security of processing. The absence of patching, the use of deprecated software, and the lack of exfiltration detection on systems processing EU personal data fail to meet the standard of "appropriate technical and organizational measures."
• .GDPR Article 33 - 72-hour notification to supervisory authority. Oracle's 18-day delay from public disclosure to customer notification, and longer delay from discovery to any notification, exceeds the 72-hour requirement. Kela identified affected organizations in the UK, Italy, France, Germany, Sweden, Norway, Denmark, Finland, Portugal, Belgium, and Austria.
• .GDPR Article 34 - Communication to data subjects. Given the nature of the data (authentication credentials, encryption keys), this is a high-risk breach requiring direct notification to affected individuals. There is no public evidence Oracle notified EU data subjects individually.
• .Fines - Up to EUR 20 million or 4% of annual global turnover, whichever is higher. Oracle's FY2025 revenue was $57.4 billion. Four percent of global turnover equals approximately $2.3 billion. Multiple EU member states have affected tenants, enabling parallel enforcement actions.

United Kingdom:

• .UK GDPR / DPA 2018 - UK organizations are among the most heavily affected tenants. ICO enforcement powers include fines up to GBP 17.5 million or 4% of global turnover.

Saudi Arabia:

• .PDPL - Saudi organizations using Oracle Cloud services may have had credentials exposed. Fines up to SAR 5 million (approximately $1.3 million). NCA Essential Cybersecurity Controls apply to government tenants.

UAE:

• .Federal Decree-Law No. 45/2021 (PDPL) - UAE organizations among affected tenants. CPX, the Abu Dhabi-based cybersecurity firm, published specific technical analysis of the breach's impact on regional organizations. Fines up to AED 10 million.
• .DIFC Data Protection Law / ADGM Data Protection Regulations - Financial free zone entities using Oracle Cloud face additional regulatory obligations.

Switzerland:

• .revFADP - Imposes personal liability on individuals, not just corporations. Oracle executives responsible for the delayed notification and evidence destruction could face individual fines up to CHF 250,000.

1. The full scope of the Oracle Health breach is unknown. Oracle has confirmed up to 80 hospitals may be affected, but only 16 health systems have publicly disclosed. The total number of affected patients has not been established.

Union Health alone confirmed 262,831 individuals. Extrapolating across 80 hospitals, the total could range from several hundred thousand to several million patients.

2. Whether rose87168 has decrypted the stolen SSO passwords is unconfirmed. The attacker exfiltrated both encrypted passwords and the JKS files and JPS keys that could enable decryption.

Whether the attacker has successfully decrypted the credentials, sold them to a third party, or is still attempting decryption is unknown.

The difference between "encrypted passwords were stolen" and "plaintext passwords were stolen" is the difference between a contained credential exposure and a supply chain compromise affecting 140,000 organizations.

3. Oracle's April 7 notification states the stolen passwords were "encrypted and/or hashed" - the "and/or" formulation indicates Oracle itself may not know which passwords were encrypted and which were merely hashed, or may be deliberately obscuring whether any were stored in a weaker format.

4. Whether any of the 140,000+ affected tenants experienced secondary compromises through the stolen credentials has not been reported.

Given the 30+ day dwell time before detection and the additional weeks before affected organizations were notified, threat actors had ample time to use exfiltrated credentials for downstream attacks.

5. The relationship between the Cloud and Health breaches is unclear. Both occurred in January 2025 within Oracle's legacy infrastructure. Both were discovered approximately 30 days later.

Whether this is coincidence, whether one breach enabled the other, or whether both were discovered through the same internal investigation has not been disclosed.

6. The full financial impact to Oracle is unknown. Direct costs (investigation, remediation, credit monitoring, legal defense) have not been disclosed. The class action lawsuit filed March 31, 2025, and any GDPR enforcement actions could take years to resolve.

1. Patch known-exploited vulnerabilities on your own infrastructure. CVE-2021-35587 had been public for three years and on CISA's KEV list for over two years when it was exploited. Oracle - the vendor that wrote the patch - did not apply it to its own production server.

Every organization, including the vendor itself, must maintain a vulnerability management program that prioritizes CISA KEV entries for immediate remediation. There is no credible excuse for a three-year patching gap on a CVSS 9.8 vulnerability on your own SSO infrastructure.

2. Decommission or migrate legacy systems on a defined timeline. The Cloud breach targeted Oracle Fusion Middleware 11G last updated in 2014. The Health breach targeted Cerner servers acquired in 2022 and not yet migrated.

Both were legacy systems that Oracle knew were at end-of-life. Organizations must enforce hard deadlines for migration or decommissioning of legacy systems containing sensitive data - with executive accountability for missed deadlines.

3. Enforce MFA on all access to systems containing authentication data or PHI. The Cloud SSO server and the Cerner health record servers both lacked adequate access controls.

Phishing-resistant MFA (FIDO2/WebAuthn hardware keys) should be mandatory for any system that stores, processes, or transmits authentication credentials, encryption keys, or protected health information.

4. Deploy data loss prevention and exfiltration monitoring on identity and healthcare databases. Six million records were exfiltrated from the IDM database and patient data was copied from Cerner servers - both without triggering automated alerts.

Database activity monitoring, anomalous query detection, and egress filtering should be deployed on any system containing identity data or PHI.

5. Provide transparent, written, timely breach notification. Oracle's verbal-only communications, plain-paper notifications, and instructions to delay disclosure violate the spirit and, in many jurisdictions, the letter of breach notification laws.

Organizations must notify affected parties in writing, within legally mandated timeframes, with specific information about what was compromised, what the risk is, and what remediation steps are available.

6. Never destroy evidence of a breach. Oracle's use of the archive.org exclusion process to remove cached evidence of the compromised server is a disqualifying act for any organization that positions itself as a trusted custodian of enterprise data.

Evidence preservation, not destruction, is the legal and ethical obligation of a breached organization.

CloudSEK, BleepingComputer, Dark Reading, Cybersecurity Dive, SecurityWeek, The Register, Trustwave SpiderLabs, CybelAngel, Hudson Rock, Kevin Beaumont (DoublePulsar), CISA, FINRA, Becker's Hospital Review, HIPAA Journal, CSO Online, Hackread, SOCRadar, CPX, Orca Security, Kela, TechCrunch, Bloomberg, American Bar Association, NVD (CVE-2021-35587), Sophos, Arctic Wolf, Sygnia, Black Kite, Beazley Security, Fierce Healthcare, Bank Info Security, Clearwater Security, TechRadar, Computing.co.uk, Security Magazine