When a major cloud provider faces breach allegations, the response method and style of the people in charge matters almost more than the details of the technology. That’s exactly what’s happening with Oracle Cloud right now, as paper-thin narratives are being blown apart related to the potentially massive security incident affecting thousands of enterprise customers.

We all saw last week when “rose87168” posted on BreachForums that they had compromised Oracle Cloud’s login servers and exfiltrated approximately 6 million records containing sensitive authentication data. This includes Java KeyStore files (containing security certificates and encryption keys), encrypted SSO and LDAP passwords, and other authentication-related information.

Oracle’s response was… both instant and forceful:

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.

The instant confidence seemed too abrupt to be reliable. Sound familiar?

Hegseth is the first Trump official to deny [the breach]

Indeed, just like how The Atlantic has exposed national security level breach facts a cybersecurity firm CloudSEK tells us already a very different story than Oracle. Evidence published suggests the breach not only is completely real but will stand as one of the most significant supply chain compromises.

So what do we actually know, and how plausible is this breach? Let’s look at some evidence:

1. Proof of Access: The threat actor uploaded a simple text file to login.us2.oraclecloud.com containing their email address, which was captured by the Internet Archive’s Wayback Machine. This suggests they had write access to an Oracle Cloud server.
2. Confirmation of Prod Environment: CloudSEK has presented documentation showing that the compromised server wasn’t a test environment but a legitimate production SSO endpoint used by real customers for OAuth2 authentication and token generation.
3. Validation of Real Customers: By cross-referencing the leaked domain list with publicly available GitHub repositories, CloudSEK identified multiple genuine Oracle customers who had configurations referencing the affected login server. These included organizations like Rapid4Cloud (an Oracle Gold Partner) and several other enterprise companies.
4. Applicability of 2021 Vulnerability: The Register noted the server appeared to be running Oracle Fusion Middleware 11G, which may have been vulnerable to CVE-2021-35587, a critical flaw in Oracle Access Manager. This vulnerability has public exploit code available and matches the attack vector described.
5. Dump of Sample Data: The threat actor has since released a 10,000-line sample containing data from over 1,500 organizations, with evidence suggesting access to development, test, and production environments.

Despite this level of investigation producing reliable evidence, Oracle positioned their response as no breach possible. In cybersecurity, such absolute denials sometimes occur when organizations believe a compromised system is not directly connected to customer data, or don’t have a complete picture of their own systems. Perhaps more to the point Oracle may be defining “breach” narrowly (for example, distinguishing between credential theft and actual data exfiltration) and want to rewrite the issue as something different than what’s being claimed by the security reporter.

Without more detailed explanation from Oracle, it’s difficult to reconcile such an early categorical denial with the flow of specific technical evidence that is starting to be revealed.

The breach claims sure seem increasingly plausible, despite immediate denials, and for several good reasons. First, the breach vector follows known weakness in cloud architecture (as outlined in our 2012 cloud security book). Similar SSO/authentication system breaches have been known to come from unpatched vulnerabilities. Second, we have specific server names and paths that match legitimate Oracle Cloud infrastructure, and a second investigation that provided documentation analysis, domain verification, and sample data examination. Third, speaking of documentation, the volume and structure of the leaked data could be extremely difficult to fabricate convincingly. Not saying AI wouldn’t do a job today, but in the past integrity of the data dump has been a useful proof-point.

What remains less clear is the disputed impact to Oracle and its customers. Authentication-related information was allegedly stolen, yet there’s no evidence yet of compromised downstream customer environments affected. Nonetheless, this incident undoubtedly places Oracle’s security credibility under scrutiny in several remarkable ways.

The stark contrast between Oracle’s blanket denial and the detailed evidence presented by CloudSEK creates a troubling credibility gap. In security incidents, transparency builds trust, even when the news is bad. Oracle was so quick to reject the claims, it opened a huge chasm of credibility for other researchers to step into and assert trust.

And of course if we’re talking about a breach from Oracle’s CVSS 9.8 (CRITICAL) CVE-2021-35587 (e.g. published in 2021), it raises concerns about Oracle’s basic patch management and vulnerability remediation practices for its own cloud infrastructure. A critical patch should have been deployed in less than 72 hours from announcement. Last time I checked my watch the year 2025 was more than a few hours later than 2021.

Incidentally, no pun intended, this detail tracks with my own experiences behind the scenes with Oracle (and inside the Salesforce infrastructure, for that matter) where patches sometimes lag so far behind industry baselines as to beg the question of why and how some “big name” Silicon Valley security executives get so wealthy so fast while seemingly asleep at the wheel… rhetorical, I know.

Apparently some organizations potentially affected by this breach will be learning about it through third parties rather than directly from Oracle, which goes back to the problem of establishing a voice of trust. Oracle likes to position itself as a security leader, dubiously emphasizing the security advantages of its cloud offerings over competitors. This incident of course challenges whether that narrative is just lipstick on the pig.

All that said, it’s worth noting that if Oracle has legitimate reasons to believe no breach occurred, making any kind of premature acknowledgment also is unnecessary. The company may be conducting a thorough investigation before providing more details. However, that should be conveyed as such, with a statement of investigation rather than a categorical denial.

What now?

If you’re an Oracle Cloud customer, here’s what:

1. Rotate Creds: Immediately rotate all SSO, LDAP, and associated credentials.
2. Confirm MFA: Ensure strong multi-factor authentication is enforced across all cloud access points.
3. Tune-up Monitoring: Increase alerting on suspicious authentication attempts or lateral movements.
4. Independent Assessment: Consider engaging external experts to impartially and evaluate potential exposure with novel methods.
5. Document, document: Maintain detailed records of your response actions in case this becomes relevant to compliance requirements and claims against Oracle.

The fundamental challenge in cloud security isn’t new, and Oracle should be handling this in a way that doesn’t paint an even bigger target on their customers. When using third-party infrastructure, organizations are inherently dependent on security practices and transparency of the management running that infrastructure. This debate also demonstrates the value of dedicated and independent security researchers who more reliably verify claims and provide additional context during incidents.

As this story continues to develop, the most important outcome would be increased clarity—whether that confirms a breach occurred or explains why the compelling evidence presented doesn’t indicate an actual security compromise. Either way, we’re all watching closely for lessons that can improve future security.