Attackers Bypass WAFs to Exploit Oracle PeopleSoft Flaw and Deploy Web Shells
- ID
- 28925
- Status
- summarized
- Published
- 26 Sep 2026, 7:46 PM
- Fetched
- 26 Sep 2026, 11:15 PM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/09/attackers-bypass-wafs-to-exploit-oracle.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 5.5
- Created
- 26 Sep 2026, 11:16 PM
- Tags
- Audience
- developerssaas_founders
What happened
Google/Mandiant report a renewed mass-exploitation campaign against Oracle PeopleSoft using CVE-2026-35273 (CVSS 9.8), an unauthenticated remote code execution flaw in the PSEMHUB servlet, attributed to ShinyHunters-linked UNC6240. The attackers bypassed string-based WAF rules by URL-encoding one character, requesting /%50SEMHUB/ instead of /PSEMHUB/, because many WAFs and reverse proxies match the literal path before URL decoding while the PeopleSoft server decodes it and routes to the vulnerable servlet. Post-exploitation drops two JSP web shells into the PSEMHUB.war directory ('x.jsp' for command execution, 'u.jsp' for chunked uploads plus cmd.exe execution), with targets spanning higher education, technology, IT services, healthcare, agriculture, transportation, and government, and web shells deployed on dozens of systems.
Why it matters
If you run any WAF or reverse-proxy rule that matches a literal request path, this is a concrete demonstration that pre-decoding matching is bypassable — a single percent-encoded character (/PSEMHUB/ vs /%50SEMHUB/) walks straight past it. The practical decision: treat WAF rules as detection, not as a compensating control for a CVSS 9.8 unauthenticated RCE, and ask your WAF/proxy vendor directly whether their rules normalize percent-encoding before matching. The article names no Malaysian organizations, so there is no local victim or policy detail to act on here — the transferable lesson is the WAF decode-order gap, not PeopleSoft itself.
Discussion angle
The WAF matched the literal path before URL decoding, the app decoded it after — how many of your own edge rules, path-based auth checks, or rate-limit rules assume the path you see is the path the app sees? Worth walking through one real rule from your stack live.