Yes. CISA added CVE-2025-6205 to its Known Exploited Vulnerabilities catalogue on 28 October 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 missing authorization vulnerability that could allow an attacker to gain privileged access to the application.
What “being exploited in the wild” means for a KEV-listed CVE
For a CVE, “exploited in the wild” means there is credible evidence that real attackers are using the flaw outside a lab or proof-of-concept setting. CISA’s KEV listing is the practical signal to treat the issue as an active threat, not just a theoretical weakness. For CISA Known Exploited Vulnerabilities Catalog, use the catalog entry to confirm the current remediation expectations.
That matters because a missing authorization flaw is not just a code defect, it is an access-control failure. If the vulnerable application is exposed and reachable, an attacker may be able to move from ordinary application access to privileged actions without the checks the product should enforce. That is why KEV status should immediately move the issue into your highest-priority response queue. See also the CVE Program record model for how vulnerabilities are tracked and referenced.
The operational question is not whether the product has a flaw in the abstract, but whether your instance is exposed to the attack path CISA is warning about. If the answer is uncertain, assume exposure until you have confirmed the affected service, the reachable interface, and any compensating controls around it. The vendor advisory remains the authoritative source for product-specific remediation details.
How to respond when patching or mitigation is not immediate
When a KEV-listed issue cannot be fixed right away, the priority is to reduce reachability and abuse potential, not to wait for a perfect maintenance window. That usually means restricting network access to the application, tightening authentication and authorization boundaries around the affected interface, and disabling any unnecessary exposure paths until the fix is in place.
Use the KEV entry as the trigger for a short, explicit exception decision. If you must defer remediation, document why, how long the exception lasts, what compensating controls are active, and who owns the follow-up. A KEV listing is a poor candidate for open-ended risk acceptance because it already indicates known exploitation.
For this class of flaw, review whether the application’s privilege model could allow a compromised session or interface call to become a broader administrative foothold. That review should include service accounts, integration accounts, and any privileged workflows the application can invoke on behalf of users or systems. If those paths exist, limit them before you rely on detection alone.
What to check after exposure is confirmed
If the application was reachable while vulnerable, assume there may have been attempts to use it before you patched it. Check authentication logs, administrative actions, API activity, and unusual changes to configuration, users, roles, or business records. The goal is to look for signs that an authorization boundary was crossed, not only for obvious malware.
Where the product controls sensitive workflows, confirm whether any privileged actions were performed through the application during the exposure window. If the flaw could have exposed privileged access, review whether passwords, API keys, session material, or service credentials were reachable through adjacent systems or logs. Rotate only the material that could plausibly have been exposed, but do not underreact if privileged access was possible.
Use the exposure window to bound your search. Start from the date the issue became reachable in your environment, then work forward through patching or containment. If you find evidence of abuse, treat it as an incident response problem, not just a vulnerability remediation task.
Risk and Threat Considerations
KEV-listed authorization flaws are attractive because they can turn a normal application request into privileged access without needing to defeat the entire authentication stack. That raises the likelihood of administrative misuse, data access, and workflow manipulation wherever the product exposes sensitive functions.
Failure mechanism: An attacker abuses a missing authorization check to call privileged functions, alter protected data, or reach administrative capabilities that should have been blocked by the application.
Impact: The result can be unauthorized configuration changes, sensitive data exposure, integrity loss, or a broader compromise chain if the application has access to downstream systems or privileged integrations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | ID.RA-01 — Risk Identified | KEV-listed exploitation requires rapid risk identification and triage. |
| Recommendation — Identify the exposed asset and escalate it as an active risk for containment. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Active exploitation requires identifying exposure and validating whether the flaw is present. |
| SI-2 — Flaw Remediation | The subject is an actively exploited software flaw that needs prompt remediation. | |
| AC-6 — Least Privilege | A missing authorization flaw is fundamentally about excessive access being possible. | |
| Recommendation — Scan affected systems and validate exposure before accepting the risk. Apply the vendor fix or mitigation as soon as exposure is confirmed. Restrict privileged application paths to the minimum access required. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV status drives urgent vulnerability prioritization and remediation tracking. |
| Recommendation — Prioritise and remediate KEV-listed exposure ahead of routine findings. | ||
Practitioner Guidance
What to prioritise: Treat confirmed exposure as a triage and containment event first, and a patching event second. For a KEV-listed authorization flaw, the first decision is whether the application can still be reached in a way that preserves the exploit path.
What to verify: Confirm the exact deployment, reachable interfaces, and any privileged workflows the application can invoke. If the product sits behind other controls, verify that those controls actually block the specific request path, not just the login page.
Decision rule: If the instance was reachable before remediation, assume compromise assessment is warranted; if privileged actions are exposed through the application, rotate or reissue the relevant credentials or sessions before you rely on normal operations.
Practitioner takeaway: KEV status should change your posture immediately, because for active exploitation the key question is no longer “is this vulnerable?” but “has this access path already been abused, and what privileged reach did it expose?”
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- 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)
- Is CVE-2025-6204 (Dassault Systèmes DELMIA Apriso Code Injection) being exploited in the wild?
- Is CVE-2025-5086 (Dassault Systèmes DELMIA Apriso Deserialization of Untrusted Data) being exploited in the wild?