Back to Blog

The Oracle Cloud Breach — and Why the Denial Mattered More

In March 2025, a threat actor using the handle rose87168 offered roughly six million records for sale, claiming they had been taken from Oracle Cloud’s federated single sign-on and LDAP systems, affecting more than 140,000 tenants. The listing included Java KeyStore files, encrypted SSO passwords, hashed LDAP credentials and Enterprise Manager JPS keys.

Oracle denied a breach of Oracle Cloud. Both statements were, in a narrow sense, true — and that is precisely what makes this incident worth understanding.

What was actually compromised

The affected environment was Oracle Cloud Classic — Oracle’s Gen 1 platform — not Oracle Cloud Infrastructure, the Gen 2 service most customers mean when they say “Oracle Cloud”. The likely entry point was CVE-2021-35587, a critical unauthenticated vulnerability in Oracle Access Manager within Fusion Middleware 11G. Reporting indicated the vulnerable endpoint had last been updated in 2014.

So: a publicly known vulnerability, disclosed years earlier, on a legacy platform, exposed to the internet, apparently unpatched.

The denial, and why it backfired

Oracle’s initial position was that Oracle Cloud had not been breached. It later confirmed to customers that credentials had been stolen from what it described as “two obsolete servers”, and characterised the data as old and non-sensitive.

The threat actor then produced material appearing to originate from an Oracle Access Manager endpoint on login.us2.oraclecloud.com, with records dated 2024 and 2025. Security researchers were blunt about the framing: rebadging a platform as “Classic” does not make a compromise of it something other than a compromise of an Oracle-managed cloud service. CISA subsequently issued guidance advising affected organisations to reset credentials, review logs and adopt phishing-resistant MFA.

The lesson is not about Oracle

It is tempting to read this as a story about one vendor’s communications strategy. The more useful reading is about how every organisation manages inherited systems.

Almost every business we assess has an equivalent: a legacy platform still running because something depends on it, still internet-facing, still holding credentials, and no longer owned by anyone in particular. It is not in the patching schedule because it predates the patching schedule. Oracle’s version was a Gen 1 cloud platform. Yours might be an old VPN appliance, a forgotten web server, or a directory service nobody wants to touch.

What to take from it

Three things. First, inventory what is actually exposed to the internet — not what you believe is exposed. Second, credentials leak sideways: SSO and LDAP material stolen from a legacy system unlocks modern systems, so credential rotation after any vendor incident is not optional. Third, a vendor’s public characterisation of an incident is a legal and commercial position, not a risk assessment. Read the technical detail and decide for yourself whether it affects you.

Sources

#CyberSecurity#DataBreach#Cloud

Need IT support?

Let's discuss how we can help protect and optimise your technology infrastructure.