Learning from Oracle: What Not to Do After a Data Breach

The first half of this year has not been a happy one for Oracle or its customers. The company has suffered from two serious data breaches. This is problem enough on its own, but the real issue is how it has handled the intrusions.

Experts have lambasted the database giant for poor breach disclosure practice, including failure to communicate and twisting the message when it did ‘fess up.

Breach Number One

The company’s problems began in mid-February when it learned that attackers had accessed data on servers at the electronic health records company Cerner. Cerner, which Oracle acquired for $28bn in 2022, had an ongoing contract with the US Department of Veterans Affairs. Oracle learned about the attack around a month after it happened.

A class action lawsuit filed against Oracle at the end of March chastised the company for mishandling the incident.

“The lack of notification exacerbates the circumstances for victims of the data breach,” the lawsuit said, complaining that it had not notified anyone about the incident or told them whether it had been able to contain the threat. Neither did it explain how the intrusion happened.

Another Breach Hits

Then, a second breach came to light. On March 21, cybersecurity company CloudSEK discovered a threat actor called ‘rose87168’ selling the data online.

The data was stolen from 140,000 affected cloud tenants, according to its secretive criminal vendor, who claimed to have entered the system via an Oracle Cloud login endpoint. CloudSEK found that they exploited an instance of Oracle Fusion Middleware 11G, last patched in 2014. Dumped assets include Java Key Store files holding cryptographic certificates, along with encrypted single sign-on passwords and key files.

That’s pretty serious for customers, but Oracle apparently released next to no information in the early days of the breach, aside from claiming that it only affected legacy servers. The company told Bleeping Computer: “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.”

However, experts disagreed. rose87168 made a sample of the data available to Alon Gal, co-founder of the security consulting firm Hudson Rock. Gal contacted companies on the list to verify the data. The customers said that the files said to have come from Oracle Cloud were legitimate.

CloudSEK also published a follow-up article proving that the endpoint rose87168 took over was a production entity.

Oracle eventually contacted some customers privately, reporting that its Gen 1 servers had suffered a security incident. Gen 1 servers are old machines now serving what’s known as Oracle Cloud Classic. Gen 2 servers, which contain extra features, are called Oracle Cloud.

All of this means that if you strictly follow the wording of Oracle’s denial to the letter, only Oracle Cloud Classic servers were pwned, not Oracle Cloud servers. But we suspect the market, in general, would have liked a full, open discussion about what had happened rather than dealing with a tight-lipped vendor who revealed only the bare minimum of information.

Who Deleted The Archived Page?

Here’s where things get especially scuzzy. rose87168 had also uploaded a text file to the compromised Oracle endpoint and published a screenshot of it as proof that they controlled the asset. A snapshot of the evidence of compromise was stored on the Wayback Machine, a service hosted by the Internet Archive. This service stores copies of websites for posterity after they disappear. However, that archived page was allegedly removed using the Archive’s exclusion process.

“This is Oracle actively covering up evidence of an intrusion,” said security researcher Jake Williams in his post reporting the take-down on X. “This is someone executing 1990’s breach playbooks in 2025.”

We can’t prove who took down that page, but the whole affair is nevertheless an excellent lesson in how not to handle a data breach from a company hell-bent on protecting its brand as it races to grow its share of the lucrative cloud computing business.

How To Do It Right

So, how should you handle breach disclosure? Frameworks such as NIST’s Computer Security Incident Handling Guide and ISO 27001 have broad guidelines for communicating incidents. Key points include:

Communicate promptly and accurately: Notify affected parties as soon as practical once an incident is confirmed and its scope is understood. Regulations now often demand at least initial reports within a tight time window, and that’s becoming mandatory in many cases.

Coordinate your response: Keep communications fact-based and coordinated so that no one reveals anything that hasn’t been confirmed. To that end, understand in advance who will talk to the various stakeholders, including customers, regulators, employees, contractors, and the press. Channel messaging through them ensures that everyone understands the internal chain of communication.

Know what to communicate: While not everything will be available in the early days, notifications should eventually include a summary of what happened, along with what data was compromised and what actions are being taken to mitigate the problem and prevent it from happening again. Affected individuals should also know what they should do to protect themselves.

Don’t communicate too little: Not all information will come out immediately, but you should be as forthright as possible and communicate in good faith. As the FTC points out: “Don’t make misleading statements about the breach. And don’t withhold key details that might help consumers protect themselves and their information.” We’re looking for open communication, not spin. Don’t treat this as an adversarial process.

Define communication templates: Developing pre-approved messaging templates helps to keep communications smooth and consistent. The FTC has an example.

Align with regulators: Different jurisdictions (both international, national, and local) will have their own rules about how and when to notify different stakeholders. So will different industries. Work with your lawyers to ensure that you follow them.

Stay accountable: Just as in everyday life, adults expect each other to own their mistakes and make them right. Ensure that customers have adequate support. This might include effective communication and specific help around breach remediation, consisting of tools to help protect you. It’s telling that CloudSEK, not Oracle, released a tool for companies to determine whether their data was on the list of stolen records.

This isn’t the only time that Oracle has drawn flak for its approach to handling cybersecurity issues. These include sluggish responses to reports of security flaws in its products and the CSO’s rant against security researchers sending her bug reports, which got so much blowback that the company deleted it. The organisation clearly has its own way of doing things, and we’re sure this won’t be the last time it causes consternation in the tech industry.