ShinyHunters Bypassed WAF Rules to Attack Oracle PeopleSoft Servers

• The Mess: ShinyHunters is exploiting an old Oracle PeopleSoft zero-day again, but this time the attackers changed the exploit to bypass WAF rules. Mandiant found web shells on dozens of compromised systems worldwide.
• The Damage: One unauthenticated request can lead to remote code execution, persistent access, credential theft and full server compromise.
• The Fix: Patch CVE-2026-35273 immediately and stop pretending that a WAF rule is a substitute for fixing the vulnerable application.

Oracle PeopleSoft is the kind of software attackers love.

It sits deep inside enterprises, handles sensitive business data and often has access to databases, integration services and internal infrastructure.

Now ShinyHunters is exploiting it again.

The vulnerability is CVE-2026-35273, a critical remote code execution flaw in the PeopleSoft Environment Management component.

Oracle originally disclosed the issue in June.

The current campaign is different.

Attackers have modified their exploit to defeat one of the most common mitigation strategies administrators used after the original disclosure: blocking the vulnerable endpoint with a Web Application Firewall.

Mandiant says the new campaign has already reached organizations across higher education, technology, IT services, healthcare, agriculture, transportation and government.

The vulnerability is brutally simple

Oracle rates CVE-2026-35273 at CVSS 9.8.

It is remotely exploitable over HTTP.

No authentication is required.

No user interaction is required.

A successful exploit can compromise PeopleSoft Enterprise PeopleTools and provide remote code execution.

The vulnerable component is the Environment Management Hub, exposed through the PSEMHUB application.

That makes the problem particularly nasty for systems that expose the relevant PeopleSoft infrastructure to the Internet.

The original attack already gave ShinyHunters a powerful entry point.

The new campaign shows that the attackers were paying attention to defensive guidance.

The WAF bypass

After Oracle released its security alert, many administrators tried to reduce exposure by blocking access to the vulnerable PSEMHUB endpoint.

That was a reasonable temporary mitigation.

It wasn’t a permanent fix.

ShinyHunters modified the request path.

Instead of requesting:

/PSEMHUB/

the attacker can use:

/%50SEMHUB/

The %50 represents the letter P.

A WAF or reverse proxy may compare the URL before decoding it.

The PeopleSoft application server decodes the request and sees the original path.

So the security appliance sees one thing.

The vulnerable application sees another.

The request gets through.

The vulnerable servlet processes it.

The exploit runs.

That tiny difference between URL parsing layers is enough to turn a perimeter mitigation into a bypass.

The attack chain doesn’t stop at RCE

Mandiant observed a consistent sequence in compromised PeopleSoft environments.

Attackers first verified whether the server was vulnerable.

They typically sent several POST requests containing serialized Java objects to the encoded PSEMHUB endpoint.

Once exploitation succeeded, they deployed web shells.

The shells provided persistent command execution through the PeopleSoft web tier.

From there, the attackers moved deeper into the operating system.

Some commands executed with root or NT AUTHORITY\SYSTEM privileges.

Others ran as PeopleSoft or WebLogic service accounts.

Those service accounts still had access to valuable application configuration and database connection information.

This is where an application RCE becomes an enterprise problem.

Web shells everywhere

Mandiant found web shells on dozens of compromised systems.

The attackers placed malicious JSP files inside PeopleSoft application directories.

Investigators identified filenames including:

x.jsp

u.jsp

tunnel.jsp

tunnel.jspx

and

Ple64.exe

The exact filename is less important than the location.

A JSP web shell sitting inside a web application gives the attacker a reusable command execution mechanism.

The initial exploit can disappear from the logs.

The shell remains.

ShinyHunters also used MeshCentral

The attackers didn’t rely exclusively on custom malware.

Mandiant observed deployment of MeshAgent, a legitimate remote-management component associated with the open-source MeshCentral project.

That gives attackers interactive remote access while hiding behind software that can have legitimate administrative uses.

This is another problem for defenders.

Blocking “malware” isn’t enough when the attacker uses legitimate administration tools.

A security team has to ask a more useful question:

Why is this server running this software, and who installed it?

Credentials became another target

A compromised PeopleSoft server can contain extremely valuable secrets.

Mandiant observed attackers accessing PeopleSoft configuration files and extracting information such as database connection strings.

