Composing a Catastrophe: Dissecting SAP NetWeaver’s CVE-2025-31324 File-Upload Flaw

TL;DR —

What broke: A totally unauthenticated file-upload endpoint in Visual Composer lets anyone drop arbitrary files (e.g., a JSP web-shell) onto the server.
Why it’s bad: Upload ⇒ web-accessible path ⇒ one HTTP GET ⇒ remote code execution as the SAP service account (often high-privilege). Active exploitation observed in the wild.
Who’s affected: Any NetWeaver system with the Visual Composer “development server” component enabled and reachable (especially if exposed to the internet).
Exploit:

It was a quiet day in the SAP data center—until a rogue “composer” strolled in carrying a malicious payload, completely uninvited. CVE-2025-31324 is the technical name for this party crasher: a critical zero-day vulnerability in SAP NetWeaver that left a backdoor propped open in the Visual Composer component. The result? Unauthenticated attackers could waltz right in and upload anything (yes, anything), from webshells to malware, onto mission-critical SAP servers. This vulnerability scored a perfect 10.0 on the CVSS severity scale for good reason. In this post, we’ll dive deep (with a dash of wit) into how this flaw works, show a bit of code that makes security folks cringe, and offer guidance on how to fix the mess and avoid such “compositions” in the future.

What is CVE-2025-31324?

CVE-2025-31324 is an unauthenticated file upload vulnerability in SAP NetWeaver’s Visual Composer module bleepingcomputer.com. Visual Composer (software component VCFRAMEWORK) is an add-on for SAP’s Java-based NetWeaver Application Server that lets users build applications via a graphical interface (essentially a “low-code” tool). Unfortunately, one of its helper services – the Metadata Uploader – wasn’t playing by the security rules. A missing authorization check in this uploader endpoint meant anyone, without logging in, could upload arbitrary files to the server’s filesystem ionix.ioionix.io. As SAP themselves described it, the uploader was “not protected with a proper authorization”nvd.nist.gov, turning it into a proverbial unlocked door.

This flaw is categorized as CWE-434 (Unrestricted File Upload)nvd.nist.gov. In practical terms, it allows an attacker to drop malicious files (for example, a JSP webshell, a WAR package, or even native binaries) into sensitive locations on the server, leading to instant Remote Code Execution (RCE) under the privileges of the SAP server process ionix.io. In many SAP landscapes, that means code execution as an administrative OS user (the <sid>adm account) – a nightmare scenario for any enterprise.

Notably, Visual Composer is not always installed by default. It’s often an optional component used for modeling workflows. However, many SAP environments do have it enabled (sometimes unknowingly) if they installed the add-on or if it came along with certain packages . Systems exposing the Visual Composer development service to the internet (intentionally or via misconfiguration) were at the highest risk ionix.io. And as it turned out, attackers on the internet found this flaw before SAP did – making CVE-2025-31324 a true zero-day that was exploited in the wild prior to a patchbleepingcomputer.com.

How the Exploit Works

At its core, CVE-2025-31324 exists because the Visual Composer Metadata Uploader doesn’t ask “Who are you?” or “What are you giving me?” when someone sends it a file. Let’s break down the exploit flow step by step:

Figure: How an attacker exploits CVE-2025-31324 to get Remote Code Execution on SAP NetWeaver. The Metadata Uploader happily accepts a malicious JSP file without authentication, saves it in a web-accessible directory, and the attacker then invokes it to execute code on the server.

POST /developmentserver/metadatauploader?CONTENTTYPE=MODEL&CLIENT=1 HTTP/1.1
Host: sap-victim.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
Content-Length: 12345

------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="shell.jsp"
Content-Type: application/octet-stream

<%-- Malicious JSP code (webshell) goes here --%>
------WebKitFormBoundary--

The server-side code responsible for this endpoint (in pseudocode) might look like this:

