SAP NetWeaver (CVE-2025-31324): a login-free web shell

SAP systems are the digital heart of the largest organisations: finance, manufacturing, the supply chain, HR data — all in one place. That’s exactly why the CVE-2025-31324 flaw in the SAP NetWeaver Visual Composer component, disclosed in spring 2025, was so dangerous. With a CVSS score of 10.0 (the maximum), it allowed uploading any file to the server with no authentication whatsoever — in practice a web shell giving full control over the system holding the company’s most valuable processes. And, as tends to happen with critical flaws in internet-exposed systems, it entered active exploitation before many companies managed to patch it.

What the flaw was

The problem was a missing access control on one of Visual Composer’s upload endpoints (/developmentserver/metadatauploader). An attacker could send a request and upload an executable file (e.g. a JSP web shell) into a directory served by the application server — no login, no token, nothing. Once uploaded, simply opening the planted file in a browser executed commands on the server with the SAP service’s privileges.

The simplicity of the chain (upload → execution) made it ideal for mass, automated exploitation. Both espionage groups and ransomware operators joined in — the repeatable pattern: a critical 0-day in a high-value system first serves quiet penetration, then extortion.

Why SAP is a special target

SAP security lived in the shadows for years, because these systems tend to be treated as “internal, so safe”. In practice many SAP instances are — deliberately or by neglect — partially reachable from the internet (portals, integrations, web components). And the stakes are the highest: taking over SAP means access to financial ledgers, employees’ personal data, production processes and payments. It’s not “just another server” — it’s a system whose compromise hits confidentiality, integrity and continuity at once.

Add the maintenance reality: SAP systems are critical and complex, so maintenance windows are rare and patching is cautious and slow. The very trait that makes them stable delays the response to critical flaws. Attackers know this.

Defence: what to do with critical SAP

Patch and check for bypasses. SAP issued an emergency fix outside the normal cycle, and soon another closing a related vector (CVE-2025-42999). Installing both is essential — the same “a patch can be bypassed” lesson as ToolShell.

Assume compromise if you were exposed. With a flaw under mass exploitation, check the server directories for planted files (web shells), review the upload endpoint’s logs and unusual application-server child processes. It’s classic threat hunting — a patch doesn’t remove a web shell that’s already there.

Take SAP off the internet. SAP web components (especially Visual Composer, if unused) should not be publicly reachable. Access only via VPN with MFA, segmentation, exposure limited to the necessary minimum.

Bring SAP into your security process. SAP too often stands outside standard vulnerability management and testing. It should be inventoried, scanned and monitored like any other critical system — and given its value, rather more than less.

Frequently asked questions (FAQ)

Our SAP is “internal”, not reachable from the internet. Were we safe? Worth verifying rather than assuming. Many instances have partially exposed web components or integrations the team has forgotten about. Even if SAP really is internal only — an attacker who entered the network another way will use this flaw to take over the most valuable system (lateral movement).

We don’t use Visual Composer. Did the flaw affect us? The vulnerable component is sometimes installed and enabled by default, even if you don’t actively use it. So “we don’t use it” isn’t enough — you have to check whether the component is present and reachable, and apply the patches or disable unused modules.

How do we check whether someone uploaded a web shell? Search the application-server directories for unexpected files (JSP and similar) with dates from the exposure window, review access logs for the upload endpoint, and check processes launched by the SAP service. Treat any traces found as an active incident.

Why is patching SAP so hard? Because these are critical, complex and usually heavily customised systems — every change needs testing and a maintenance window. It’s a real challenge, but with a CVSS 10.0 flaw under mass exploitation the priority must outweigh convenience; the alternative is losing the company’s heart.

How do we approach SAP security comprehensively? By treating it as a critical system in the full process: inventory and exposure minimisation, regular patching, monitoring, access control and periodic security testing. We’re glad to help assess your SAP exposure and bring it into the process — get in touch.

Summary

CVE-2025-31324 was a reminder that the most dangerous flaws are those in the highest-value systems — and SAP, despite its “internal” reputation, is often exposed and rarely patched in time. The defence is a fast fix (plus closing the related vector), active web-shell hunting, taking components off the internet and folding SAP into your normal security process. If SAP holds your company’s heart, make sure it isn’t standing outside your protection programme.

Sources and further reading: SAP Security Notes, CISA KEV.