How to Detect and Fix the SAP NetWeaver Zero-Day: A Technical Recap

In Episode 1 of our new docuseries, Hacking & Defending SAP Applications Live, Onapsis researchers Ignacio Favro and Fabian Hagg analyzed the first mass-exploited SAP zero-day (CVE-2025-31324 and CVE-2025-42999). Sophisticated threat actors leveraged this previously unknown flaw to compromise hundreds of SAP customers. 

This article serves as a practitioner’s recap of that session, breaking down the mechanics of the exploit and providing actionable remediation steps for SAP security teams.

How Do The CVE-2025-31324 & CVE-2025-42999 Exploits Work?

The CVE-2025-31324 and CVE-2025-42999 exploit works by sending a malicious serialized object to an unauthenticated HTTP endpoint within the SAP NetWeaver Visual Composer Metadata Uploader.

A deserialization vulnerability is a flaw that occurs when an application reconstructs runtime objects from formatted data in a serialized byte stream without applying proper input validation or sufficient restrictions on available object classes. It’s critical for security teams because it enables adversaries to chain together existing code blocks (gadgets) with an exploit primitive to trigger unexpected code execution during the deserialization process. 

The analyzed exploit relies on a highly complex gadget chain that demonstrates the advanced expertise of the threat actors. Attackers engineered this payload by combining a custom-built sequence of gadgets from SAP-specific libraries with a well-known code execution sink commonly utilized in the ysoserial payload generation tool. To evade classic signature-based detection by intrusion detection systems, the authors intentionally altered specific values within the malicious byte stream. 

Furthermore, it was seen that the threat actors dynamically adapted the byte stream at runtime to probe target systems and tailor the payload against different software versions, establishing a more stable exploit capable of executing arbitrary remote commands on vulnerable systems.

Once the payload is successfully deserialized, the intrusion rapidly escalates. As demonstrated in our live attack simulation, a typical attack scenario unfolds in phases:

• Initial Access & Persistence: The attacker targets the unauthenticated endpoint with a payload to immediately deploy a .jsp web shell, establishing persistent remote access under the highly privileged <sid>adm user context.

While specific post-exploitation activities may vary, demonstrated attack scenarios highlight the critical potential impact of a successful breach. Once an attacker establishes administrative access, they possess the capability to execute the following high-impact objectives:

• Credential Exfiltration: Threat actors can download critical configuration files, such as SecStore.properties, directly from the server to extract the underlying database credentials.
• Data Manipulation and Disruption: Utilizing compromised database access, adversaries can execute unauthorized SQL queries to manipulate core business data, alter financial transactions, or trigger system commands that completely shut down the SAP environment.

How to Hunt for CVE-2025-31324 & CVE-2025-42999 Indicators of Compromise (IOCs)

Hunting for CVE-2025-31324 & CVE-2025-42999 indicators of compromise requires inspecting Java trace logs for unauthorized deserialization events and checking the file system for dropped web shells. 

Because attackers deploy web shells to maintain persistent remote access even after a system is patched, identifying and removing these artifacts is mandatory.

Required Tools and Access for IOC Hunting

You need access to your SAP Java trace logs, file system administrative rights, and an active SAP vulnerability management solution.

1. Step 1: Check the File System for Web Shells: Inspect the specific directories on the Java system where attackers typically drop web shells. Search for unrecognized .jsp files, paying close attention to filenames consisting of exactly eight random characters or known malicious filenames associated with these campaigns. Refer to SSN 3604119 and our threat research for the complete list of file indicators.
2. Step 2: Analyze Java Trace Logs: Inspect the trace files from the Java system for unauthorized deserialization activity. Because the exact error messages differ from generic execution logs, security teams must cross-reference their trace files against the specific indicators detailed in the SAP Security Notes.
3. Step 3: Audit Highly Privileged Execution: Check logs for unauthorized commands executed under the <sid>adm user context, or unexpected access to the SecStore.properties file.

Verification 

Run the open-source Onapsis and Mandiant joint IOC scanning tool against your environment to programmatically verify that no hidden web shells or compromised credentials remain in your systems.

