TL;DR: SAP NetWeaver AS Java Visual Composer CVE-2025-31324 enables unauthenticated remote code execution through the metadata uploader endpoint, and public exploit code now makes abuse far easier for unpatched systems, according to Pathlock. Patch urgency is now inseparable from exposure reduction and post-compromise hunting because the blast radius can extend into adjacent identity-connected systems.
NHIMG editorial — based on content published by Pathlock: analysis of SAP NetWeaver CVE-2025-31324 and public exploit activity
Questions worth separating out
Q: What breaks when SAP NetWeaver Visual Composer is exposed to unauthenticated upload abuse?
A: The failure is that an untrusted request can enter a trusted SAP Java execution path without authorization.
Q: Why do service accounts increase the impact of pre-auth RCE in SAP environments?
A: Because the application runtime is a non-human identity with standing reach into downstream portals, integrations, and system resources.
Q: How should teams know whether SAP upload-path controls are actually working?
A: Look for two signals: the vulnerable endpoint is unreachable from untrusted networks, and logs show no unexpected POST traffic or new files under SAP runtime paths.
Practitioner guidance
- Patch every reachable SAP Java instance first Apply SAP Security Note 3594142 and the related corrective note 3604119 across all nodes, then verify that clustered systems were updated consistently and restarted where required.
- Block the metadata uploader at the edge Restrict or block /developmentserver/metadatauploader at SAP Web Dispatcher, ICM, and WAF layers, and remove internet reach from any development or administrative endpoint.
- Hunt for upload and persistence artefacts Search HTTP and ICM logs for POST requests to the uploader path, then inspect IRJ servlet directories for unexpected JSP or class files and quarantine anything suspicious.
What's in the full article
Pathlock's full research covers the operational detail this post intentionally leaves for the source:
- Packet-level and log-level hunt guidance for the metadata uploader path and related SAP Web Dispatcher and ICM events
- Verification steps for applying SAP Security Note 3594142 and the related corrective note 3604119 across clustered environments
- Practical examples of post-exploitation artefacts such as JSP persistence files, shell spawning, and outbound beaconing
- Additional analysis of the public exploit structure and the defensive heuristics Pathlock used to identify success
👉 Read Pathlock's analysis of SAP NetWeaver CVE-2025-31324 exploitation →
SAP NetWeaver CVE-2025-31324: are your controls keeping up?
Explore further
Unauthenticated RCE against SAP NetWeaver is really a non-human identity failure. The vulnerability matters because the application runtime acts as a privileged service identity, not because a generic web server was exposed. When that runtime accepts attacker-controlled content without authorization, the trust boundary around the SAP service account collapses and the application becomes an execution broker for outsiders. Practitioners should treat the service account as the security object that failed, not just the endpoint that was hit.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
- Only 44% of organisations are currently using a dedicated secrets management system.
A question worth separating out:
Q: Who is accountable when a public SAP exploit leads to lateral movement into identity systems?
A: The accountable teams are the application owners, SAP platform owners, and identity defenders who manage the downstream trust chain. The breach is not only about patching a CVE. It also reflects whether service-account scope, endpoint exposure, and recovery procedures were governed as a single control set.
👉 Read our full editorial: SAP NetWeaver CVE-2025-31324 exposes the danger of pre-auth RCE