public void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    // Missing authentication/authorization check!
    Part filePart = req.getPart("file");
    if (filePart != null) {
        String fileName = Paths.get(filePart.getSubmittedFileName()).getFileName().toString();
        // No validation on file type or content – dangerous!
        File dest = new File(UPLOAD_DIR, fileName);
        Files.copy(filePart.getInputStream(), dest.toPath());
    }
    // ... (return success response)
}

What’s wrong here? Two glaring issues: (a) There’s no check to ensure the requester is an authorized user (the code should require an authenticated session or specific role, but it doesn’t). (b) There’s no restriction on file type or path; the code blindly writes whatever file is provided to a directory on the server. The combination of these flaws is lethal. As Ionix security researchers succinctly put it, “a missing authorization check allows unauthenticated attackers to upload arbitrary files (JSP, WAR, JAR, or executables) to the application server’s filesystem”ionix.io. And because the uploader doesn’t discriminate by MIME type or extension, even dangerous file types are accepted (a JSP is essentially executable code on a Java server)ionix.io.
File Gets Saved in a Web-Accessible Directory – The Visual Composer uploader stores the file in a specific folder within the SAP NetWeaver application directory. According to incident reports, the files typically land in the Visual Composer’s web content area. For example, on a NetWeaver Java system on Linux you might find the uploaded file under a path like:/usr/sap/<SID>/JC<##>/j2ee/cluster/server0/apps/sap.com/visual_comp/servlet_jsp/myapp/root/shell.jsp (as observed in one exploit) ionix.io.On other systems, the path could be under the Portal’s directory (e.g. sap.com/irj/servlet_jsp/irj/root/ or .../irj/work/ directories) onapsis.comonapsis.com – essentially wherever the Visual Composer or portal runtime stores its content. The key is that the file ends up in a publicly accessible web directory of the SAP server.
Remote Code Execution via the Uploaded File – Once the malicious file is saved on the server, the attacker can execute it by simply sending an HTTP GET request to the file’s URL. For instance, the JSP uploaded as shell.jsp might be accessible at https://sap-victim.example.com/visual_comp/myapp/shell.jsp (or a similar URL path)ionix.io. When the attacker invokes this URL, the SAP server executes the JSP code. In the case of a webshell, that code might allow the attacker to run arbitrary commands on the server with the privileges of the SAP service account. In real attacks, after uploading webshells, threat actors were able to send commands via HTTP that the JSP would execute on the OS, effectively giving them a remote shell in the SAP environment bleepingcomputer.com.
Post-Exploitation Mayhem – With code execution achieved, attackers typically deploy further malicious tools or backdoors. In documented incidents, attackers quickly moved to deploy advanced payloads like the Brute Ratel C2 framework and other malware agents via the webshellbleepingcomputer.com. They even used techniques like “Heaven’s Gate” to evade detection and injected payloads into system processes like dllhost.exe on Windows bleepingcomputer.com. Essentially, the initial webshell was a stepping stone to a full-blown compromise: once inside the SAP server, attackers could pivot deeper into the network, steal sensitive data, or disrupt operations. As security researchers at WatchTowr noted, this vulnerability “means full Remote Code Execution and total system compromise” for the victim bleepingcomputer.com. In many cases, the SAP NetWeaver server has connections to crown-jewel databases (ERP, HR, finance data) and runs with high privileges, so the blast radius of a compromise is enormous ionix.io.

In summary, CVE-2025-31324 turns a normally innocuous feature (uploading metadata for Visual Composer) into a full-fledged attack vector. With a single unauthenticated HTTP request, an outsider can plant a backdoor on an SAP system and execute it to take control. It’s the equivalent of finding an unlocked delivery door to a bank vault – just drop in a “package” and walk out with the goods.

Real-World Exploitation and Impact

This vulnerability isn’t just theoretical. Active exploits were observed in the wild even before SAP released a patch. In mid-April 2025, security analysts from ReliaQuest detected multiple SAP servers being compromised via unauthorized file uploads bleepingcomputer.com. The attackers used the flaw to upload JSP webshells (malicious scripts) into publicly accessible directories on SAP NetWeaver systems bleepingcomputer.com. They then sent simple HTTP requests to those webshells to execute commands remotely – effectively gaining a foothold on the SAP servers without any credentials.

