Is CVE-2025-31324 (SAP NetWeaver Unrestricted File Upload) being exploited in the wild?

Yes. CISA added CVE-2025-31324 to its Known Exploited Vulnerabilities catalogue on 29 April 2025, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. SAP NetWeaver Visual Composer Metadata Uploader contains an unrestricted file upload vulnerability that allows an unauthenticated agent to upload potentially malicious executable binaries.

What “being exploited in the wild” means for this CVE

CISA listing CVE-2025-31324 in KEV means this is not just a theoretical weakness. For a SAP NetWeaver Visual Composer Metadata Uploader unrestricted file upload flaw, the practical question is whether the vulnerable NetWeaver instance is internet reachable, whether the affected component is deployed, and whether an attacker could use the upload path to place executable content before defenders notice.

For practitioners, the key distinction is between a vulnerable installation and one that is already in an attacker’s hands. Active exploitation raises the urgency from routine remediation to incident-ready response, because file upload flaws often become the first step in web shell placement, privilege expansion, or persistence.

Because CISA ties this entry to ransomware use, the issue should be treated as an exposure that can move quickly from initial access to business disruption. That makes exposure confirmation and compromise checks part of the answer, not optional follow-up.

For a broader response pattern to actively exploited weaknesses, Zero-Day and Exploited Vulnerabilities Guide is the most direct NHIMG starting point, and CISA’s own Known Exploited Vulnerabilities Catalog is the authoritative source for exploitation status and response priority.

Why unrestricted file upload becomes a real intrusion path

An unrestricted upload issue matters because the upload feature is not just accepting data, it may be accepting code, scripts, or files that the application later processes as trusted content. If the attacker can influence file type, naming, storage location, or execution context, the upload endpoint can become an ingress point for malicious binaries or server-side code.

That risk is higher when the application runs with broad filesystem permissions, stores uploads where web content is served directly, or lacks content validation and isolation. In those cases, the exploit path is straightforward: deliver a payload, place it somewhere reachable, and use the application or server to execute it.

That is why file upload hardening is not a cosmetic control. File Upload Security Guide covers the exact failure mode here, and the relevant response is to validate the upload path, storage model, and execution boundaries rather than assuming the vulnerability is only a data-quality problem.

On the external side, the official CVE Program record format and the NIST National Vulnerability Database entry are the places to confirm the canonical record details, while KEV tells you why the weakness has operational urgency.

What to verify before and after mitigation

First confirm whether SAP NetWeaver Visual Composer Metadata Uploader is present and reachable in your environment, including exposed test, staging, and forgotten internet-facing instances. Then determine whether the system has already received suspicious uploads, web shells, unexpected executables, or unusual child processes associated with the application server.

If patching or vendor remediation is delayed, reduce exposure immediately by disabling or restricting the vulnerable upload path, filtering access at the network edge, and isolating the affected host so that even a successful upload has less room to execute or persist. Where the application is business critical, containment is often the fastest way to buy time.

After remediation, review logs for prior compromise and rotate any credentials, tokens, or service accounts that were exposed through the application server or adjacent management interfaces. Vulnerability Management Guide is useful here because actively exploited weaknesses should be tracked as exposure plus verification work, not just patch completion.

Risk and Threat Considerations

An unrestricted file upload flaw is attractive to attackers because it can convert a normal application endpoint into an execution bridge. Once the attacker can plant content on the server, the next steps may include web shell deployment, lateral movement, credential harvesting, or ransomware staging.

Failure mechanism: The application accepts attacker-controlled files without sufficient type validation, storage isolation, or execution protection, allowing malicious content to be written into a location that the server later trusts or executes.

Impact: A single successful upload can lead to remote code execution, persistence, data theft, and rapid business disruption, especially where SAP systems are integrated with sensitive enterprise processes.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Unrestricted upload exploitation is often enabled by insecure deployment and storage configuration.
Recommendation — Harden upload storage, execution paths, and exposed services to remove the exploitable condition.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	The flaw is an input-validation failure that allows unsafe file content into the application flow.
	SI-3 — Malicious Code Protection	Upload-based exploitation can introduce executable malware or web shells into the host environment.
Recommendation — Validate upload type, content, and handling before any file is stored or processed. Inspect and block malicious uploaded content before it can execute or persist.
OWASP ASVS	V5 — File Handling	ASVS file-handling requirements directly address unsafe upload acceptance and processing.
	V16 — Security Logging and Error Handling	Post-exploitation checks depend on logs that reveal suspicious uploads and execution attempts.
Recommendation — Apply file-handling controls that restrict type, storage, and execution of uploaded content. Retain and review upload and server logs to detect abuse and validate response.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	If the upload led to server compromise, adjacent secrets and credentials may have been exposed.
Recommendation — Rotate any secrets that the exploited server could access or disclose.
MITRE ATT&CK	T1105 — Ingress Tool Transfer	Attackers commonly use upload pathways to move payloads onto a target system.
	T1505.003 — Server Software Component: Web Shell	Unrestricted uploads frequently support web shell placement after initial access.
Recommendation — Hunt for inbound payload staging and unexpected file transfer activity on the host. Search for web shells and related persistence artifacts in application-facing directories.

Practitioner Guidance

What to prioritise: Treat this as both a patching problem and a compromise-check problem. If the instance is externally reachable or historically exposed, assume the upload path may already have been probed and prioritise containment before routine maintenance work.

What to verify: Confirm whether uploaded content can be executed, whether upload directories are web accessible, and whether logs show unusual file names, temporary files, or post-upload process execution. If those signals exist, investigate for deeper compromise instead of stopping at vulnerability closure.

Decision rule: If the system handled sensitive business data or had privileged integration access, perform credential and session review after fixing the flaw, because the main loss from exploitation is often not the upload itself but what the attacker could reach next.

Practitioner takeaway: For an actively exploited upload flaw, remediation is not complete until you have both removed the exposure and ruled out attacker footholds created through the upload path.