Oracle Cloud Data Breach Claim: What Is Confirmed, What Is Disputed and What to Do

Key takeaways

• The claim dates to March 2025, not 2026.
• Oracle denied a breach of Oracle Cloud, but reporting later pointed to a legacy environment.
• The actor's cited flaw, CVE-2021-35587, is a patched, older vulnerability, and its role is unconfirmed.
• Inventory legacy systems, patch, rotate credentials and report incidents to CERT-In.

What was claimed

In March 2025 a threat actor using the name "rose87168" posted on a hacking forum claiming to have stolen data from Oracle Cloud's single sign-on and LDAP infrastructure. The post offered about six million records, said to include encrypted passwords, key files and tenant details, and demanded payment. An earlier version of this article gave the date as 2026, which was wrong. The incident dates to 2025.

Oracle's response, and why it was disputed

Oracle publicly denied that its Oracle Cloud had been breached and said the published credentials were not from Oracle Cloud. Several organisations and security researchers disputed this after examining sample data, and reporting later said Oracle had told some customers that an older, legacy environment had been affected. Oracle's wording drew criticism because it appeared to separate "Oracle Cloud" from the legacy systems involved. Because the facts were reported by several outlets and not all confirmed by Oracle, check the latest statements from Oracle, CISA and CERT-In before you quote any of this as settled.

The vulnerability behind the claim

The actor claimed to have exploited a flaw in Oracle Fusion Middleware, specifically Oracle Access Manager, tracked as CVE-2021-35587. It is a long-standing vulnerability with a patch available since 2021. The record is on the National Vulnerability Database. Whether this flaw was the actual entry point in the incident is the actor's claim, and has not been independently confirmed in the sources used here.

Why this matters even if details are disputed

• Old systems stay exposed. A vulnerability that is years old can still be exploited if a server was never patched or retired.
• Shared sign-in is a single point of risk. Stolen SSO material can affect many applications at once.
• Vendor statements are not evidence. A "no breach" claim can be technically narrow. Customers should test their own exposure.
• Credential material ages badly. Even hashed or encrypted passwords can be attacked offline.

What organisations should do

1. Inventory systems, including legacy and forgotten ones, and retire what is not needed.
2. Patch or mitigate known vulnerabilities, using the NVD and vendor advisories to prioritise.
3. If you run Oracle Access Manager or related products, check vendor guidance and review logs for suspicious access.
4. Rotate credentials, keys and certificates that could have been exposed, and enable multi-factor authentication.
5. Monitor for your domain in leak reports and follow incident response procedure if you see it.
6. Report incidents to CERT-In, which requires reporting of cyber incidents within set time limits for covered entities.

Lessons for defenders and learners

This case teaches vulnerability management, asset inventory and incident communication more than any single technique. For other recent breaches, see our write-ups on the Nokia data breach claim and the Samsung Germany breach.

Next steps

To learn how to manage vulnerabilities and respond to incidents, see the SOC analyst course.

Related reading

• How Unpatched Active Directory Flaws Expose Your Microsoft Servers | The Silent Threat
• Deloitte Hacked: Brain Cipher Ransomware Group Allegedly Steals 1 TB of Data
• Krispy Kreme Data Breach 2025 | What Data Was Stolen and How to Protect Yourself