Is CVE-2025-42999 (SAP NetWeaver Deserialization) being exploited in the wild?

Yes. CISA added CVE-2025-42999 to its Known Exploited Vulnerabilities catalogue on 15 May 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 a deserialization vulnerability that allows a privileged attacker to compromise the confidentiality, integrity, and availability of the host system by deserializing untrusted or malicious content.

What “exploited in the wild” means for this SAP NetWeaver CVE

For this question, the key signal is CISA’s KEV listing. If a vulnerability is in the Known Exploited Vulnerabilities catalogue, practitioners should treat it as actively exploited, not merely theoretically dangerous. The immediate job is to confirm whether any SAP NetWeaver Visual Composer Metadata Uploader instances exist in your estate and whether they are exposed to untrusted input paths.

For a deserialization flaw, the practical exposure question is not just “is the product installed?” but “can an attacker reach the vulnerable component and supply crafted data?” The relevant surface is the component that accepts serialized content, so inventory and exposure validation matter more than generic vulnerability counts. The right operating assumption is that exploited-in-the-wild status raises the priority above ordinary patch queues.

Because this is a deserialization issue, the attack path is often about turning parser trust into execution or data access. Insecure deserialisation guidance is useful here because the failure mode is the same class of unsafe object handling, even when the affected application is SAP-specific. For exploit-driven triage, Zero-Day and Exploited Vulnerabilities Guide helps frame the difference between routine vulnerability backlog work and a KEV-driven emergency response.

What to do while confirming exposure and exposure paths

Start with scope confirmation: identify every SAP NetWeaver deployment, every Internet-facing or partner-facing entry point, and every path that can reach Visual Composer functionality. If you cannot immediately prove the component is absent, assume it may be present and constrain access until validation is complete. That is especially important when the platform is shared across business units or has been inherited from older deployment models.

Then validate whether you have compensating controls that actually reduce reachability, not just paper controls. Network filtering, reverse proxy rules, application-layer restrictions and hard segmentation only help if they prevent the vulnerable component from receiving attacker-controlled content. A KEV-listed deserialization issue should also trigger a search for unusual server-side errors, new administrator activity, unexpected file changes and any signs the host was already used as a foothold.

The best source of truth for patch and mitigation detail remains the vendor advisory and the CISA KEV catalogue. The KEV entry tells you why this belongs in emergency prioritisation; SAP’s guidance tells you what version or mitigation path applies to your exact deployment.

Internal references that help with the same response pattern are Vulnerability Management Guide for triage discipline and Gladinet Hard-Coded Keys RCE Exploitation for the broader lesson that active exploitation changes remediation from routine maintenance to incident-grade response.

Why post-patch verification and compromise checks matter here

Deserialization vulnerabilities are high-risk because they can cross the boundary from “remote input accepted” to “server state changed.” Even if the fix is applied quickly, that does not prove the system was not already abused. Once exploitation is public and catalogued, a delayed patch window becomes an opportunity for both opportunistic and targeted follow-on activity.

The verification step should therefore look for prior compromise, not just current patch state. Check logs for suspicious requests, anomalous errors around the vulnerable component, unexpected child processes, web shell indicators, new local accounts, strange outbound connections and any sign that the application host acted as an internal pivot point. If the application handled privileged data or had broad system access, widen the hunt to adjacent systems that might have been reached after initial compromise.

When the vulnerable service had access to secrets, sessions or privileged back-end connectivity, rotate the material that could have been exposed or replayed. That is not automatic for every deserialization flaw, but it becomes material when the application could have been used to retrieve credentials, impersonate users, or access downstream systems.

For a broader operational model of active exploitation response, CISA Known Exploited Vulnerabilities Catalog is the most direct external reference, while NIST National Vulnerability Database helps you anchor the record to the canonical CVE entry and technical metadata.

Risk and Threat Considerations

Active exploitation changes the risk profile from theoretical application weakness to probable attacker interest. A deserialization flaw is especially dangerous when the vulnerable service runs with elevated privileges, because a crafted payload can turn one request into server-side compromise, data exposure or a durable foothold.

Failure mechanism: The attacker supplies malicious serialized content, the application trusts and deserializes it, and the resulting object manipulation can produce unauthorized code execution, state corruption or access to sensitive host resources.

Impact: Compromise can extend beyond the application itself to confidentiality, integrity and availability of the host, and from there to lateral movement, credential abuse, persistence or ransomware staging if the server is reachable from broader systems.

Standards & Framework Alignment

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

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-7 — Continuous Vulnerability Management	Active exploitation makes rapid identification and remediation the central control problem.
Recommendation — Prioritise KEV-listed systems for immediate remediation and exposure reduction.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This question is about confirming exposure and tracking an actively exploited vulnerability.
	SI-2 — Flaw Remediation	The CVE requires timely fix or mitigation once exploitation is known.
	IR-4 — Incident Handling	KEV status and possible prior abuse require compromise assessment and response.
Recommendation — Continuously identify affected SAP assets and verify remediation status. Apply the vendor fix or compensating mitigation without delay. Treat the system as a potential incident and investigate for prior compromise.
OWASP ASVS	V15 — Secure Coding and Architecture	Deserialization weaknesses arise from unsafe object handling and trust boundaries.
Recommendation — Eliminate unsafe deserialization paths and enforce trusted-data handling.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as a remediation emergency. Verify whether any SAP NetWeaver instance is exposed, then reduce access to the vulnerable component first and patch or mitigate immediately after that.

What to verify: Confirm the exact deployment path, whether Visual Composer Metadata Uploader is enabled, and whether logs show suspicious requests or anomalous server behaviour before the fix went in. If the host had privileged access, assume compromise assessment is part of the response.

Decision rule: If you cannot patch at once, limit reachability, isolate the system where practical, and move straight to compromise hunting. If business criticality prevents isolation, treat the system as high risk until the vendor’s remediation is complete and post-fix validation is finished.

Practitioner takeaway: For a KEV-listed deserialization flaw, the right question is not “is it patched yet?” but “was it reachable, was it abused, and what downstream trust did the server already have?”