Nissan staff hacked via Oracle zero-day bug

Two weeks of zero-day abuse

On 2026-06-10, database giant Oracle published an emergency patch for a bug designated CVE-2026-35273.

The security advisory noted, in the staccato-but-wordy, templated, copy-and-paste jargon often used in bulletins of this sort:

Oracle PeopleSoft Enterprise Applications customers may [․․․] be affected by this vulnerability. This vulnerability is remotely exploitable without authentication. If successfully exploited, this vulnerability may result in remote code execution. We consider implementation of the recommended mitigations to be a high-priority risk reduction measure and strongly recommend immediate action to address the identified exposure.

The risk score on the CVSS (common vulnerability scoring system) scale came out at 9.8/10, but that 98% danger rating wasn’t really enough.

The bug was a zero-day hole, meaning the crooks got there first, and had already used the bug to carry out attacks.

Simply put, the probability of successful abuse of the bug was already 100% by the time the alert came out, with Google claiming that exploitation happened between 2026-05-27 and 2026-06-09, the two weeks preceding the appearance of the patch.

In other words, Oracle’s phrase saying “[our] customers may be affected by this vulnerability” might better have been written as “some customers have been hit for sure, but we’re not sure yet who they were, so it may be you, or it may be someone else.”

If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.

Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.

SSRF explained

The bug, according to reports, is what’s known very broadly as a server side request forgery (SSRF), a fancy way of saying that an outsider (in this case, a regular user with no login credentials for the targeted system) can send what should be innocent data to the server․․․

․․․but trick the server into using that data in a follow-on request of its own in a dangerous way.

A simple example of an SSRF attack might be a server that accepts a search term, expecting it to be a simple name or a user ID, and is supposed to build that search term into a web request of its own, reaching out to a specific database service inside its own network to do the lookup.

Now imagine that the search term submitted, instead of being a simple text string such as duck, is itself a complete URL such as https://private.test/getSystemConfig.

Imagine also that the server fails to reject the “username” for containing non-alphabetic characters, recognizes it as a URL, and decides simply to trust and use the full URL for its own follow-on search request, instead of searching against the specific database server it’s supposed to use.

Tricks of this sort can typically abused in many ways, including luring the vulnerable server to reach inwards to internal-only servers that aren’t supposed to be accessible to outsiders at all, or to reach outwards to servers controlled by the attackers, thereby exfiltrating secret internal data.

One common abuse of SSRF bugs is to feed “local only” URLs starting https://127.0.0.1/ or https://localhost/ to a remote server, thereby tricking it into accessing tools that for security reasons are only supposed to be available locally, such as a management interface or a password reset feature.

Nissan staff in the firing line

We now know that Nissan is one of Oracle’s customers whose data was targeted using this bug, allegedly by the ShinyHunters cybercriminal gang.

ShinyHunters are notorious cyber-blackmailers who loosely fall into the category of ransomware criminals, although they generally don’t bother with the file-scrambling part of a typical ransomware attack.

Instead, they simply steal as much personal data as they can, and the “ransom” they demand from victims is basically hush money.

Pay the blackmail, and they say they’ll delete all the data they stole instead of selling in on to other crooks, forwarding it to the media, or dumping it for the world to see.

Nissan’s breach disclosure states:

We are writing to share an important message regarding employees’ personal information. Nissan Americas uses Oracle PeopleSoft software to manage employee information, including payroll, tax administration, and other personnel records. Oracle has informed us that there was a cyber event and that the personnel records of hundreds of companies may have been obtained by so-called threat actors. We have since learned that Nissan was specifically targeted in this attack.

The staff affected by this crime probably won’t be pleased to see it glibly described as “a cyber event,” given that cyber events include almost any online activity, from watching a cat video to sending a DM to a friend, but the notification does at least admit that it was an “attack.”

Worrying amounts and types of data are already known to have been stolen, although Nissan admits that the “full scope and impact” is not yet known:

We are working to complete our investigation as quickly as possible to understand the full scope and impact. Though we are early in that process, we believe some personal information has been accessed, such as contact and banking information, Social Security Number / Social Insurance Number /National Identification Number, financial and tax data, and dependent / beneficiary information. We believe that this incident affects current and former Nissan employees in the USA, Canada, Mexico, and Brazil.

As we continue our investigation, individuals whose personal information has been exposed will receive further communication with additional details and next steps.

What to do?

Nissan is advising its staff to change their passwords and enable 2FA/MFA (two-factor/multi-factor authentication).

Although this is a reasonable suggestion in this case, given that it’s not yet known whether passwords or other authentication data was stolen, it’s important to remember that doing these things in advance would not have prevented this attack, and that victims carry no blame here, regardless of their own personal cybersecurity choices.

The victims didn’t get a choice of whether to hand over this data or not (it was a necessity of employment); didn’t get to choose whether it would be shared with a third party (it was Nissan’s decision to outsource personnel records to Oracle); and couldn’t have improved the security of this data through settings or behaviors of their own (it was stolen without authentication via a bug of Oracle’s making).

Other useful advice is:

• If you use the affected Oracle products yourself, make sure you’re patched, given that the criminals already know how to exploit this bug.
• If you outsource data to Oracle’s affected cloud services, ensure that you keep in contact with Oracle to find out whether your data was affected. As seen in Nissan’s disclosure report above, hundreds of companies were exposed in this attack alone.
• As an employer, the buck stops with you for protecting and securing the personal data you collect and keep about your staff. Outsourcing this data to a third-party service in the cloud doesn’t exonerate you if there’s a breach, so don’t be afraid to demand answers from your service providers about their cybersecurity risk management, and practice what you will do and how you will respond if your provider lets you down.
• If you’re a victim of an attack like this, be especially cautious of “experts” who reach out to “help” you in the aftermath. Criminals often use stolen personal information as “evidence” that they’re contacting you officially, using data that you may assume “proves” they work for at the organization from which they say they’re calling, emailing, or messaging.
• Keep a closer eye than usual on your financial statements. The sooner you spot any anomalies, and the sooner you report them, the sooner they can be investigated. But remember tip 3 above – don’t “report” problems to “officials” who contact you. Find your own way to the official reporting services of the financial institution involved. Use URLs or phone numbers from official correspondence you received in the past.

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!