CVE-2025-31324 – Exploitation Report

Exploit Performed By: Authorized Tester (Ethical Purpose Only)

1. Executive Summary

This document confirms the successful exploitation of CVE-2025-31324, a vulnerability in SAP NetWeaver Visual Composer Metadata Uploader, which allows unauthenticated file upload leading to remote code execution. The exploit was executed in a controlled environment using Apache Tomcat and Kali Linux.

2. Vulnerability Details

CVE-2025-31324 enables remote attackers to upload crafted .jsp files through a misconfigured or exposed metadata uploader endpoint in SAP NetWeaver Visual Composer. If executed, this file can lead to arbitrary system-level command execution without authentication.

3. Test Environment Setup

Operating System: Kali Linux

Web Server: Apache Tomcat 10

Port Used: 9091

Localhost URL: http://127.0.0.1:9091

Test File: cache.jsp (with embedded command execution payload)

4. Exploitation Steps

1. Started a Python HTTP server to simulate vulnerable endpoint.

2. Uploaded cache.jsp to the server using the exploit script.

3. Verified command execution via browser:   

- http://127.0.0.1:9091/cache.jsp?cmd=whoami → Output: tomcat   

- http://127.0.0.1:9091/cache.jsp?cmd=cat /etc/passwd → Output: full /etc/passwd contents

- http://127.0.0.1:9091/cache.jsp?cmd=ls -ll → Output: directory listing

A) Understanding SAP & Its Core Components:

SAP is a business software platform used by large enterprises to manage critical operations like finance, HR, payroll, logistics, and inventory — all in one place. Instead of running separate tools, companies use SAP to centralize these workflows into a unified system. The foundation that powers most SAP applications is called SAP NetWeaver, which acts like the core server or operating system for SAP modules. It provides the runtime environment needed for SAP apps to function.

NetWeaver comes in two major stacks: the ABAP stack, which is SAP’s proprietary programming environment used in traditional SAP systems, and the Java stack, which supports web-based applications using technologies like JSP and servlets. The vulnerability CVE-2025-31324 specifically affects the Java-based NetWeaver, not the ABAP side.

Running on top of NetWeaver Java is a tool called SAP Visual Composer. It allows SAP users and developers to design interfaces — like forms, dashboards, and workflows — without writing code. These UIs are created visually and then deployed directly onto the NetWeaver server. Visual Composer relies internally on a backend module called vcframework, which is responsible for receiving and handling uploaded UI definition files (metadata). This is where the vulnerability lies.

The component vcframework includes a metadata uploader endpoint that was found to accept file uploads without requiring any authentication. An attacker can abuse this by uploading a .jsp file (Java Server Page), which is executable code. Since SAP NetWeaver Java includes a JSP engine, the server will automatically compile and run this uploaded JSP file when accessed through a browser — resulting in remote code execution. This means an attacker could run arbitrary system commands without any login or credentials.

While SAP MMC (Microsoft Management Console) is not directly vulnerable, it is used by administrators to manage and control NetWeaver services — such as starting or stopping the Visual Composer or Java services. In production environments, this tool is crucial for maintaining the affected components.

So in full connection — SAP runs business logic, NetWeaver hosts the logic, Visual Composer builds the interface, vcframework processes uploads, and the vulnerability lets anyone upload executable code via this chain — leading to full system compromise.

B) Connection to CVE-2025-31324:

1. SAP applications run on NetWeaver Java

2. Visual Composer runs inside NetWeaver Java

3. Visual Composer uses vcframework to handle uploaded metadata

4. vcframework has a vulnerable upload endpoint

5. That endpoint allows unauthenticated upload of .jsp files

6. Uploaded .jsp files are placed in the public webroot

7. NetWeaver’s JSP engine executes them — leading to Remote Code Execution

8. No login, no session, no security in place — critical impact

C) The issue occurs because:

the vcframework component of SAP NetWeaver Visual Composer exposes an upload endpoint (/developmentserver/metadatauploader) that does not enforce authentication or proper file validation. This allows unauthenticated attackers to upload arbitrary .jsp files directly to the server’s web-accessible directory. When accessed, these files are executed by the underlying JSP engine, leading to full remote code execution without any user session or permission checks.

5. impact of CVE-2025-31324

