A PeopleSoft WAF bypass using an encoded path has revived mass exploitation, showing why literal URL blocks cannot replace Oracle patches.
Answer first: Google’s threat-intelligence team says attackers linked to the ShinyHunters ecosystem renewed mass exploitation of Oracle PeopleSoft by encoding one character in a known path. The change let requests evade some web-application-firewall rules that blocked only the literal /PSEMHUB/ string. The fix is the Oracle patch for CVE-2026-35273, not another increasingly complicated URL rule.
The September 25 disclosure covers targets across multiple sectors and countries. Google and Mandiant describe a variant using /%50SEMHUB/, where the encoded value resolves to the same path after processing. This is a narrow but important distinction: a WAF may compare the request before normalization while the application interprets it afterward. Attackers win when two layers disagree about what the request means.
How the PeopleSoft WAF bypass works
A defensive rule that searches for one suspicious text string can be useful as an emergency brake. It is not equivalent to removing the vulnerable code path. Encoding, mixed case, alternate separators and multiple decoding passes can all produce equivalent requests that look different to a front-end filter. The reported PeopleSoft bypass appears to exploit exactly that gap.
Google attributes the activity to threat actors associated with ShinyHunters, but attribution remains the investigators’ assessment rather than a court finding. The directly auditable facts are the vulnerability identifier, the path variant, the renewed exploitation telemetry and the vendor’s available remediation. Those facts are enough to establish an urgent operational story without speculating about every victim or the attackers’ final access.
Why patching beats a new block rule
Adding the encoded form to a deny list may reduce immediate noise, but defenders should assume more representations exist. A normalized comparison can improve coverage, yet a WAF still sits outside the application and cannot reliably reconstruct every server-side parsing decision. Oracle’s update changes the vulnerable component itself, making it the central control.
Administrators should inventory internet-reachable PeopleSoft endpoints, confirm the exact PeopleTools versions, apply Oracle’s patch guidance, and review logs for both literal and encoded variants. They should also inspect downstream identity events and privileged changes. The exposure is not proven merely because a request hit the endpoint, but a successful exploit may leave evidence beyond the first web log.
This is the same defensive pattern seen in other enterprise software incidents, including the SolarWinds Observability patch: perimeter filtering can buy time, while the vendor fix closes the software flaw. Teams that cannot patch immediately should isolate the service, restrict trusted sources, add canonicalization-aware detections and prepare to rotate credentials if compromise indicators appear.
What is verified and what is not
The primary investigation and three independent reports agree on the renewed campaign and encoded bypass. Public reporting does not establish a complete victim list, a universal success rate or that every observed request led to access. “Mass exploitation” describes broad targeting activity; it should not be converted into a count of confirmed breaches.
The better executive question is whether the organization has removed the vulnerable condition. If the answer is “our WAF blocks the old path,” the PeopleSoft WAF bypass shows why that assurance is incomplete. A patch record, endpoint inventory and retrospective hunt provide a stronger answer.
Frequently asked questions
What is CVE-2026-35273?
It is the Oracle PeopleSoft PeopleTools vulnerability targeted in the campaign described by Google and Mandiant. Administrators should use Oracle’s security guidance to determine affected and fixed versions.
Does a WAF stop the attacks?
Not reliably. Literal rules can miss encoded equivalents. A WAF is a compensating control; the vendor patch addresses the underlying flaw.
Does scanning prove a breach?
No. A suspicious request proves targeting, not successful compromise. Teams need application, identity and host evidence to establish impact.
Verified facts
| Disclosure | September 25, 2026 |
|---|---|
| Target | Oracle PeopleSoft PeopleTools |
| Vulnerability | CVE-2026-35273 |
| Bypass pattern | Encoded /%50SEMHUB/ path variant |
| Priority | Apply vendor fixes; do not rely on a literal WAF rule |
Sources
- Google Threat Intelligence Group / Mandiant — Direct investigation of renewed multi-sector exploitation and WAF bypass.
- Oracle Critical Patch Update — Vendor remediation context.
- BleepingComputer — Independent corroboration of the encoded-path bypass.
- The Hacker News — Independent technical coverage.
- TecheNet — Independent report of the renewed campaign and mitigation limits.
Disclosure note: This report distinguishes confirmed exploitation or internal observations from inference. Syndicated accounts were not counted as separate verification.
Related Lapaas Voice coverage: Roundcube active-exploitation advisory.
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
