WAF Watch: PeopleSoft path tricks, WordPress LFI, Drupal Webform

Mac ClarkMac Clark · September 28, 2026

A short roundup of what hit websites this past week — and what to do about it if you run campus or agency sites. Fear is cheap; checklists are useful. Last week’s Watch covered Click2Shell, Feide/Sikt availability, Magento StyleSmuggler cleanup, and a second Events Calendar RCE. Here’s what landed since then.

ProtectMyWebsite is the WAF that tells you what’s safe to block — rules start in count, then your dashboard shows what to promote. You still decide.

1. Oracle PeopleSoft — percent-encoding slips past literal WAF path rules (CVE-2026-35273)

Google Mandiant / GTIG reported on September 25–26 that UNC6240 (associated with ShinyHunters) resumed mass exploitation of CVE-2026-35273 — unauthenticated RCE in PeopleSoft PeopleTools 8.61 / 8.62 (CVSS 9.8, Oracle Security Alert June 10) — by changing one character in the request path.

Operators who could not patch quickly had been advised to block the Environment Management Hub path /PSEMHUB/* at the edge. Attackers now request /%50SEMHUB/ instead (%50 is the letter P). Many WAF and reverse-proxy rules match the literal path before URL decoding; PeopleSoft / WebLogic decodes and still routes to the vulnerable servlet. Mandiant says the new wave dropped web shells on dozens of systems across higher education, government, healthcare, IT services, and more. Recon often looks like a handful of POSTs to /%50SEMHUB/hub with serialized Java objects; later stages drop JSP shells (x.jsp, u.jsp), Neo-reGeorg tunnels, MeshAgent on Linux, or a trojanized installer that loads SIDEEYE on Windows.

Campus / agency angle: HR, student, payroll, and applicant portals on PeopleSoft are exactly the estates Mandiant flagged in the earlier education-focused wave. A string rule that “blocks PSEMHUB” is not the same as a patched PeopleTools node.

Do this: Apply Oracle’s fix for CVE-2026-35273. Disable EMHub in multi-server setups or remove the PSEMHUB app in single-server configs when that is operationally safe. Search WebLogic access logs for /PSEMHUB/ and percent-encoded / mixed-case variants. Inspect PSEMHUB.war for unexpected JSP shells. Rotate credentials readable by the PeopleSoft service account. At the edge, put encoded-path and deserialization probe shapes in count first — promote only when hits look like scanners, not a legitimate internal management call your team still needs during cutover.

BleepingComputer (Sep 26) · The Hacker News (Sep 26) · Oracle Security Alert CVE-2026-35273

2. WordPress core — unauth LFI→RCE fixed in 7.1.2; exploited within hours (CVE-2026-87902)

On September 22 WordPress shipped 7.1.2 for CVE-2026-87902 / GHSA-7hp8-65ch-5whp: an unauthenticated path-traversal issue in page-template resolution (get_page_template()). Under the right theme and PHP conditions (theme with a top-level page-* directory, readable local PHP such as pearcmd.php, register_argc_argv=On — common on older PHP / cPanel and the official WordPress Docker image), that LFI can become RCE. WordPress rates it critical; the GHSA lists CVSS 4.0 9.2. Fixes are backported as a courtesy through 4.7; only the current line is actively supported.

Patchstack told BleepingComputer the first malicious requests landed at 17:44 UTC on September 22 — under five hours after the release. Within a day, traffic rose about tenfold and moved from recon includes to writing files under /tmp and /var/tmp (wp-pear-rce-flag.php, poc87902.php, luci_*.php, zeta_*.php), including short tags that run a shell command on access. DeafNews (Sep 27) also notes CISA added the CVE to KEV on September 25 with a short remediation window.

Campus / agency angle: departmental microsites and shared hosting still on pre-7.1.2 (or “courtesy” backports on unsupported branches) are the soft targets.

Do this: Land 7.1.2 (or the matching security backport for your branch) everywhere — including every site in a multisite network. Confirm the version actually changed; do not assume auto-update finished. Sweep /tmp, /var/tmp, and other web-writable dirs for those payload names. Hunt access logs for POSTs with pagename / page_id and double-encoded traversal (%252f). Where you control PHP, turn register_argc_argv off if you do not need it. Patching does not remove files already dropped — hunt the filesystem. At the edge, put double-encoded pagename / template-resolution probe signatures in count; promote when traffic looks like scanners.

WordPress 7.1.2 release · BleepingComputer (Sep 23) · GHSA-7hp8-65ch-5whp

3. Drupal contrib — Webform RCE and a 36-issue Sept 23 batch

On September 23 the Drupal Security Team published advisories covering 36 vulnerabilities across 16 modules, including five rated critical. The headline for campus estates is CVE-2026-96355 in Webform: custom multiple-value display formats can include submission-value tokens that get evaluated as template code when a submission is displayed — ranging from data exposure to code execution depending on site config. Fixed in Webform 6.2.12 / 6.3.1 (that same upgrade clears 19 related moderate issues). Other criticals in the batch include Cloud module RCE / TLS issues (CVE-2026-96376, CVE-2026-96375, fix 7.0.1), Project Browser CSRF, and tawk.to CSRF. Beazley Security’s write-up notes no public PoC / confirmed in-the-wild exploitation at time of writing — Drupal contrib criticals historically get weaponized fast after disclosure.

Campus / agency angle: Webform is how a lot of public feedback, admissions interest, FOIA intake, and grant forms get built. “We only use contrib modules” is not a comfort statement.

Do this: Inventory Webform, Cloud, Project Browser, and tawk.to. Upgrade Webform to 6.2.12 or 6.3.1, Cloud to 7.0.1, then run database updates and rebuild caches. After Webform, grant the new Administer webform remote post URLs permission only to trusted roles. If you cannot patch today, remove custom multiple-value formats that embed submission tokens until you can. Uninstall Project Browser from production if unused. At the edge, put webform-submission and template-injection probe shapes in count; promote carefully so real public forms keep working.

Beazley Security (Sep 23 batch) · Drupal SA-CONTRIB-2026-175 (Webform) · NVD CVE-2026-96355

4. FBIjobs.gov — portal offline while PeopleSoft claims are investigated

From September 22 onward, ShinyHunters claimed a breach of FBIjobs.gov (the FBI special-agent application portal). Visitors reportedly saw a defacement-style message; the portal was marked unavailable in subsequent days. The FBI has said it is aware of reports of unauthorized activity and is investigating; as of late September coverage, it had not confirmed the entry vector or the full scale of any data loss. A sample of applicant/employee records was judged authentic by reporters covering the claim. The group has tied the operation to PeopleSoft / PSEMHUB — including the encoding bypass above and, in separate statements, a claimed additional unknown flaw in the same component. Treat group claims as claims until the agency says otherwise; treat an offline federal applicant portal as a reminder that HR / jobs CMS estates are high-value and often sit on the same PeopleSoft stack campuses run.

Campus / agency angle: applicant and student-employment portals share the same “public form in front of sensitive backend” shape. Availability loss and data-theft extortion patterns both show up in Mandiant’s PeopleSoft guidance this week.

Do this: If you run PeopleSoft for HR or applicants, assume you are in scope for the Mandiant checklist in item 1 — patch, disable/remove EMHub where safe, hunt encoded paths and JSP shells, rotate service-account credentials. Keep a public status owner for applicant portals so a takedown does not turn into silence. Origin IPs stay off the public internet.

BleepingComputer PeopleSoft / FBI Jobs context · The Hacker News (Sep 26)

Tip of the week

A literal path rule is not a patch — and encoded variants belong in count first.

This week’s PeopleSoft story is the clearest operator lesson in months: blocking /PSEMHUB/ while leaving /%50SEMHUB/ open is how a temporary mitigation becomes a false sense of safety. WordPress’s double-encoded pagename probes are the same family of bug — sanitizers and edge rules that look at the string before decode miss what the app sees after. Drupal Webform is different (template tokens in submissions), but it still rewards “deploy signature → watch real traffic → promote” over flipping deny on day one and breaking Monday morning public forms.

The right move:

  • Patch first when a vendor fix exists (PeopleTools, WordPress 7.1.2, Webform 6.2.12 / 6.3.1).
  • Deploy (or request) virtual-patch rules that cover normalized / decoded paths, not only the pretty ASCII string — plus the CMS-specific probe shapes above.
  • Leave new rules in count against real traffic.
  • After about a day, open the dashboard — it shows what’s safe to block.
  • One click to promote. You stay in the loop.

That’s how we run ProtectMyWebsite: Rules start in count. After 24 hours, the dashboard shows what’s safe to block — one click. Promote Copilot can explain why a rule looks safe (or why to hold / allowlist) in plain English for campus and agency operators — you still click once. It does not auto-block for you.

Self-serve is $150/site/month with a 14-day trial. Refer a peer: both sides get 10% off for three months.

If you run a multi-site estate (main site + departmental CMS + applicant portal + PeopleSoft), ask about Campus Estate: Talk to the sales team. No cookie-cutter dollar figure on a blog post; your inventory drives the conversation.

If you run campus or agency sites: scan your site, see what WAF count mode is, what's safe to block on a WAF, managed WAF for university and college websites, managed WAF for government and public-sector websites, Prior Watch (Sep 21), Prior Watch (Sep 16), and start a 14-day trial.

Related