Once inside, the attackers escalated their attack, deploying persistence and post-exploitation tools. For example, they dropped Brute Ratel, a sophisticated red-team toolkit, likely to establish a more robust command-and-control channelbleepingcomputer.com. Observers also saw usage of Cobalt Strike beacons and even attempts to create rogue Java applications on the SAP server to survive future patching (so that even if the vulnerability is fixed, the backdoor remains)ionix.io. In at least one case, the attackers injected payloads into system processes to hide their presence bleepingcomputer.com.

The impact of a successful attack through CVE-2025-31324 is severe. Consider the potential consequences (many of which were noted by security researchersionix.ioionix.io):

Complete System Takeover – The attacker can execute arbitrary code with the same privileges as the SAP application server. They could read, modify, or delete any data that the SAP server itself can access ionix.io. Given SAP’s deep integration, this could mean full control of business processes.
Data Theft or Tampering – Sensitive data (financial records, personal data in HR systems, intellectual property in databases) could be extracted or altered. Attackers could quietly exfiltrate databases or, worse, manipulate data (imagine falsifying financial entries or changing a payroll) ionix.io.
Disruption of Services – An attacker could deploy ransomware or simply sabotage the system, causing downtime on critical ERP functions. For enterprises, that could halt production lines or logistics if SAP is at the core of those operations.
Lateral Movement – With an SAP server under control, attackers can often pivot into the broader corporate network. They might use the compromised server to attack other connected systems (including SAP ABAP servers, database servers, or even non-SAP systems that trust the SAP server) ionix.io.
Stealthy Persistence – Attackers may leave behind new user accounts, scheduled tasks, or additional backdoor web applications to maintain access even after the initial hole is patched ionix.io. The “uninvited guest” might stick around undetected, continuing to harvest data or await a more opportune moment to strike.
Reputational and Compliance Fallout – A breach of this magnitude can trigger regulatory issues (consider GDPR for personal data or SOX for financial systems) and damage an organization’s reputation. Clients and partners may lose confidence in the company’s security practices.

It’s worth noting that SAP released an emergency patch for this issue on April 24, 2025, outside of their normal patch cycle bleepingcomputer.combleepingcomputer.com. The vulnerability was serious enough that government agencies took note: on April 29, 2025, the U.S. CISA added CVE-2025-31324 to its Known Exploited Vulnerabilities Catalog, mandating federal agencies to remediate itnvd.nist.gov. This was essentially an acknowledgment that “yes, this is being actively used by threat actors, fix it now.” (In fact, CVE-2025-31324 was dubbed the “SAP NetWeaver Unrestricted File Upload Vulnerability” in that catalog nvd.nist.gov.)

SAP’s response also included guidance on checking if you’ve been hit. For instance, SAP Note 3596125 provides instructions to look for unfamiliar .jsp, .java, or .class files in certain directories (such as .../irj/root and .../irj/work/ folders) as indicators of compromise onapsis..com. If such files are found (e.g. weirdly named JSP files like helper.jsp or random 8-character names), it’s a red flag that the vulnerability was exploited and a webshell was planted onapsis.com.

In short, CVE-2025-31324 went from zero-day to “everybody patch now” in a matter of days, and not without casualties. If your SAP NetWeaver system had this Visual Composer endpoint exposed, there’s a non-trivial chance someone unwanted came knocking. Now let’s talk about how to kick them out and lock the door.

Remediation and Mitigations

Facing a critical bug like this, the remedy comes in two flavors: apply the official patch (the ideal fix), and/or implement mitigations to reduce risk if you can’t patch immediately. SAP thankfully provided a fix in the form of SAP Security Note 3594142, which administrators should apply without delayionix.io. This patch corrects the missing authorization check, properly securing the Metadata Uploader endpoint, and is the most direct way to eliminate the vulnerability. In SAP’s terms, this note is classified as a "HotNews" update due to its urgencysecuritybridge.com. Make sure to update Visual Composer to the fixed version (for SAP NetWeaver 7.50 Visual Composer, or relevant patch levels for older versions as listed in the note).

