CVE-2025-31324 is an unrestricted file upload vulnerability in SAP NetWeaver. CISA added it to the Known Exploited Vulnerabilities catalogue on 29 April 2025, which means attackers have used it in real attacks. SAP NetWeaver Visual Composer Metadata Uploader contains an unrestricted file upload vulnerability that allows an unauthenticated agent to upload potentially malicious executable binaries.
What this vulnerability means in practice
An unrestricted file upload in SAP NetWeaver means the application accepts attacker-controlled files without sufficient type, content, or execution checks. In a platform that can process uploaded content server-side, that turns a simple upload flaw into a foothold for code execution, web shell placement, or follow-on compromise.
Because the primary issue is unauthenticated upload, defenders should treat it as an exposure problem, not just a validation bug. The practical question is whether any Internet-facing or internally reachable NetWeaver instance exposes the vulnerable upload path and whether the platform is still reachable through trusted application routes that attackers can abuse.
Why unrestricted file upload is dangerous
File upload flaws are dangerous when uploaded content can be stored in a web-accessible location, interpreted by the server, or later executed through another component. That is why upload weaknesses often become initial access events rather than isolated application defects.
In enterprise systems, the impact can extend beyond one host. If an attacker can upload executable content into a business platform, they may pivot into application data, credentials, configuration files, or downstream integrations that trust the compromised system.
The CVE Program and the NIST National Vulnerability Database are the authoritative places to confirm the record details, while vendor advisories should be used for exact product guidance and remediation timing.
How organisations check exposure and reduce blast radius
Exposure checks should start with an asset inventory that identifies every SAP NetWeaver deployment, including test, development, externally hosted, and forgotten instances. From there, teams should verify whether the vulnerable upload surface is reachable from the network and whether any compensating reverse proxy, WAF, or application-layer restriction is actually blocking the attack path.
When patching cannot happen immediately, organisations should focus on compensating controls that reduce exploitability, such as restricting exposure, tightening upload handling, isolating the service, and monitoring the vulnerable path for suspicious file types or unexpected executable content.
For prioritisation, this belongs in the same operational discipline as other actively exploited weaknesses, which is why a structured programme like Vulnerability Management Guide is useful for sorting inventory, prioritisation, exceptions, and verification around KEV-listed issues.
Detection, response, and post-patch review
Detection should look for evidence that an upload led to execution or persistence, not just the upload event itself. Useful signals include unexpected new files in web-accessible paths, anomalous server-side processes, changes to application directories, suspicious HTTP requests to upload endpoints, and new outbound connections from a system that normally should not initiate them.
After patching, teams should assume the possibility of pre-patch compromise and review the host and adjacent application stack for web shells, modified configuration, altered scheduled tasks, and newly created admin or service-level artefacts. If exploitation is confirmed or strongly suspected, rotate credentials and tokens that may have been exposed through the application or server context.
Attackers often chain file upload flaws into broader compromise, so response should include log review, integrity checks, and validation that no secondary payload remained behind after the vulnerability was remediated.
Risk and Threat Considerations
Because this flaw was added to the KEV catalogue, the material risk is not theoretical, and unauthenticated exploitability makes exposed instances especially high priority. The main threat is that an attacker can move from a single upload request to code execution, persistence, or web shell deployment on an enterprise application server.
Failure mechanism: The application accepts attacker-supplied content without adequate server-side controls, allowing malicious binaries or scripts to land in a location that the platform can later execute or process.
Impact: A successful exploit can lead to full application compromise, data access, lateral movement into connected systems, and incident response work that extends well beyond the original upload endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Upload flaws are prevented by validating and constraining untrusted input. |
| SI-3 — Malicious Code Protection | Uploaded binaries can deliver malicious code into the application stack. | |
| Recommendation — Validate file uploads and reject content that does not meet strict type and handling rules. Scan and block malicious uploaded content before it reaches executable paths. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This is a web application vulnerability that needs secure handling and testing of upload paths. |
| Recommendation — Test upload endpoints and fix insecure file-handling behavior in the application. | ||
| OWASP ASVS | V5 — File Handling | ASVS file-handling requirements directly address unsafe upload processing and storage. |
| Recommendation — Enforce strict file-handling controls for type, storage, and execution restrictions. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Uploaded malicious content becomes a stored payload that should not be executable or uncontrolled. |
| Recommendation — Protect stored uploaded files so they cannot be used as executable payloads. | ||
Practitioner Guidance
Why practitioners should care: Treat this as an actively exploited exposure that can invalidate assumptions about trust in the application boundary. If SAP NetWeaver is Internet-facing or reachable by broad internal networks, the upload path deserves immediate validation, not routine backlog handling.
What to watch for: Watch for signs that uploaded content is being used as a delivery mechanism for code, not documents or static assets. That includes abnormal file naming patterns, executable extensions, unexpected server changes, and post-upload activity that does not match normal business use.
Practitioner takeaway: For KEV-listed upload flaws, patching is necessary but not sufficient, because response quality depends on whether you can prove the system was not already used as an execution foothold.
Related resources from NHI Mgmt Group
- CVE-2025-52691 (SmarterTools SmarterMail Unrestricted Upload of File with Dangerous Type)
- Why does an unauthenticated file upload flaw in SAP NetWeaver create such high compromise risk?
- What are the signs that CVE-2025-31324 may already be exploited in an SAP environment?
- CVE-2021-20022 (SonicWall Email Security Unrestricted Upload of File)