When Oracle warned Nissan of a zero-day exploit in PeopleSoft, the carmaker was already compromised. Between May 27 and June 9, attackers linked to the ShinyHunters group accessed sensitive employee data, Social Security numbers, banking details, tax records, through CVE-2026-35273, a critical remote code execution flaw that Oracle patched only after exploitation began.
Nissan's disclosure, published on June 26, named current and former staff across the US, Canada, Mexico, and Brazil as affected. This breach wasn't unique; hundreds of organizations, mostly universities, were caught in the same campaign. The pattern of mistakes that let attackers in? Those repeat across industries.
Why These Mistakes Keep Happening
Zero-day exploits don't announce themselves. You don't get advance warning, and by the time your processor publishes an advisory, attackers have already moved. But the conditions that make zero-days catastrophic, the access paths, the unmonitored payroll systems, the absence of segmentation, are within your control before the exploit drops.
Most teams treat processor software as a black box. You implement PeopleSoft or SAP or Workday, configure user access, and assume the processor handles security. That assumption breaks when a zero-day hits enterprise HR software, because payroll and personnel systems hold exactly the data Article 9 GDPR classifies as special category: health records, union membership, dependent information. The impact isn't just regulatory. It's every employee's banking details and tax ID in the hands of an extortion group.
The mistakes below aren't about missing the zero-day itself. They're about the choices that turned a software vulnerability into a personal data breach affecting thousands of individuals across four countries.
Mistake 1: Treating processor Software as Low-Risk
Your procurement team signed the PeopleSoft contract years ago. It runs payroll, so access is tightly controlled, only HR and finance can log in. You've satisfied yourself that the processor agreement is in place, and you move on.
The mistake: assuming enterprise software from a major processor carries lower risk than a third-party API or cloud storage bucket. Attackers don't care about your processor's reputation. They care about the data the software holds and whether it's exposed to the internet.
The consequence: When CVE-2026-35273 dropped, organizations with internet-facing PeopleSoft instances had no additional controls between the exploit and their employee database. The processor's patch came after the breach window closed.
The fix: Map every system that processes employee personal data and document its internet exposure. For each one, answer: does this need to be reachable from outside our network? If PeopleSoft must be accessible remotely, put it behind a VPN with multi-factor authentication and restrict access by IP range. If it doesn't need external access, segment it. Your appropriate technical and organizational measures under Article 32 must account for the sensitivity of the data, not the processor's brand.
Mistake 2: No Monitoring on Payroll Systems
You've got logging enabled on your perimeter and your domain controllers. Your SIEM alerts on failed login attempts and privilege escalation. But your payroll system? It's internal, so you trust it.
The mistake: assuming that internal systems don't need the same behavioral monitoring as external-facing infrastructure. Attackers who exploit a zero-day don't trip your perimeter defenses, they're already inside the application.
The consequence: Between May 27 and June 9, ShinyHunters extracted employee records from PeopleSoft instances across hundreds of organizations. Many victims didn't know they'd been breached until Oracle issued its advisory. Without query monitoring or data export alerts, mass extraction of personnel records looked like normal system activity.
The fix: Implement query-level logging on any system that holds special category data or financial information. Set thresholds: if someone exports more than 50 employee records in a single session, you get an alert. If a user account accesses the system outside normal business hours, you get an alert. These controls won't stop a zero-day, but they shrink your detection window from weeks to hours.
Mistake 3: Delayed processor Communication Protocols
Oracle warned Nissan of "a cyber event affecting hundreds of companies." That notification came after the exploitation window. By the time Nissan knew it was targeted, the data was gone.
The mistake: waiting for your processor to tell you there's a problem, rather than establishing a protocol for immediate notification of any suspected compromise.
The consequence: Your breach notification clock under Article 33 starts when you become aware of the personal data breach, not when you confirm the full scope. If your processor waits days to notify you, you've lost days of your 72-hour window to notify your supervisory authority. Worse, you've lost time to contain the breach and preserve evidence.
The fix: Your processor agreements should require notification within 24 hours of any suspected security incident affecting your data, not just confirmed breaches. For critical systems like payroll, establish a direct escalation path, your processor's security team should have your DPO's contact details and a mandate to notify immediately. When you receive that notification, your first action isn't investigation. It's preservation: lock the affected accounts, capture logs, and snapshot the system state before you start forensics.
Mistake 4: No Segmentation Between Payroll and Corporate Network
After the breach, Nissan restricted payroll access so staff must use a network computer or secured VPN to view pay slips or change direct deposit details. That's a post-breach control that should have been pre-breach architecture.
The mistake: allowing payroll self-service from any device, anywhere, without additional authentication. Convenience beats security until you're writing breach notifications.
The consequence: If an attacker compromises an employee's credentials, they can access not just that employee's payroll data but potentially pivot to broader system access. When your payroll system sits on the same network as your email and file shares, a PeopleSoft exploit becomes a foothold for lateral movement.
The fix: Treat payroll access like you treat your financial systems. Require VPN plus MFA for any remote access. Better yet, implement a jump box or privileged access workstation for HR staff who process payroll changes. Your employees can view their pay stubs from a secured portal, but modifications, direct deposit changes, tax withholding updates, require stepped-up authentication and happen only from managed devices.
Mistake 5: Assuming Patching Closes the Incident
Oracle issued an out-of-band advisory and mitigations after the attacks began. Your team applied the patch within hours. Incident closed, right?
The mistake: treating a zero-day patch as the end of your response when it's actually the beginning. As one security researcher noted in the aftermath, patching the flaw does nothing for data already taken during the exploitation window.
The consequence: You've stopped ongoing exfiltration, but you haven't determined what was accessed, by whom, or whether the attacker left persistence mechanisms. Your Article 33 notification obligation doesn't end when you patch. It begins when you discover the breach, and it requires you to describe the likely consequences and the measures you've taken or proposed to address it.
The fix: The patch stops the bleeding. Your incident response starts after. Pull access logs for the exploitation window, in Nissan's case, May 27 to June 9. Identify every account that queried employee records during that period. Cross-reference against normal usage patterns. Check for new user accounts, modified permissions, or scheduled tasks created during the window. Only after you've mapped the access can you scope your notification. And if your logging doesn't go back far enough? That's your finding for the next risk assessment.
Prevention Checklist
Before the next zero-day drops:
- Map your employee data flows. Document every system that processes personnel records, health information, or financial data. Note which are internet-facing.
- Segment payroll systems. If remote access is required, enforce VPN plus MFA. If it's not required, remove internet exposure entirely.
- Implement export monitoring. Set alerts for bulk data access, after-hours queries, or unusual user behavior on HR systems.
- Update your processor agreements. Require 24-hour notification of suspected incidents, not just confirmed breaches. Establish direct escalation contacts.
- Test your breach response. Run a tabletop exercise where your processor notifies you of a zero-day at 4 PM on a Friday. Can you preserve evidence and notify your supervisory authority within 72 hours?
- Review your logging retention. You need enough history to reconstruct attacker activity during the exploitation window. If you can't go back 30 days, extend your retention.
The zero-day will come. Your job is to make sure it doesn't become a personal data breach affecting thousands of employees across four countries because you assumed the processor had it covered.
