What I check when a firewall rule stands in for the PeopleSoft patch

On June 10, Oracle published an out-of-band security alert for CVE-2026-35273, a remote code execution flaw in PeopleSoft Enterprise PeopleTools that an attacker reaches without credentials ¹. Oracle scores it 9.8 under CVSS v3.1 and names PeopleTools versions 8.61 and 8.62 ¹. Mandiant had watched ShinyHunters exploit it against higher education from May 27 to June 9, before the fix existed, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on June 12 ².

For teams that could not patch that week, Mandiant’s June guidance recommended blocking external access to the vulnerable endpoint at the perimeter ³. Organizations took that step and considered the item handled ³. Three months later Mandiant published a follow-up: the group had changed one character in its request and walked past those rules ³.

That gap between a mitigation and a fix is the part I care about when a vulnerability window opens.

What the block covered

The endpoint in the exploit path answers on /PSEMHUB/, the Environment Management Hub ³. A rule that matches that literal string catches the request spelled that way. It misses the same request sent as /%50SEMHUB/, because %50 is the URL encoding of the letter P ³. The WAF compares the raw path against its rule before anything decodes it, finds no match, and passes the request through; WebLogic decodes the path and routes it to the same servlet ³. The rule holds against the spelling it was written for, and Mandiant notes that the technique reaches systems whose operators believed the WAF rule had covered the exposure ³.

I test the mitigation the way the attacker does

Someone tells me a control is in place, and I treat that as a claim and go find the layer that enforces it. For a path rule the questions are concrete: whether the match runs before or after URL decoding, whether it normalizes case and repeated slashes, and whether the same servlet is reachable through a rewrite or a second connector. Mandiant names /PSIGW/HttpListeningConnector alongside /PSEMHUB/hub in the same chain, so a rule that names only the first path leaves the second one open ³².

The check I run is the attacker’s move: encode a character, change the case, add a path segment, and watch whether the rule fires ³. A rule that fails an encoding test leaves the asset reachable and the fix still pending, so it goes into the same recommendation as the patch.

The September wave

Mandiant tracked the renewed campaign across higher education, technology, IT services, healthcare, agriculture, transportation, and government ³. The FBI’s jobs portal sits in that window. On September 22, ShinyHunters claimed it had breached the portal and taken data on agents and applicants, the bureau said it was investigating, and the site went down ⁴. Mandiant’s follow-up came three days later ³. Vectra ties the portal to the same PeopleSoft flaw ⁵; the FBI’s public statements stop at the investigation and do not confirm which vulnerability the group used ⁴. I treat the technique as the reliable part and the attribution as a claim until someone confirms it.

What I add to the window

Patching here runs through automation, so the work I own in a window like this is the order and the reasoning behind it. The first pass is scope: is the affected software in our inventory at all, and can the vulnerable endpoint be reached from outside ³¹?

When the asset is in scope, I look for the bypass in the logs instead of trusting the rule. Requests to /PSEMHUB/ and to any percent-encoded variant come first, with POST requests to /hub and new .jsp files from external addresses next ³. Mandiant’s indicators cover outbound SMB traffic from the server and MeshCentral agents configured to look like Azure services, which is how the group held access after the first request landed ³². A rule applied in June says nothing about a host that was reached before the rule existed, so the log review and the patch go into the same recommendation.

The order I keep

Mandiant’s guidance says path-based blocking and WAF rules do not replace the patch ³. CVE-2026-35273 gives me a way to apply that rule early. Before I record a mitigation as coverage, I try the encoding trick on it, because that is where a group that reads published guidance aims its next attempt. I keep the rule in place until the patch lands.