The Biggest Supply Chain Hack of 2025

In March 2025, a threat actor calling themselves ‘rose87168’ posted an offer on BreachForums: 6 million records stolen from Oracle Cloud, affecting over 140,000 organizations worldwide. The data included encrypted passwords, authentication keys, and the cryptographic files needed to potentially decrypt them.

Oracle’s response? They denied it happened.

‘There has been no breach of Oracle Cloud,’ the company stated publicly. ‘The published credentials are not for Oracle Cloud. No Oracle Cloud customers experienced a breach or lost any data.’

Then the evidence started piling up. Security researchers at CloudSEK verified the stolen data. Multiple affected companies confirmed the samples contained genuine information from their accounts. The compromised server — login.us2.oraclecloud.com — was quietly taken offline.

Oracle eventually began privately contacting affected customers. The breach was real. And it exposed a fundamental truth about cloud security: when your provider gets breached, you’re breached too.

What Actually Happened

The attacker exploited a vulnerability in Oracle Access Manager — specifically CVE-2021-35587, a critical flaw that allows unauthenticated attackers to completely take over Oracle Access Manager systems via HTTP.

Here’s what makes this breach particularly damning: the vulnerability was disclosed in 2021 and patched in January 2022. But the server rose87168 compromised was running Oracle Fusion Middleware 11G that hadn’t been updated since September 2014.

A decade of missed patches. On a production authentication server. For 140,000+ enterprise customers.

The attacker gained access to Oracle Cloud’s Single Sign-On (SSO) and Lightweight Directory Access Protocol (LDAP) systems — the core infrastructure that manages how users authenticate across Oracle’s cloud services.

What Was Stolen

The stolen data includes:

• Encrypted SSO passwords — used for single sign-on authentication across Oracle Cloud services
• Encrypted LDAP passwords — used for directory services and user authentication
• Java KeyStore (JKS) files — containers for cryptographic keys and certificates
• Key files — cryptographic keys used for authentication and encryption
• Enterprise Manager JPS keys — used for Java Platform Security within Oracle applications
• OAuth2 keys — used for authorization across connected applications
• Tenant data — information about organizations using Oracle Cloud

The critical concern: if the encrypted passwords can be decrypted using the stolen key files, attackers could gain access to the Oracle Cloud environments of over 140,000 organizations.

The Extortion Campaign

Rose87168 didn’t just steal the data — they weaponized it. The attacker:

• Listed the data for sale on BreachForums, accepting payment or zero-day exploits in exchange
• Offered to remove specific organizations’ data — for a ransom payment
• Solicited help decrypting the passwords — offering incentives to anyone who could crack the encryption
• Created a Twitter/X account to follow Oracle-related accounts, presumably for harassment or pressure
• Built tracking infrastructure — monitoring how many victims viewed the stolen data samples

This is the modern playbook: steal the data, then squeeze victims from multiple angles.

Oracle’s Handling Made It Worse

Oracle’s initial denial — in the face of mounting evidence — damaged trust far more than the breach itself.

Security researcher Kevin Beaumont pointed out that Oracle appeared to be engaging in ‘wordplay.’ The company stated there was no breach of ‘Oracle Cloud’ — but the compromised servers were Oracle Cloud Classic (Gen1), a different platform that is still Oracle-managed cloud services. The distinction felt like a technicality designed to avoid accountability.

When Oracle finally began privately confirming the breach to customers, it was weeks after the initial disclosure. Organizations had already been in the dark about whether their data was compromised, unable to take protective action.

The lesson: when your cloud provider gets breached, you may be the last to know.

This Wasn’t Even the Only Oracle Breach

While the rose87168 incident was unfolding, Oracle was dealing with another separate breach involving Oracle Health (formerly Cerner).

In that incident, a different attacker named ‘Andrew’ accessed legacy Cerner data migration servers and began extorting Oracle Health customers — including up to 80 hospitals. Healthcare providers including Lake Regional Health System in Missouri, OSF Saint Clare Medical Center in Illinois, and others have confirmed patient data was stolen.

Then came the third breach: In late 2025, the CL0P ransomware group exploited zero-day vulnerabilities in Oracle E-Business Suite (CVE-2025-61882 and CVE-2025-61884), stealing sensitive data from over 100 organizations including Harvard University, The Washington Post, Cox Enterprises, and Logitech.