This vulnerability allows unauthenticated remote attackers to achieve full remote code execution (RCE) on SAP NetWeaver Java systems. By uploading a crafted .jsp file through the exposed metadata upload endpoint, an attacker can execute arbitrary operating system commands with the privileges of the application server (typically the tomcat user). This can lead to:

·       Unauthorized access to sensitive business data

·       System compromise and lateral movement within the internal network

·       Installation of backdoors or malware on the SAP infrastructure

·       Disruption of critical enterprise functions running on SAP

Given SAP's role in handling core business operations, exploitation of this vulnerability poses a critical risk to business continuity, data integrity, and infrastructure security the CVSS Base Score is 10.0 CRITICAL.

6. Environment and Setup

The exploitation of CVE-2025-31324 was performed in a controlled, isolated environment simulating a vulnerable SAP NetWeaver Java server. Since full SAP deployment was not required to validate the vulnerability behavior, the setup focused on replicating the JSP execution behavior using Apache Tomcat.

• Operating System: Kali Linux (latest)

• Web Server: Apache Tomcat 10 (used to simulate SAP NetWeaver Java's JSP engine)

• Port Used: 9091 (default 8080 reassigned due to port conflict)

• Testing Interface: Web browser and command-line tools

• Payload File: cache.jsp – custom JSP web shell with command execution support

• Execution Path: /var/lib/tomcat10/webapps/ROOT/cache.jsp

• Access URL: http://127.0.0.1:9091/cache.jsp?cmd=whoami

This configuration accurately replicates the vulnerable behavior by demonstrating unauthenticated upload, successful server-side code execution, and real-time response

7. Sharing CVE-2025-31324 PoC: Learn, Analyze, Secure

1. Payload Engine Deployment – Internal Build

#git clone https://github.com/ODST-Forge/CVE-2025-31324_PoC

#cd CVE-2025-31324

2. Install and Start Apache Tomcat

To simulate the vulnerable SAP Java environment (which executes JSP files), you installed Apache Tomcat as the Java webserver:

#sudo apt update

#sudo apt install tomcat10 -y

#sudo systemctl start tomcat10

#sudo systemctl enable tomcat10

Verify Tomcat is Running:

http://127.0.0.1:8080

3. Copy JSP Payload to Tomcat Webroot

Now you moved the exploit payload (cache.jsp) into the Tomcat webroot so it becomes directly accessible and executed.

#sudo cp cache.jsp /var/lib/tomcat10/webapps/ROOT/

Expected Access URL:

http://127.0.0.1:9091/cache.jsp

Note: Port 9090/91 was used if 8080 was already taken by another tool like Burp Suite.

4. Use PoC.py to Upload cache.jsp

Instead of manually copying, you used the official exploit script PoC.py to upload the malicious cache.jsp — mimicking the actual SAP vulnerable upload endpoint.

5. Trigger the JSP Payload

Open your browser and access:

http://127.0.0.1:9091/cache.jsp?cmd=whoami

try to access some files or commands:

The uploaded JSP was executed successfully via the vulnerable endpoint. Commands like cat /etc/passwd, ps aux, and id were executed remotely, confirming unauthenticated Remote Code Execution (RCE).

Post exploitation confirmed access to the underlying Linux environment running Apache Tomcat 10.0. The server allows unrestricted code execution, revealing system hostname, kernel version, active users, and running services.

Why Uploading on Port 9090 Works But Execution Happens via 9091

The .jsp file was uploaded through port 9090, which saved it in the shared Tomcat webroot directory (/webapps/ROOT/). Port 9091 runs the active Tomcat10 server, which serves files from that same directory.

So even though the upload happened on 9090, the file is accessible and executed through 9091 because both ports share the same file system path.

This behavior is important to understand during exploitation, as many systems expose different services across multiple ports but rely on a common backend.

  No login

Working upload

  Fully executed malicious .jsp  

Remote Code Execution achieved

8. Recommendations

- Immediately restrict access to the vulnerable endpoint.

- Validate MIME types and sanitize file upload paths.

- Disable direct .jsp execution in upload directories.

- Apply patches from SAP if available.

- Regularly audit and monitor HTTP file uploads.

9. Confirmation

This document confirms a real and complete exploitation of CVE-2025-31324.