However, patching might require testing or downtime in some environments. In the meantime (or if you’re stuck on an older version), consider these mitigations and best practices:

Lock Down the Endpoint: Immediately restrict access to the Visual Composer development server URLs. If possible, block or filter any requests to /developmentserver/metadatauploader at your web application firewall or reverse proxy ionix.io. If that endpoint isn’t meant to be externally accessible, ensure your network controls reflect that (e.g., only allow internal IPs or VPN access to it). Essentially, don’t let the bad guys reach this servlet in the first place.
Disable or Remove Visual Composer (if not needed): Many organizations weren’t actively using Visual Composer, even if it was installed. If that’s the case, you can turn it off. SAP has provided guidance on disabling the component – for example, undeploying the Visual Composer application (VC70RUNTIME) via SAP’s management console or telnet interfacesecuritybridge.com. In fact, SAP Note 3593336 provides a workaround to disable the uploader and even suggests how to remove stray files it may have dropped securitybridge.com. By uninstalling or disabling the Visual Composer add-on, you remove the vulnerable functionality entirely (just remember to also patch in case it gets re-enabled later) securitybridge.com.
Validate and Sanitize File Uploads: This is more of a development best practice, but it’s worth mentioning as a mitigation if you have the ability to customize or filter. Ensure that any file upload feature (not just in SAP, but any enterprise app) strictly checks user authorization, file types, and content. For instance, allow only expected file formats and use virus scanning or content scanning for anything uploaded. In the case of SAP’s Metadata Uploader, one would expect it to only accept certain metadata files – so in theory it should reject .jsp, .exe, or other obviously dangerous files. Implementing such validation (if you maintain a custom servlet filter or using an SAP Web Dispatcher rule) could prevent an attacker from uploading webshells ionix.io. In general, never trust user input, especially file uploads.
Segment and Monitor: Consider isolating your SAP servers from direct internet access. If the Visual Composer endpoint had not been exposed to the internet, the risk would have been much lower (the attacker would need another foothold to reach it). Place critical systems behind VPNs or zero-trust access gateways. Additionally, deploy monitoring on your SAP hosts: enable logging for HTTP requests and use security monitoring tools (EDR/XDR) to alert on suspicious processes spawned by the Java server ionix.io. The Ionix team, for example, recommends isolating SAP servers from general IT networks and watching for anomalies in the Java process that could indicate a webshell running ionix.io.
Check for Signs of Compromise: If you haven’t already, hunt for any evidence that someone exploited this before you patched. As noted, look in the filesystem for any odd files in the Visual Composer or Portal directories (e.g. .jsp files that you didn’t put there) comonapsis.com. Search your SAP HTTP access logs for requests to /metadatauploader (especially POST requests that succeeded with HTTP 200) and subsequent requests to unfamiliar JSPsionix.io. If found, assume breach: remove any malicious files, reset credentials if necessary, and conduct a thorough incident response. The earlier you find and eradicate a webshell or beacon, the less damage an attacker can do.
Apply Defense in Depth: Even after patching, use this incident as a learning opportunity. Employ a layered defense for your enterprise applications. For instance, enable a Web Application Firewall (WAF) with rules to detect and block common webshell patterns or large, unusual file uploads. Ensure your SAP servers run with the least privileges necessary (though SAP <sid>adm accounts are highly privileged by design, you might harden what they can do or monitor their activity). Regularly update and review your access control lists – an endpoint like Visual Composer’s uploader probably never needed to be open to all users. Had an authorization check been in place (even one that only allowed admins or localhost access), this whole saga would have been avoided.

Preventing Similar Vulnerabilities in the Future

CVE-2025-31324 is a stark reminder that even enterprise-grade software from industry giants can have “oops” moments. However, there are general strategies and best practices that can prevent or at least mitigate such flaws in the software we develop and deploy:

