One Encoded Letter: ShinyHunters Walked Past the PeopleSoft WAF Rule Everyone Wrote in June

/%50SEMHUB/

That's the whole trick. %50 is the URL-encoded form of the capital letter P. To a PeopleSoft server, /%50SEMHUB/ and /PSEMHUB/ are the same path. To a web application firewall rule that looks for the literal string PSEMHUB, they aren't. According to Mandiant and Google Threat Intelligence Group, that one-character difference is how ShinyHunters (tracked as UNC6240) came back for a second round against Oracle PeopleSoft in late September, three and a half months after Oracle shipped a fix.

I've read a lot of exploitation write-ups this year. This is the one I'd hand to anyone who still describes a WAF rule as "virtual patching."

What happened in June

The first wave is well documented. Rapid7 and Mandiant both report that ShinyHunters exploited CVE-2026-35273 as a zero-day between 27 May and 9 June 2026. It's an unauthenticated server-side request forgery bug in PeopleTools 8.61 and 8.62 that chains to remote code execution, rated CVSS 9.8. Oracle pushed an out-of-band fix on 10 June. CISA added it to the Known Exploited Vulnerabilities catalog on 12 June.

More than 100 organizations were notified. Mandiant says 68% of them were universities and colleges, which makes sense: higher education runs PeopleSoft Campus Solutions everywhere, and student records are exactly the kind of bulk PII ShinyHunters monetizes through its leak site. Stolen data went up on that site on 9 June.

The vulnerable endpoints were the Environment Management Hub (/PSEMHUB/hub) and the Integration Gateway listener (/PSIGW/HttpListeningConnector). Rapid7's analysis also flagged a detail that gets less attention than the RCE: the SSRF could be used to force the server into outbound SMB connections on TCP 445, handing the attacker the NetNTLM hash of whatever Windows account the PeopleSoft service ran as.

Hold onto that detail. It matters later.

What happened in September

PeopleSoft upgrades aren't quick. Plenty of teams, faced with a June advisory and a maintenance window months away, did the reasonable-looking thing: they put a rule on the WAF or reverse proxy blocking requests to /PSEMHUB/ and /PSIGW/, and they put the real patch in the queue.

On 26 September, Mandiant described a renewed mass-exploitation campaign that went straight through those rules. The requests now targeted /%50SEMHUB/. BleepingComputer's reporting on the Mandiant findings describes the pattern: 5 to 15 POST requests carrying serialized Java objects, then command execution. Mandiant's own line is blunt: "The threat actor bypassed these string-based WAF rules by URL-encoding a single character."

Mandiant counted web shells on dozens of systems globally, across higher education, technology, IT services, healthcare, agriculture, transportation and government. The tooling, per both BleepingComputer and CyberInsider:

• x.jsp for command execution
• u.jsp and u2.jsp for file uploads
• tunnel.jsp / tunnel.jspx, the Neo-reGeorg tunneling kit, to proxy traffic into the internal network
• Ple64.exe, a 5.2MB binary dressed up as the Light Alloy media player, which installs a backdoor Mandiant calls SIDEEYE
• MeshAgent, the legitimate open-source remote management agent, on Linux hosts

SIDEEYE's capabilities are the tell for what this campaign is really after. It steals browser and application credentials, manages files and processes, opens reverse shells and proxies traffic. That's not a smash-and-grab data exfil tool. That's what you install when you plan to come back and move.

The FBI claim

The highest-profile victim is the one with the least confirmed detail. On 22 September, ShinyHunters told BleepingComputer and Hackread that it had used a PeopleSoft exploit against the FBI's jobs portal and moved laterally into FBI-managed AWS GovCloud infrastructure. The group claims 2 to 3TB of data on current and former employees and applicants, and named internal systems including BEAST (background checks) and MedLink (medical records).

What's verifiable: Help Net Security reported on 28 September that apply.fbijobs.gov and fbijobs.gov/special-agents were still offline. 404 Media says it checked part of the leaked sample against public records. The FBI hasn't confirmed the GovCloud claim, and I'd treat the lateral movement story as unproven until it does. ShinyHunters has a habit of inflating its reach, and its stated motive here, contesting an IC3 advisory telling victims not to pay, is itself a pressure play.

But you don't need the GovCloud claim to be true to take the lesson. The jobs portal going dark for a week is enough.

Why the WAF rule was always going to lose

I want to be fair to the teams that wrote those rules. A WAF block on an unused admin endpoint is a sensible stopgap. The failure isn't writing the rule. It's closing the ticket on it.

Path-based string matching has a long, ugly history of losing to normalization differences. The firewall sees one representation of the URL. The application server, after decoding, sees another. Anything that sits between them and doesn't normalize identically creates a gap. Single-encoding, double-encoding, mixed case, path parameters with semicolons, overlong UTF-8, dot segments: every one of these has beaten someone's rule at some point. If your rule says "block PSEMHUB" and doesn't decode first, %50SEMHUB was always going to work. ShinyHunters just bothered to try it.

Here's the edge case I'd check first if you run PeopleSoft behind a reverse proxy: does your proxy decode before matching, and does it then forward the decoded path or the original? I've seen setups where the proxy matched correctly on a decoded copy but forwarded the raw string to WebLogic, and others where it did the opposite. The only way to know is to send /%50SEMHUB/ at your own front door and watch what reaches the backend. If you never tested your mitigation with an encoded variant, you don't know whether it works.

And notice the attacker economics. Writing this bypass cost ShinyHunters roughly nothing. The exploit chain already existed from June. The target list already existed: every PeopleSoft instance still answering on those paths. Mandiant's guidance now explicitly says to search WebLogic logs for encoded variants of the path, which tells you how many organizations were relying on the literal-string version.

