.svg)
.svg)
The key lesson is not that the vulnerable code was open source. It was not. The lesson is that trusted first-party Java code contained a dangerous deserialization path that attackers could reach from the outside and turn into remote code execution.
The breach of the FBIJobs environment looked, at first, like another patching failure. Reuters reported that an Accenture contractor supporting the FBI failed to apply a critical Oracle PeopleSoft security update, and that ShinyHunters exploited the exposed system. Oracle later said it found no evidence that the recent attacks required a new PeopleSoft zero-day. The evidence now points back to a known and patched weakness in PeopleSoft — CVE-2026-35273.
That matters operationally. But the more important technical lesson is what the application actually did when it was attacked.
The attack path ran through Java deserialization
Google Mandiant observed ShinyHunters exploiting PeopleSoft’s PSEMHUB component at scale. Before exploitation, targeted servers received repeated POST requests containing serialized Java objects. Once a system was confirmed vulnerable, Mandiant observed two exploitation paths: web-shell deployment and fileless command execution. Both abused Java deserialization inside the PSEMHUB hub servlet.
In the fileless variant, the legitimate WebLogic Java process spawned operating-system shells such as cmd.exe or /bin/sh. No malicious executable needed to be present on disk before the application itself crossed from trusted Java execution into operating-system command execution.
The vulnerable path was first-party PeopleSoft code
This was not an open-source library vulnerability. Researchers at Fortra/Core Security decompiled the shipped PSEMHUB.war application and traced the vulnerable flow through PeopleSoft classes. Their analysis identified PeopleSoft’s EMObjectInputStream deserialization path and a first-party class named ExecuteProcessActivityCommand.
The important point is not the class name itself. It is what the class could do. The class exposed functionality that could write attacker-controlled content to a chosen file. Once attacker-controlled serialized data reached that trusted class through the vulnerable path, the application’s own functionality became part of the exploit chain.
The attacker did not need to introduce the dangerous capability. The capability was already inside the trusted enterprise application. The attacker needed only to discover a path to reach it.
“The capability was already inside the application. The attacker simply discovered a path to reach it.”
Closed source is not invisible to attackers
PeopleSoft is commercial software, but that does not make its runtime behavior opaque. Java applications are shipped as bytecode inside JAR and WAR files. Researchers demonstrated that PSEMHUB.war could be decompiled and its classes, methods, deserialization paths, and dangerous capabilities studied in detail.
There is no public evidence proving that ShinyHunters discovered the bug using exactly that reverse-engineering workflow. But the defensive research proves the broader point: attackers do not need a vendor’s private source repository to study a widely deployed Java application. Shipped code can be enough.
For open source, the attacker reads the source. For commercial Java software, the attacker can often study the bytecode. The mechanics are different. The resulting attack surface can be very similar.
Once the weakness was understood, the attack scaled
Mandiant observed ShinyHunters validating exposed PeopleSoft systems remotely before exploiting them. In the renewed campaign, attackers sent a small series of serialized Java requests to the PSEMHUB endpoint and used the response to determine whether the system remained exploitable. The same application behavior could then be reused across organizations running the same vulnerable code.
They also adapted when defenders tried to compensate without patching. Mandiant documented a simple URL-encoding bypass that slipped past literal WAF rules while WebLogic still decoded the path and routed the request to the vulnerable servlet. The perimeter rule changed. The dangerous runtime behavior did not.
This is why runtime security matters
Traditional vulnerability management asks: “Which package is vulnerable?” That is an important question, but it is not enough. This incident shows why defenders also need to ask: “What is this code allowed to do when it executes?”
From a runtime perspective, the origin of the code is secondary. It can be open source, third-party commercial software, or first-party application code. If externally influenced data reaches a sensitive capability — deserialization, file modification, process creation, command execution, network access — that transition is what matters.
Raven is built around that principle. Raven observes application behavior at runtime and is designed to enforce sensitive capabilities based on the code path that reaches them. The goal is not simply to know that a CVE exists. The goal is to prevent trusted application code from being turned into an attacker’s execution path.
The FBI breach is a patching story — but not only a patching story
The immediate operational failure was straightforward: an available security update was not applied. That deserves attention. But “patch faster” is not a complete security strategy, because the attack technique existed before defenders understood it, perimeter mitigations were later bypassed, and the vulnerable behavior lived inside a legitimate enterprise application.
The deeper lesson is this:
Raven takeaway: The perimeter saw an HTTP request. The runtime saw Java deserialization become code execution.
Explore how Raven prevents exploits with or without a CVE.
Research sources
• Reuters — Accenture contractor removed from FBI following damaging data breach (Oct. 6, 2026)
• Oracle — PeopleSoft Security Update and Guidance (Oct. 2, 2026)
• Fortra / Core Security — Analysis of CVE-2026-35273: Oracle PeopleSoft PeopleTools
