Is CVE-2025-6204 (Dassault Systèmes DELMIA Apriso Code Injection) being exploited in the wild?

What this CVE means for active exploitation

CVE-2025-6204 is not just a theoretical flaw. CISA's KEV listing is the practical signal that defenders should treat it as being used in the wild, not merely disclosed. For an internet-facing or internally reachable DELMIA Apriso deployment, the question is whether the vulnerable code path is reachable, whether the product is still present, and whether the environment has compensating controls that meaningfully reduce execution risk.

Because the issue is a code injection weakness, the security concern is direct execution on the target system, not just a crash or minor data exposure. That makes it a candidate for rapid containment review, especially where the application has access to downstream databases, file shares, automation tasks, or adjacent production systems.

A useful first step is to treat exposure as a software inventory problem before it becomes an incident problem. If the product is installed, identify the exact application instances, the network paths to them, and whether any external or partner-facing interfaces can reach the vulnerable component. The presence of the product alone is not enough, but the presence of an exposed service plus active exploitation changes the response tempo.

How to respond while patching is being arranged

The safest response is to move quickly on the vendor fix or approved mitigation path and reduce reachable attack surface until the issue is closed. When a patch cannot be applied immediately, constrain access at the network layer, remove unnecessary exposure, and place the affected application behind tighter segmentation or administrative reachability controls. CISA's KEV entry and the vendor advisory should be the source of the exact version and remediation details.

If temporary compensating controls are all that is available, treat them as short-lived. A code injection flaw can be abused repeatedly once the vulnerable endpoint is discovered, so delaying remediation because "nothing bad has been observed yet" is a weak assumption. For this class of issue, absence of alerting is not evidence of absence of exploitation.

After remediation, do not stop at patch verification. Check for suspicious child processes, unexpected script execution, new services, web shells, abnormal outbound connections, and unauthorized changes to application directories or scheduled tasks. If the system had broad internal reach, also review whether the application account or host credentials could have been used to pivot further.

What a practical exploitation check should include

For a KEV-listed code injection issue, the question is not only "is it patched?" but "was it reached before the fix?" Review web, application, and host logs for unusual requests to the Apriso application, repeated failures followed by success, error patterns that match injection probing, and any post-exploitation activity near the KEV publication date. Correlate this with endpoint telemetry and authentication logs where available.

If the system exposes service credentials, API keys, or application secrets, rotate the material that could have been touched by an attacker after validating the scope of the event. The need for rotation depends on what the compromised process could access, not just on whether a defender saw overt malicious activity. In practice, the blast radius often matters more than the initial exploit itself.

Risk and Threat Considerations

The main risk is that a code injection flaw can turn a business application into an execution foothold. Once an attacker can run code in the application context, they may be able to steal data, alter workflows, plant persistence, or use the host as a stepping stone into adjacent systems. A KEV listing raises the likelihood that the attack path is already being operationalised by real actors.

Failure mechanism: The vulnerable input or processing path accepts attacker-controlled content that is interpreted as executable code, which can lead to arbitrary command or code execution under the application's privileges.

Impact: Successful exploitation can produce full compromise of the application host, exposure of connected data, lateral movement opportunities, and a need for incident response beyond routine patching.

Practitioner Guidance

What to verify: Confirm whether any DELMIA Apriso instance is reachable from user, partner, or external networks, and whether the exact vulnerable component is present in production, test, or DR environments. A hidden non-production instance can still become the easiest entry point.

Decision rule: If the application can execute under a privileged service context, treat credential rotation, session review, and compromise assessment as part of the remediation plan, not as a separate later task.

Practitioner takeaway: For a KEV-listed code injection flaw, the right question is not "should we patch soon?" but "what access could an attacker have gained before we finished patching, and what would that access let them reach?"

Related resources from NHI Mgmt Group

• Guide: Zero-Day and Exploited Vulnerabilities Guide
• CVE-2025-6204 (Dassault Systèmes DELMIA Apriso Code Injection)
• How do you patch or mitigate CVE-2025-6205 (Dassault Systèmes DELMIA Apriso Missing Authorization)?
• CVE-2025-6205 (Dassault Systèmes DELMIA Apriso Missing Authorization)
• CVE-2025-5086 (Dassault Systèmes DELMIA Apriso Deserialization of Untrusted Data)