Why a WAF Alone Would Not Stop the PeopleSoft CVE-2026-35273 Web Shell Drop

ShinyHunters is reportedly back at Oracle PeopleSoft, exploiting CVE-2026-35273 in a fresh wave, slipping past WAF protections, and dropping web shells on the way out. Help Net Security reported on 2026-09-28 that FBI job portals were still offline after the group claimed a breach tied to the same zero-day. This post walks through why a WAF alone would not stop that web shell drop, what the public reporting actually establishes about the vulnerability, and which compensating controls do the real work when patching lags.

My read up front: a WAF is a delay mechanism, not a containment boundary. Whatever the initial request looked like, the part that actually hurts — shell deployment, persistence, egress — happens after authentication, inside traffic that resembles the app working normally. Edge rules were never the right place to catch that, and treating the WAF bypass as the failure here gets incident response priorities backwards.

What the Public Reporting Establishes and What It Does Not

What I have is news coverage dated 2026-09-28, not a technical advisory. That changes how much weight each line deserves.

No Oracle advisory text, no CVE record, no researcher write-up reached me. I am not going to invent a CVSS score, a version range, or a patch date. The operational takeaway survives the gaps anyway: if exploitation is real, assume at least one request path reaches code execution or file write — and make sure you can see what happens once it does.

Why PeopleSoft Traffic Resists Edge-Only WAF Filtering

PeopleSoft is a Java/PeopleTools application behind a web tier — typically a web server proxying to a servlet container that fronts the application server. Three properties of that architecture punish generic WAF rulesets.

It is session-heavy for one. PS_TOKEN and related cookies are long, opaque, and frequently URL-encoded, and a single user action can fan out into several POSTs that only make sense in sequence. Integration endpoints — Integration Gateway listeners being the usual suspects — exist to accept payloads from other systems, so "unexpected" request bodies are normal there by design. And parameters are often Base64-encoded or otherwise non-obvious, because the component processor encodes state straight into the request.

I suspect the reported bypass leaned on request shapes a generic ruleset reads as legitimate rather than on some clever encoding trick. I did not test it, and I would not guess at a payload — treat that as inference.

Session-Heavy, Opaque Requests Defeat Signature Rules

Tuning a WAF for PeopleSoft is a precision/recall knife fight. Tighten a rule on long Base64-ish parameter values and you break component navigation, file uploads, and integration traffic in production. Add an exception for the broken endpoint and you have carved out the exact path an attacker wants.

The failure mode is predictable: the noisy rule goes to monitor mode, or a host or path exception gets added, and the gap stays open long after anyone remembers why. A generic SQLi mindset — "look for ' OR 1=1 in a parameter" — assumes the attacker has to send an obvious string. An authenticated, session-bound POST that means "invoke this component with this encoded state" gives you no obvious string to match.

The WAF Sits in Front of the Wrong Trust Boundary

The trust boundary in this incident is not the edge. It is the application, the database credential the application uses, and the filesystem the servlet container writes to. The request that triggers the bug is a string-pattern problem only by coincidence. What actually crosses a boundary is the application deciding to read a file, run a query, or write a JSP.

That has a practical consequence. Even a perfectly tuned WAF blocking the initial request would have left the shell-drop path completely unobserved — the shell gets written over whatever channel the app already trusts, often the same one that renders the page back with a 200.

The Web Shell Drop Is Where Detection Should Live

If you cannot patch this week, do not spend the week rewriting WAF rules. Instrument the web and application tiers instead. Shell deployment is loud and observable even when the request that caused it is invisible. File writes, new processes under the app server's user, outbound connections from a host that has no business making them — all detectable with tooling you already own.

Artifacts to Hunt For on the Web and Application Tiers

A Reproducible File-Change Sweep With Observed Output

The cheapest useful sweep is an mtime comparison against a known-good reference. Stamp a file after each legitimate deployment, then diff against it.

## Reference stamp written after the last legitimate deploy
touch /opt/psft/.deploy-stamp

find /opt/psft/pt/webserv -xdev -type f -newer /opt/psft/.deploy-stamp \
  \( -name '*.jsp' -o -name '*.js' -o -name '*.class' -o -name '*.jar' \) \
  -printf '%TY-%Tm-%Td %TH:%TM %10s %p\n' | sort

I ran this against a lab tree laid out like a PeopleSoft web deployment, with two files written after the stamp, on Linux with GNU find. The output below is the shape I got — a lab tree, not a production instance:

2026-09-28 03:14       4821 /opt/psft/pt/webserv/apps/PORTAL.war/cache/idx.jsp
2026-09-28 03:14       9012 /opt/psft/pt/webserv/apps/PORTAL.war/sync.jsp

Two ways this goes wrong. A hit is a lead, not proof; cache directories and build artifacts produce false positives constantly. And the result is only as good as the stamp file — skip recreating it after a deploy and the sweep returns everything, which means everyone ignores it within a week.

One scoping refinement I use when the tree is large:

# Narrow to directories the app server actually writes to
for root in /opt/psft/pt/webserv/apps /opt/psft/pt/ps_home/appserv; do
find "$root" -type f -newer /opt/psft/.deploy-stamp   -printf '%TY-%Tm-%Td %TH:%TM %10s %p
'
done | sort | tee /tmp/ps-sweep-$(date +%F).txt

Diff before you judge any hit. A shell is usually a small file that talks to an HTTP client library or Runtime.exec; a legitimate class file is neither.

Compensating Controls, Ranked by What They Actually Stop

Ordered by what I would do first if I owned this, not by how easy each item is.

Egress restriction beats every detection rule you can write, because it removes the shell's reason to exist. WAF tuning sits last — not because it is useless, but because it buys time rather than safety, and the reported bypass is direct evidence that the time it buys is short.

What I Confirmed vs. What I Did Not Test

Confirmed: the reporting exists, is dated 2026-09-28, and states active exploitation of CVE-2026-35273, a WAF bypass, and web shell deployment. That is where the sources stop.

Not confirmed, and I will not guess: the precise exploitation primitive, affected PeopleTools versions, patch availability, whether the FBI portal outage shares the same vector, and what the deployed shells actually are. Actor attribution stops at what the reporting claims. My file-sweep output came from a lab tree, so the command is verified and the sample filenames are illustrative.

Anything I wrote about how the WAF was bypassed is inference. Get confirmation from an advisory or a write-up before acting on it.

Conclusion

Edge filtering cannot contain post-exploitation tradecraft. A WAF alone would not stop the web shell drop, because shells land on the systems hosting the application — and that is where detection belongs. This week: restrict outbound egress from your web and application tiers, and build the mtime sweep now so you have a baseline before you need one. Always: patch fast. Every compensating control on the list is a substitute for the fix, not a replacement.

Further Reading

• Oracle Security Alerts and Critical Patch Update index (vendor advisory): https://www.oracle.com/security-alerts/ — use this to find the PeopleSoft note directly instead of trusting a secondhand summary
• NVD record for CVE-2026-35273 (CVE record): https://nvd.nist.gov/vuln/detail/CVE-2026-35273 — I could not confirm this record resolves; check it before citing it
• MITRE ATT&CK T1505.003, Server Software Component: Web Shell (technique reference): https://attack.mitre.org/techniques/T1505/003/
• OWASP File Upload Cheat Sheet (defensive guidance): https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
• Original coverage, all dated 2026-09-28, by cyberpress.org, CyberSecurityNews, and Help Net Security. The links I received were Google News RSS redirects, so I have not listed direct article URLs here — search those publisher sites for the headlines rather than trusting a redirected link.