How to Remediate the SAP Visual Composer Flaw

Remediating the SAP Visual Composer flaw requires a multi-step patching process. Organizations must first apply the out-of-band SAP Security Note 3594142 (addressing CVE-2025-31324) to enforce authentication on the vulnerable HTTP endpoint. To fully address the underlying deserialization process and enforce strict class filtering, security teams must also apply the subsequent SAP Security Notes 3660659 and 3604119 released during standard Patch Tuesday cycles.

Applying these patches restricts the Java Virtual Machine from deserializing the specific malicious classes abused in the attacker’s gadget chain, neutralizing the root cause of the vulnerability.

Patching Requirements and Portal Access

Administrative access to the affected SAP environment and access to the SAP Support Portal to download the emergency patch (3594142) and the subsequent patch day notes. 

• Step 1: Download Required Security Notes: Log in to the SAP Support Portal to retrieve the specific SAP Security Notes addressing CVE-2025-31324 and CVE-2025-42999. To ensure comprehensive protection across all related vulnerabilities and entry points, you must download the following suite of notes: SSN 3620498, SSN 3660659, SSN 3594142, SSN 3578900, SSN 3621771, SSN 3685286, SSN 3604119, SSN 3634501, SSN 3660969, SSN 3657998, SSN 3610892, SSN 3670067, and SSN 3621236.
• Step 2: Configure the JVM Serial Filter: Implementing the protection requires modifying the Java Virtual Machine parameters to block malicious classes. Access the NetWeaver Administrator (NWA) portal at http(s)://<host>:<port>/nwa (replacing <host> and <port> with your system’s specific variables). Navigate to Configuration, select Infrastructure, and open Java System Properties. Ensure you select the active template and navigate to the System VM Parameters section. Add a new parameter with the name jdk.serialFilter and set the value to the exact list of restricted classes and packages specified in SSN 3660659.
• Step 3: Restart the System: Perform the required system restart to ensure the new class filtering rules are actively enforced by the Java Virtual Machine.

Verification

Attempt to reach the metadata uploader HTTP endpoint via an unauthenticated network request. Receiving an access denied response confirms the successful implementation of SAP Security Note 3594142. Because this network test only validates endpoint authentication, security administrators must manually review the system configuration and patch levels to verify the correct application of the JVM Serial Filter and the specific patch for CVE-2025-42999 (SAP Security Note 3604119).

Through active collaboration with the SAP Product Security Response Team, Onapsis Research Labs responsibly disclosed additional exploit entry points (CVE-2025-30012, CVE-2025-42966, CVE-2025-42964, CVE-2025-42980, CVE-2025-42963, CVE-2025-42944, CVE-2025-42884, CVE-2026-0504) and code gadgets (CVE-2025-42928).

For a behind-the-scenes look at the discovery timeline and what active exploitation revealed about modern adversaries, watch the on-demand session on the SAP and Onapsis joint response to CVE-2025-31324.

How to Implement Compensating Controls Without Downtime

Implementing compensating controls requires configuring your SIEM and SAP threat detection tools to identify and block the specific raw event details associated with the exploit. Applying patches immediately isn’t always feasible for production ERP systems. If you must delay patching to wait for a scheduled maintenance window, you must implement continuous SAP threat monitoring.

Required SOC and SIEM Capabilities

 An active SIEM integration with your SAP environment and a dedicated SOC team.

1. Step 1: Configure Endpoint Monitoring: Set alerting rules in your SIEM to monitor all traffic destined for the SAP NetWeaver Visual Composer HTTP metadata uploader endpoint.
2. Step 2: Alert on Unauthenticated Access: Flag any unauthenticated requests to this specific URL. The SIEM must capture the raw event details, including the extraction time, the target ERP system, and the source IP.

Verification

Run a benign, simulated unauthenticated request against the endpoint. Verify that the event successfully triggers a high-priority alert in your SIEM dashboard within one minute, ensuring your SOC has the visibility needed to initiate an incident response.

To see exactly how attackers manipulate this vulnerability and how the Onapsis Platform automatically detects these threats in real-time, watch Episode 1 of Hacking & Defending SAP Applications Live here.