Secure Coding Practices: Developers must build security in from the start. In this case, a simple authorization check (if (!user.isAuthorized()) { reject; }) could have stopped the madness. Ensuring that every sensitive action (like writing files to the server) is gated behind proper authentication/authorization is fundamental. Code reviews and static analysis can catch missing auth checks or input validation oversights. Use frameworks or libraries that enforce these checks consistently rather than ad-hoc, to avoid human error.
Principle of Least Privilege (PoLP): Not just for user accounts, but for components. The Visual Composer Metadata Uploader likely didn’t need to allow arbitrary file types or locations. By limiting what an uploader can do (e.g., only save XML metadata into a specific folder, and nothing else), you reduce the impact of abuse. Similarly, the account running the SAP services should have only the privileges absolutely required – if it didn’t have permission to write to certain directories or execute new code, the damage from file upload would be limited. In practice, SAP services run with broad system access, but perhaps future designs can compartmentalize such functionality.
Attack Surface Reduction: Audit your systems for functionalities that are not in use, and disable them. An unused component is just unnecessary risk. Many SAP customers might not even know Visual Composer was enabled. Regularly inventorying features and services (and uninstalling or turning off those not needed) can prevent an attacker from exploiting a component you weren’t even aware of. This applies to default configs – if a product ships with a sample or dev service enabled (which was likely the case here), consider turning it off in production environments.
Keep Software Updated: This sounds obvious, but it’s worth stressing. SAP had actually encountered a similar issue in the past – an earlier Unrestricted File Upload vulnerability in Visual Composer was patched back in 2021 (CVE-2021-38163, affecting older 7.0x versions) securitybridge.com. Organizations that patched that issue and upgraded might have avoided this 2025 variant (or at least been more alert to it). Apply security patches as soon as feasible, especially for critical vulns. If a system is end-of-life and no longer gets patches, that’s a risk – plan to upgrade or isolate it.
Network Layer Security: Assume that someday, somehow, an attacker will find a flaw in an internal component. Design your network such that even if one server is compromised, it’s not game over for the entire enterprise. Use network segmentation to separate critical servers. Limit direct internet exposure of sensitive apps – use VPNs or gated access. Place monitoring on network traffic to detect anomalies (like an SAP server suddenly initiating connections to an external C2 server, which was reported in these attacksionix.io).
Detection and Response Preparedness: Finally, have a plan for when things go wrong. Implement centralized logging and SIEM alerts for strange behavior (e.g., a normally quiet SAP server uploading data to unknown external hosts, or sudden bursts of errors in a component log file). Conduct periodic drills or simulations (many security companies, like the one whose blog we cited, offer tools to simulate attacks like this in a safe way picussecurity.com) to test if your controls can catch or stop them. The quicker you detect a breach, the quicker you can kick out the intruder and limit the damage.

Final Thoughts

CVE-2025-31324 in SAP NetWeaver’s Visual Composer was a particularly nasty flaw – the kind that gives IT administrators sleepless nights. It combined a simple oversight (missing auth check) with a far-reaching impact (remote code execution on a critical system). The story comes with a silver lining, though: it pushed many organizations to audit and harden their SAP systems, and it highlights practices that will make everyone safer going forward.

In the realm of enterprise security, vigilance is key. Today it’s an unprotected file upload in a Visual Composer; tomorrow it could be a trust misconfiguration in an integration or a deserialization bug in a legacy service. By staying on top of patches, minimizing exposure, and rigorously applying security best practices, we can keep the would-be intruders at bay. In short, don’t let your guard down – or your upload forms run wild – and you won’t have to face the music when the next vulnerability tries to take center stage. Stay safe out there, and happy patching!

Sources: This analysis was informed by vulnerability reports and threat research from the SAP community and security experts. Key references include the National Vulnerability Database entry for CVE-2025-31324 nvd.nist.gov, the SAP HotNews security notes securitybridge.com, community blogs detailing the exploit mechanics ionix.io, and incident reports of real attacks in the wildbleepingcomputer.com, among others.