Is CVE-2021-38406 (Delta Electronics DOPSoft 2 Improper Input Validation) being exploited in the wild?

Yes. CISA added CVE-2021-38406 to its Known Exploited Vulnerabilities catalogue on 25 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Delta Electronics DOPSoft 2 lacks proper validation of user-supplied data when parsing specific project files (improper input validation) resulting in an out-of-bounds write that allows for code execution.

What “exploited in the wild” means for this CVE

For a CVE like this, “exploited in the wild” means more than a theoretical weakness or a proof-of-concept exploit. It indicates that defenders have enough evidence to treat the issue as an active attack path, so exposure should be assumed wherever the product and affected parsing workflow are present. The right response is to confirm whether the vulnerable software exists in your environment and whether project files from untrusted or external sources are handled.

Because CISA has already placed it in the KEV catalogue, the operational question is no longer whether exploitation is possible. The useful question is whether any systems still accept the risky file input path, whether those systems are reachable from less trusted networks, and whether they can execute parsed content in a way that would make an out-of-bounds write meaningful to an attacker.

When a flaw combines malformed input handling with code execution potential, the exposure is often greatest on engineering workstations, file import workflows, shared project repositories, and systems that process customer-supplied or partner-supplied data. That makes asset inventory and workflow mapping just as important as patching, because the same product can be low-risk in one segment and high-risk in another.

How to confirm exposure and reduce the attack path

Start by identifying every installation of the affected product and then map where project files originate, who can submit them, and which users or systems open them. If the software is used in an OT or industrial environment, OT Security Guide is the right conceptual model for understanding why segmentation, trusted transfer points, and strict file-handling boundaries matter here.

For a vulnerability with active exploitation, the first control objective is not perfect certainty, it is blast-radius reduction. Restrict access to the parsing application, isolate it from systems that do not need it, and stop unnecessary file exchange paths until patching or mitigation is complete. If the application must remain online, treat every imported project file as untrusted until it has passed a controlled intake process.

Validate exposure with the vendor advisory and the CISA KEV entry rather than relying on generic vulnerability scanners alone. For prioritization, the most useful external references are the CISA Known Exploited Vulnerabilities Catalog, the NIST National Vulnerability Database, and the CVE Program, which together help you anchor product identity, vulnerability record, and remediation tracking.

What to do if patching must wait

If immediate remediation is not possible, reduce exposure by constraining where the software can run, limiting who can open or exchange project files, and separating the affected environment from higher-value assets. Use a temporary compensating control that directly weakens the exploit chain, such as file transfer restrictions, network segmentation, or removal of unnecessary parsing privileges.

At the same time, review whether the vulnerable host has any standing access that would make code execution more damaging than the flaw itself. The key question is whether compromise of this application would let an attacker reach engineering data, adjacent systems, or trusted repositories. That is why vulnerable desktop tooling and operational software often need containment before investigation.

If you need a pattern for how teams handle exposed software weaknesses under pressure, the Zero-Day and Exploited Vulnerabilities Guide is useful because it frames the decision sequence around emergency mitigation, compromise assessment, and post-fix verification. For secure handling of the parsing logic itself, the Secure Coding Guide and the CWE Top 25 Guide both reinforce why input validation failures and memory corruption bugs deserve urgent treatment.

Risk and Threat Considerations

Actively exploited input-validation flaws are attractive because they often turn a simple file-open action into code execution with little user interaction. In practice, that makes the risky path easy to hide inside ordinary engineering or operations work, especially when project files arrive through email, shared storage, removable media, or vendor support channels.

Failure mechanism: The parser accepts malformed project data, performs unsafe writes outside intended memory bounds, and can be driven into execution of attacker-controlled code when a crafted file is opened.

Impact: A successful exploit can compromise the host that parses the file, expose adjacent engineering assets or data, and create a foothold for follow-on access if the system has trust relationships or elevated permissions.

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 NIST CSF 2.0 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	Limits exposed software paths and risky trust boundaries around the affected application.
Recommendation — Harden and isolate the affected software so crafted files cannot reach unnecessary parsing paths.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	The CVE is an improper input validation flaw leading to unsafe parsing and code execution.
	SI-3 — Malicious Code Protection	Active exploitation justifies detecting or blocking hostile files and payloads delivered through the application.
Recommendation — Validate all untrusted project file inputs before parsing or execution. Scan and block untrusted files before they reach the vulnerable parser.
NIST CSF 2.0	ID.AM-01 — Physical devices and systems inventory	Exposure depends on finding every installation that can process the vulnerable file type.
	PR.DS-01 — Data-at-rest is protected	Project files and imported data need protection because the exploit path begins with file handling.
Recommendation — Inventory every DOPSoft 2 installation and map where it is used. Protect project files and restrict untrusted file transfer paths.

Practitioner Guidance

What to verify: Confirm not just whether DOPSoft 2 is installed, but whether any instance can receive or open untrusted project files. That workflow detail determines whether the vulnerability is merely present or operationally exploitable.

Decision rule: If the system is internet-reachable, used with external files, or sits near high-value operational assets, treat it as a high-priority remediation item and isolate it until fixed. If neither file intake nor network adjacency exists, the urgency is still real, but the immediate containment scope may be narrower.

Practitioner takeaway: For KEV-listed flaws, exposure analysis should focus on the exact file path and trust boundary, because that is what turns a known weakness into a real exploitation opportunity.