TL;DR
- ServiceNow disclosed in June 2026 that a misconfigured endpoint exposed customer data to anyone who asked, no authentication required.
- Three weeks later, Nissan disclosed a breach exposing SSNs, banking data, and payroll records for employees in the US, Canada, Mexico, and Brazil; root cause: an unauthenticated SSRF-to-RCE flaw in Oracle PeopleSoft.
- Different vendors, different products, identical root failure: an endpoint that never checked who was calling.
- In the PeopleSoft case, access wasn’t the whole attack. Attackers chained it into RCE, disguised persistence, internal recon, and staged exfiltration.
- Volume-based detection catches spikes. Business logic security catches the failure itself; missing authorization checks and the chains they enable at any stage, before data leaves.
A Pattern, Not a One-Off
Three weeks ago, it was ServiceNow: an endpoint that never asked who was calling, exposing customer data to anyone who asked. This time it’s Oracle PeopleSoft, exploited at scale by the threat actor ShinyHunters.
Two platforms, two different vendors, the same root failure: an endpoint that skipped the one question it existed to ask. That’s not a coincidence you write off as bad luck at two companies. It’s a pattern, and it’s worth naming as one before a third company becomes the next case study.
| ServiceNow (June 2026) | Oracle PeopleSoft (May–June 2026) |
| Endpoint misconfiguration skipped an authentication check | Endpoint had no authentication check at all, chained into RCE |
| Customer data exposed to any caller | Employee SSNs, banking data, and payroll records exposed |
| Single-stage exposure; no further exploitation needed | Multi-stage attack: RCE, disguised persistence, recon, staged exfiltration |
| Missed because requests were technically valid | Missed because each stage looked like routine ERP traffic |
What Happened
On June 5, 2026, ServiceNow pushed a security update to hosted customer instances after discovering that an endpoint let unauthenticated users access more data than intended; no exploit, no credentials, just a boundary that should have required authentication and didn’t. Defenders outside the initially disclosed scope later reported evidence of external access in their own logs. We covered that incident in detail here.
Three weeks later, a structurally similar story played out at a different company running a different platform.
Nissan Americas confirmed in a filing with the California Attorney General’s office that current and former employees across the US, Canada, Mexico, and Brazil may have had Social Security numbers, banking details, payroll records, and tax data exposed. Nissan uses Oracle PeopleSoft to manage payroll, tax administration, and personnel records for its Americas workforce.
Nissan wasn’t targeted alone. The ShinyHunters extortion group, tracked by Mandiant and Google’s Threat Intelligence Group as UNC6240, ran the campaign at scale:
- 300+ PeopleSoft instances compromised
- 100+ organizations affected
- 14 days of active exploitation before a patch existed
Exploitation ran May 27 to June 9, 2026, two weeks before Oracle’s June 10 emergency patch, and well before the CVE landed on CISA’s Known Exploited Vulnerabilities catalog.
The entry point, CVE-2026-35273, is an unauthenticated SSRF flaw in PeopleSoft’s PSEMHUB component, rated CVSS 9.8, exploitable over plain HTTP with no credentials. From there, attackers chained it into full remote code execution, deployed remote-access agents disguised as Azure services, mapped PeopleSoft configuration data, and compressed records before moving them out.
Why This Is a Business Logic Flaw
Every breach retrospective wants one root cause. Here it’s tempting to say “unauthenticated endpoint” and stop. That’s accurate, but it’s not the whole story.
The endpoint is where this attack started. It’s not what made it a breach. What made it a breach was everything that happened next: RCE, disguised persistence, internal recon, staged exfiltration, none of which required a credential, and none of which was being watched.
Call this “an unauthenticated API endpoint” and the story stops at stage one. Follow what happened after access, and a different picture forms: five stages, only one of which is authentication.
- Unauthenticated access: The door with no lock. Most coverage stops here.
- SSRF chained into RCE: Should this endpoint ever be able to trigger code execution at all?
- Disguised persistence: Does this system have any legitimate reason to talk to this destination?
- Internal reconnaissance: Is this the pattern of a scheduled job, or of something exploring?
- Staged, compressed exfiltration: Has HR data ever left through this path before?
None of stages two through five are about credentials. They’re about whether an action fits the workflow it claims to be part of, and that only shows up if something is mapping the workflow itself, not just checking who’s logged in.
Why It Matters
A zero-day means the patch didn’t exist yet. It doesn’t mean the attack was invisible. Every stage after initial access was a workflow anomaly, and workflow anomalies don’t need a known CVE to be caught.
- “Internal” isn’t a security tier. PeopleSoft gets treated as back-office infrastructure, not an internet-facing attack surface. That assumption let a critical, unauthenticated, HTTP-reachable RCE sit unnoticed across 300+ instances.
- Patch timing can’t be the primary control. Nissan’s exposure window closed before Oracle’s advisory even existed. “Patch fast” always loses to a flaw nobody has named yet.
- Attackers now design around behavioral detection. Disguised C2 traffic and compressed, staged exfiltration are both deliberate moves to stay under volume-based thresholds.
- The blast radius is a business question. This was SSNs, banking details, and payroll data for a global workforce, the kind of exposure that turns into identity theft and years of downstream liability.
Where This Should Have Been Stopped
Authentication is one control, and it failed here, but it was never going to catch stages two through five. Closing that gap means watching the business logic path an attack takes, not just the door it walked through.
See the endpoint before an attacker does
AppSentinels’ discovery and posture management continuously maps every API and endpoint, including the shadow and orphaned ones legacy ERP platforms accumulate over time, the kind of exposure PSEMHUB represents, surfaced before it becomes an advisory.
Model what a legitimate workflow looks like
AppSentinels builds a business logic graph of how users, APIs, and systems are supposed to interact. A payroll system pulling one employee’s record is normal. The same system chaining into compressed bulk transfer is not regardless of whether the volume looks unusual on its own.
Catch the chain at any stage, not just the exfil
Waiting for the bulk transfer to trigger an alert means the attacker already won stages one through four. AppSentinels’ runtime protection flags and blocks business logic violations in real time, including at the access and reconnaissance stages.
Move from visibility to intent
Knowing a system can reach an endpoint isn’t enough. The real question is whether what it’s doing there matches business intent visibility isn’t security, understanding intent is.
The Key Takeaway
Unauthenticated endpoints will keep shipping. Zero-days will keep landing before patches exist. Neither is fully preventable. What is preventable is treating everything after initial access as invisible by default. Four of five stages here had nothing to do with credentials and none were caught, because nothing was checking whether they matched the workflow they claimed to be part of. Business logic security closes that gap, at whichever stage the attacker is standing in.
Schedule a demo to get a walkthrough of how AppSentinels maps your API and AI attack surface before an attacker does.
FAQs
1. What is business logic security?
2. What is a business logic graph?
3. How is business logic security different from traditional API security?
4. Why do zero-day exploits often go undetected until it’s too late?
5. How can organizations tell if their APIs are exposed to business logic abuse?
