Did Oracle Leave the Front Door Open to API Attacks?
Published: April 17, 2025
There’s a bit of a standoff brewing between database giant Oracle and cybersecurity firm CloudSEK that brings into focus the critical importance of API governance.
According to CloudSEK, in March 2025, a threat actor claimed to have stolen 6 million records from Oracle Cloud by compromising a production SSO endpoint. Oracle denied the claim outright however CloudSEK’s subsequent investigation revealed what appears to be a high-impact compromise of a critical identity service.
The attacker targeted login.us2.oraclecloud.com, a production endpoint running a publicly exposed, outdated version of Oracle Fusion Middleware 11G with a vulnerable Oracle Access Manager (OAM) component. Archived Wayback Machine captures confirm the system was live and externally accessible as of February 2025. This was an endpoint that was in active use by major enterprise customers like OneLogin and RainFocus who depended on it to broker authentication across Oracle Cloud services.
The vulnerability exploited was CVE-2021-35587, a well-documented unauthenticated remote code execution flaw in OAM. A specially crafted HTTP request sent to the /oam/server/ endpoint caused the application to parse attacker-controlled input which allowed them to load arbitrary Java classes and execute commands on the SSO server.
Once breached, the attacker gained access to encrypted SSO and LDAP passwords, JKS keystores, OAuth2 tokens, and enterprise configuration files. These assets enabled unauthorized access at the identity layer, allowing for impersonation of users and services, API abuse, and potential breaches of other environments.
This breach underscores the importance of robust API governance practices, especially around critical infrastructure elements such as identity infrastructure. This attack wasn’t just about an unpatched server, it was a failure of lifecycle oversight, external exposure controls, and identity/API architecture governance. An SSO endpoint was left publicly accessible despite being long out of date. That’s not a patching issue alone, it’s a governance issue. Oracle lacked a policy enforcing deprecation of legacy systems, had no visibility into what production services were internet-facing, and had no central registry tracking their usage.
All critical or sensitive infrastructure (anything exposed to the Internet as a minimum) needs to have an established product team owner, who is positioned to understand the components and architecture and to update them as part of an ongoing maintenance and development lifecycle of a platform. Good governance, even API specific governance, can support this by enabling education and training for the product teams about the risks, how to measure them, and how to ensure infrastructure deployment is low cost and simple to achieve on a regular basis so that dated components are being regularly updated (the three Rs of security: Rotate, Repave, Repair). As much as good governance can set rules and guidelines, it should also be seen as a service to the organization, offering education, support, and enablement.If there was no product team owning Oracle’s infrastructure, there may have been no one to educate, support, or enable.
Governance-centric mitigations that would have helped in this situation include enforcing lifecycle management policies for auth services, maintaining a registry of legacy infrastructure, and requiring business justification for public endpoint exposure. Token federation controls like audience restriction and short token lifetimes help limit attacker movement even after compromise. All authentication APIs should be fronted by managed gateways and/or with a WAF, anomaly detection, and logging to enable early detection. This could have helped block or spot invalid payloads used in the attack. Meanwhile, identity systems should be routinely tested with red-team simulations, and dependency tracking should be standard to ensure rapid response. Governance doesn’t just prevent misconfigurations, it ensures visibility, accountability, and enforced standards across the API ecosystem.
This breach highlights that API security failures are often governance failures in disguise. It wasn’t just a missing patch, it was the absence of enforceable standards, oversight, and accountability (or ownership) across the identity and API layer. Strong governance helps ensure deprecated systems are retired, exposure is intentional, and authentication endpoints follow policy, not just best effort.
At Solsys, we help organizations implement API governance frameworks that bring structure to API and identity architecture, enforce policy at scale, and reduce risk across hybrid environments. Whether it’s auditing public exposure, tightening identity flows, or establishing lifecycle management for auth services, Solsys partners with your security and platform teams to turn governance from a checkbox into a real defense layer.