Ransom demands in that campaign reached $50 million. Extortion emails were still being sent to victims as recently as January 2026.

Why This Matters for Your Business

You might think: ‘We don’t use Oracle Cloud, so this doesn’t affect us.’ But the lessons here apply to every organization that relies on cloud services — which is almost everyone.

1. Your Cloud Provider’s Security IS Your Security

When you move to the cloud, you’re outsourcing infrastructure — but you can’t outsource responsibility. If your cloud provider gets breached, your data gets breached. Their security failures become your security failures.

This is true whether you use Oracle, AWS, Azure, Google Cloud, Salesforce, or any other provider.

2. You Can’t Assume Providers Are Patched

Oracle — one of the largest enterprise software companies in the world — was running a production authentication server on software that hadn’t been patched since 2014. If they can miss a decade of patches on critical infrastructure, any provider can.

You need to ask your cloud providers about their patching practices. Get it in writing. Verify when possible.

3. Supply Chain Attacks Are Increasing

Attackers have figured out that hitting one cloud provider gives them access to thousands of victims simultaneously. This is far more efficient than attacking organizations one at a time.

CloudSEK called this ‘the biggest supply chain hack of 2025’ for a reason. Expect more attacks like it.

4. Breach Notification May Come Late — Or Not At All

Oracle denied the breach for weeks before privately confirming it to customers. Other providers may do the same. By the time you find out, attackers may have already used your credentials.

You need your own monitoring and detection capabilities. You can’t rely solely on your provider to tell you when something is wrong.

5. Encrypted Doesn’t Mean Safe

The stolen Oracle Cloud passwords were encrypted. But the attacker also stole the key files that could potentially decrypt them. ‘Encrypted’ provides false comfort if the encryption keys are compromised alongside the data.

What You Should Do

Whether you use Oracle Cloud or any other cloud service, take these steps:

Immediate Actions

• Rotate credentials — Change all passwords, API keys, and authentication tokens for cloud services
• Enable MFA everywhere — Multi-factor authentication limits damage even if passwords are compromised
• Review access logs — Look for unusual authentication attempts or access patterns
• Audit service accounts — Identify and secure any privileged accounts that could be targeted

Ongoing Practices

• Monitor for credential exposure — Use dark web monitoring to detect if your credentials appear in breach dumps
• Inventory your cloud dependencies — Know every cloud service your organization relies on
• Require security documentation from providers — Ask about patching schedules, incident response, and breach notification policies
• Plan for provider breaches — Have a response plan for when (not if) a cloud provider you use gets compromised
• Segment and limit access — Don’t give cloud services more access than they need

For Oracle Cloud Users Specifically

• Contact Oracle — Determine if your tenant was affected
• Reset all LDAP and SSO credentials — Focus especially on privileged accounts
• Regenerate JKS files and certificates — Assume cryptographic materials may be compromised
• Review authentication logs — Look for unauthorized access dating back to early 2025
• Update SASL hashes — Migrate to more secure authentication methods where possible

The Cloud Security Reality Check

The cloud offers enormous benefits: scalability, reliability, reduced infrastructure burden. But it also concentrates risk. When a major cloud provider fails, thousands of organizations fail with them.

Oracle is a $50 billion company with vast security resources. They still ran a production authentication server on decade-old, unpatched software. They still got breached. They still denied it until the evidence was overwhelming.

If it can happen to Oracle, it can happen to any cloud provider. Your security strategy needs to account for that reality.

We Can Help

At Pendergrass Consulting, we help businesses understand and manage their cloud security risks. Our services include:

• Cloud security assessments — Evaluating your cloud configuration and identifying vulnerabilities
• Vendor security reviews — Helping you understand the security posture of your cloud providers
• Incident response planning — Preparing for breaches, including third-party breaches
• Credential monitoring — Detecting when your credentials appear in breach dumps
• Security awareness training — Ensuring your team understands cloud security risks

Cloud breaches are becoming more common and more damaging. Don’t wait until your provider sends you a breach notification letter.

Contact us today to discuss your cloud security strategy.

Pendergrass Consulting provides cybersecurity, IT support, and technology consulting services throughout the Triangle area, including Raleigh, Durham, Chapel Hill, Cary, Apex, and the surrounding communities.