The PeopleSoft application service account can also have access to Integration Broker credentials and other application secrets.

The attacker therefore doesn’t need to immediately attack the database from the outside.

The application server may already contain the keys.

Compromise the application.

Read the configuration.

Recover the credentials.

Move to the database.

Simple.

The attackers changed their infrastructure

Mandiant also observed infrastructure designed to look like Microsoft or Azure services.

Earlier campaigns used domains such as:

azurenetfiles.net

microsoft-entra.net

and

enroll.azuredevice.cloud

The goal isn’t subtle malware.

It’s camouflage.

Enterprise defenders generate huge amounts of traffic involving Microsoft, Azure, identity services and cloud management infrastructure.

A malicious connection that looks vaguely like another corporate cloud service has a better chance of surviving initial detection.

This campaign crossed multiple industries

The renewed campaign isn’t restricted to universities.

Mandiant says it observed compromised systems across:

• higher education
• technology
• IT services
• healthcare
• agriculture
• transportation
• government

That matters because PeopleSoft isn’t a niche application.

It is enterprise infrastructure.

A vulnerability in a rarely used desktop application has a very different risk profile from an unauthenticated RCE in software that may sit at the center of a large organization’s business processes.

The original zero-day was already serious

CVE-2026-35273 was originally exploited between May 27 and June 9, 2026, before Oracle released its June 10 security alert.

That means it was a genuine zero-day during the original campaign.

Oracle’s advisory says successful exploitation can result in remote code execution and takeover of PeopleSoft Enterprise PeopleTools.

The original campaign primarily targeted higher-education organizations.

The renewed campaign demonstrates something defenders should expect from serious threat actors:

Once an exploit becomes public, it doesn’t become less useful.

It becomes cheaper.

Attackers can improve it.

Automate it.

Modify it.

Combine it with new infrastructure.

And search for organizations that patched slowly.

A WAF is not a patch

This is probably the most important lesson from the campaign.

A WAF rule can reduce exposure.

It can buy time.

It can block obvious exploit traffic.

But if the vulnerable application remains exposed, you’re still depending on every component in the HTTP processing chain to interpret the request exactly the way you expect.

ShinyHunters demonstrated what happens when they don’t.

The WAF sees:

/%50SEMHUB/

The application sees:

/PSEMHUB/

The attacker sees:

remote code execution.

What PeopleSoft administrators should do

First: apply Oracle’s security update for CVE-2026-35273.

Do not treat the WAF as the final solution.

Second: if the Environment Management Hub isn’t required, disable the EMHub service or remove the PSEMHUB application according to Oracle’s guidance.

Third: inspect WebLogic and PeopleSoft access logs.

Search for:

/PSEMHUB/

and encoded variants such as:

/%50SEMHUB/

Pay particular attention to POST requests hitting /hub.

Also investigate unexpected JSP and JSPX files.

Mandiant specifically recommends checking the PSEMHUB application directory for files that aren’t part of the original installation.

If you suspect compromise

Don’t just patch and walk away.

Assume the attacker may already have persistence.

Investigate:

• unexpected JSP/JSPX files
• new system services
• MeshAgent installations
• suspicious outbound connections
• shell processes spawned by WebLogic
• unexpected curl or wget
• /bin/sh and bash execution from Java processes
• suspicious database access
• changes to PeopleSoft configuration
• unknown administrator accounts
• unexpected credentials or API tokens

Rotate credentials that were accessible to the compromised PeopleSoft service account.

That includes database credentials and Integration Broker secrets.

If attackers obtained operating-system-level access, treat the server as compromised infrastructure, not simply as a patched application.

Bugstoday opinion

This is what happens when defenders confuse blocking an exploit with removing the vulnerability.

The WAF wasn’t useless.

It simply wasn’t enough.

ShinyHunters changed one character in the URL representation and walked around the rule.

That is the entire story.

The vulnerable PeopleSoft endpoint remained there.

The application still decoded it.

The exploit still worked.

The attackers still got web shells.

The lesson is brutally simple:

Patch the application. Don’t build your security strategy around hoping the attacker sends the URL in exactly the format your WAF expects.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Google Threat Intelligence Group / Mandiant — ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft
• Oracle Security Alert — CVE-2026-35273
• Oracle PeopleSoft Security Advisory
• CVE.org — CVE-2026-35273