This is the same pattern we covered with NetScaler CVE-2026-88771, where the patch couldn't recall credentials already stolen. Edge and enterprise application exploitation in 2026 keeps landing on the same point: the vulnerability is the door, and the credentials are the loot.

What's actually exposed on a PeopleSoft box

People tend to think of a PeopleSoft breach as a records breach. Student data, HR data, payroll. That's the headline loss. The more dangerous loss is the set of identities that box holds to do its job.

A PeopleSoft application server is a credential hub by design. Think about what it has to authenticate to:

• The database. Application server and process scheduler configs carry the Connect ID and the Access ID used to reach the PeopleSoft database. The Access ID is effectively the schema owner.
• Integration partners. The Integration Gateway holds node credentials and connector settings for every system PeopleSoft exchanges messages with: identity providers, LMS platforms, payroll processors, benefits vendors.
• Directory services. Plenty of deployments bind to LDAP or Active Directory for authentication, with a service account to do it.
• The OS and Windows domain. Whatever account runs the service. Remember the forced SMB from June: that's this account's NetNTLM hash leaving your network.

Historically, a lot of these values sit in configuration files encrypted with PeopleSoft's own reversible scheme. If the default key was never changed, "encrypted" doesn't mean much to someone with a shell on the server. Add SIDEEYE scraping browser and application credentials from any Windows host it lands on, and Neo-reGeorg giving the attacker a tunnel to use whatever they found, and you have a complete toolkit for turning one web server into an identity foothold.

So when Mandiant's last recommendation says to "rotate accessible credentials," read it as the most important line in the advisory, not a footnote. Patching closes CVE-2026-35273. It does nothing about a database Access ID or an integration node password that left in July and will be reused in November. We made the same argument about Artifactory tokens that outlive the patch, and it applies here with more force, because PeopleSoft service credentials are rarely rotated at all. In a lot of shops they're older than the people running the system.

Where deception fits, and where it doesn't

Let me be honest about the limits first. A decoy doesn't stop /%50SEMHUB/ from reaching an unpatched WebLogic instance. Only the patch does that. If you're still unpatched on 2 October, stop reading and go patch.

What deception does well is answer the question nobody can answer from logs alone: "Was our box touched in the gap, and did they take anything they're going to use?" ShinyHunters' tradecraft gives you three good places to ask it.

On the PeopleSoft hosts themselves. The attacker gets a shell and immediately goes looking for configuration and credentials. That's predictable, and predictable behavior is what honeytokens are built for. Plant decoy credential material alongside the real configs: a fake database service account, a decoy integration node password, a cloud access key that looks like it belongs to a reporting job. None of those have any legitimate use. The moment one is tried against your directory, your database listener or a cloud API, you have a confirmed signal with a timestamp, not a probability score. That's the zero-false-positive property that matters here: nothing in your environment should ever authenticate with them.

On the path inward. Neo-reGeorg exists to turn a web server into a pivot point. Whatever comes through that tunnel will scan for SMB, RDP, SQL and LDAP on nearby subnets. Decoy services on those ports, something like MineField's decoy TCP listeners, give you a tripwire that fires on the first internal connection attempt from a host that should only ever talk to its database and its users. An application server opening a session to a decoy RDP port is not ambiguous.

After the patch. This is the part most teams skip. If credentials left during the window, the attacker's next login may come months later, from somewhere else, against a different system. A honeytoken that was sitting on the box during the exposure window is a dated canary: if it ever fires, you know the theft happened and roughly when, even if your web logs from that period have already rolled off. That's the same reasoning behind the decoy AD objects that would have caught the Aurora affiliate's Kerberos dumps.

The checklist I'd run this week

If PeopleSoft is anywhere in your estate, including a vendor-hosted instance your HR or registrar team "doesn't really manage":

1. Confirm the June patch is applied to every PeopleTools 8.61 and 8.62 environment, including test and dev copies that sit on the same network.
2. Disable or remove the Environment Management Hub if you don't actively use it in a multi-server setup. Mandiant recommends this outright.
3. Test your edge controls with encoded paths. Send /%50SEMHUB/ and a few variants at your own perimeter and confirm what reaches WebLogic.
4. Search WebLogic logs back to May for both /PSEMHUB/ and encoded variants, plus POST bursts to /PSIGW/HttpListeningConnector.
5. Hunt for the known artifacts: unexpected .jsp or .jspx files in the PSEMHUB deployment directories, MeshAgent binaries (Rapid7 saw them named meshagent64-azure-ops.exe), Ple64.exe, and any outbound TCP 445 from application servers.
6. Rotate everything the box could reach. Connect ID, Access ID, integration node passwords, LDAP bind accounts, the service account itself and any cloud keys on the host. Change the configuration encryption key if it's still the default.
7. Seed decoy credentials on the rebuilt hosts so the next attempt, whether it's a new encoding trick or reuse of something stolen in June, announces itself.

The real lesson from one encoded letter

ShinyHunters didn't find a new vulnerability in September. They found a population of organizations that had mitigated a known one in a way that only stopped the exact string from the advisory. That's a planning failure, not a technical one, and it's going to repeat with the next critical bug in the next enterprise app with a slow upgrade cycle.

So treat a WAF rule as a timer, not a fix. Put a date on it. Assume the attacker will test it the way you should have. And assume that anything a compromised server could authenticate to is now a credential someone else holds.

If you want to see what honeytoken credentials and decoy services look like seeded across an application tier like PeopleSoft's, book a Mine2 demo and we'll walk through how a stolen decoy turns into an alert you can act on.