Is CVE-2025-5086 (Dassault Systèmes DELMIA Apriso Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2025-5086 to its Known Exploited Vulnerabilities catalogue on 11 September 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Dassault Systèmes DELMIA Apriso contains a deserialization of untrusted data vulnerability that could lead to a remote code execution. Any organisation running the affected product should treat remediation as urgent.

Why active exploitation changes the answer from “vulnerable” to “urgent”

The key distinction is that this is not a theoretical flaw review. Once CISA places a CVE in the Known Exploited Vulnerabilities catalogue, defenders should assume exploitation is already happening and that exposure can become a live incident faster than a normal patch cycle allows. For a deserialization flaw, the practical concern is remote code execution, not just service instability.

That is why the right first question is not “does the CVE exist?” but “is this product reachable anywhere in our environment, including forgotten test, staging, or partner-facing instances?” A vulnerability with active exploitation deserves immediate asset confirmation, not routine backlog treatment. NIST’s National Vulnerability Database and CISA’s Known Exploited Vulnerabilities Catalog are the right reference points for triage, but the operational decision is driven by your own exposure.

For practitioners who need a response model for exploited flaws, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is the best fit because it focuses on KEV-style prioritisation, emergency mitigation, and post-patch hunting.

What deserialization of untrusted data means in practice

Deserialization becomes dangerous when application code accepts attacker-controlled input and reconstructs objects without strict validation. The immediate risk is that the data stream can influence program flow, object state, or method invocation in a way the developer did not intend. In mature exploit chains, that can move from parser abuse to command execution, authentication bypass, or privilege abuse.

This is why the defect class is serious even before you know the exact exploit path. If the affected system processes untrusted network input, uploaded files, message queues, or integration payloads, the vulnerable surface may be broader than the obvious product interface. In other words, “we do not expose that module directly” is not a reliable safety argument if the application still ingests attacker-influenced data somewhere in its workflow.

NHIMG’s Insecure Deserialisation Guide is useful here because it explains the mechanism behind object injection and why allowlists and safer formats matter more than superficial input checks.

How to respond when patching is not immediately possible

When a fix cannot be applied at once, the immediate goal is to narrow the attack path and reduce blast radius, not to pretend the issue is contained. That usually means isolating the affected service, restricting inbound reachability, disabling or limiting the vulnerable feature if the vendor supports it, and monitoring for suspicious requests or unexpected process execution on the host.

If the application can deserialize attacker-influenced content, assume compromise is plausible until you have evidence otherwise. Review logs for unusual object payloads, abnormal child processes, outbound connections, or new accounts and services created after the exposure window. If the product handles privileged workflows or stores operational secrets, also assess whether credentials, sessions, or service tokens may need rotation after remediation.

For broader response discipline, NHIMG’s Vulnerability Management Guide helps structure exception handling, verification, and remediation tracking when a live exploit risk outruns the normal patch queue.

Risk and Threat Considerations

Active exploitation means the flaw is already in an attacker’s toolbox, so the risk is no longer limited to hypothetical code execution. The main exposure is that a reachable Apriso instance may become an entry point for arbitrary actions on the server, followed by persistence or lateral movement if the host has access to internal systems.

Failure mechanism: Untrusted serialized input is processed by application logic before it is fully validated, allowing crafted data to trigger unsafe object behavior and, in an exploitation chain, remote code execution.

Impact: A successful attack can expose application data, alter business processes, create persistence on the host, and provide a foothold for further compromise inside the environment.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Active exploitation requires urgent risk-based prioritization of exposed assets.
Recommendation — Prioritise exposed Apriso instances for immediate remediation using a risk-based process.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue is an exploited software flaw needing timely remediation and verification.
	RA-5 — Vulnerability Monitoring and Scanning	Confirm exposure and track affected instances before and during remediation.
Recommendation — Apply flaw remediation promptly and verify the vulnerable system is fixed or contained. Scan for deployed Apriso instances and validate whether exposure persists.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation calls for continuous prioritization and remediation of the flaw.
Recommendation — Prioritise and remediate the vulnerable product through continuous vulnerability management.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	A deserialization RCE in a reachable application fits public-facing exploitation behavior.
Recommendation — Map exposed Apriso instances to public-facing exploitation and hunt for initial access activity.

Practitioner Guidance

What to prioritise: Confirm whether any production or internet-reachable DELMIA Apriso instance exists, then treat every exposed instance as an urgent remediation candidate. If you cannot patch immediately, containment and monitoring should start the same day, not after the next maintenance window.

What to verify: Do not stop at “the vendor has a fix” or “the server is behind VPN.” Verify whether the vulnerable component is actually deployed, whether it is reachable from any untrusted zone, and whether the system has already shown signs of suspicious execution or unusual outbound traffic.

Practitioner takeaway: Once a CVE is in KEV, the question shifts from vulnerability management to incident-minded exposure management, so response should be driven by reachability, containment, and compromise checks, not by patch planning alone.