How do you patch or mitigate CVE-2021-38406 (Delta Electronics DOPSoft 2 Improper Input Validation)?

CISA’s required action for CVE-2021-38406 is to the impacted product is end-of-life and should be disconnected if still in use. In practice, find every instance of Delta Electronics DOPSoft 2 in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What actually changes when you patch CVE-2021-38406?

CVE-2021-38406 is an improper input validation flaw in Delta Electronics DOPSoft 2, so the practical question is not just whether a patch exists, but whether you can actually remove the vulnerable software from exposure. Start by confirming every workstation, engineering laptop, jump host, and support image that can run or open DOPSoft 2, then follow the vendor update path or the documented mitigation. For vulnerability tracking and verification, the CVE Program and the NIST National Vulnerability Database are the best places to confirm the canonical record.

Because the impacted product is end-of-life, the real decision point is often operational rather than technical: if the software cannot be remediated in place, you have to treat continued use as a containment problem. That means removing internet reachability, reducing where the software can be launched, and taking it out of service if neither a vendor fix nor a safe mitigation is available. In OT environments, the exposure is often tied to the engineering workflow itself, which is why segmentation and remote-access control matter as much as the patch.

For OT and industrial networks, the OT Security Guide is a useful companion for deciding where DOPSoft 2 should be isolated, which conduits should be constrained, and how to keep engineering tools from becoming a path into the control environment.

How do you reduce the chance of exploitation before and after remediation?

Improper input validation usually becomes dangerous when a parser, file handler, or update path accepts malformed data and then processes it with trust. For an engineering tool, that can create crash, code execution, or malformed-project risks depending on how the flaw is triggered. The safest short-term posture is to assume the vulnerable binary or project files may be weaponised and to narrow who can open or transfer those files until the fix is applied.

If patching is delayed, focus on containment that reduces attack surface and blast radius. Keep the affected host off the public internet, restrict removable media and file transfer paths, limit which operators can run the application, and avoid opening untrusted project files on production-connected systems. If the software is needed only for maintenance windows, isolate it to a controlled workstation and record when it is used so you can distinguish routine activity from suspicious execution.

The CISA Known Exploited Vulnerabilities Catalog should be part of the triage workflow because this flaw was added as actively exploited, which changes the priority from routine patching to exposure reduction and verification.

What should you check after patching or disconnecting DOPSoft 2?

After remediation, look for signs that the flaw may already have been used against the environment. Review endpoint, application, and remote-access logs for unusual launches of DOPSoft 2, unexpected file opens, failed parses, process crashes, or activity from hosts that should never have touched the software. In OT settings, also check whether any engineering workstations have had new scheduled tasks, startup items, or configuration changes that would let an attacker return.

Where the software was used to reach control assets, confirm whether the same workstation held credentials, VPN access, or remote support channels that could have been abused after initial exploitation. If the vulnerable host had that kind of reach, treat the incident as potentially broader than a single application issue and validate adjacent accounts, sessions, and management paths before closing the case.

If you need a structured way to prioritise the review and document the result, the Vulnerability Management Guide is useful for turning patch status, exposure, verification, and exception handling into a repeatable workflow.

Risk and Threat Considerations

This flaw is risky not just because it exists, but because end-of-life software tends to persist in operational environments longer than intended. Once a vulnerable engineering tool is reachable from a normal admin workstation, attackers can target the update path, the file parser, or the operator workflow to gain code execution or disrupt industrial operations.

Failure mechanism: Malformed input is accepted by DOPSoft 2 and processed unsafely, which can let an attacker trigger unexpected behaviour on the host and potentially pivot into connected engineering or OT systems.

Impact: The likely consequence is compromise of the engineering workstation or adjacent control environment, followed by downtime, unsafe changes, or broader access to industrial assets if the host is trusted inside the network.

Standards & Framework Alignment

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

NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	CVE-2021-38406 is an input validation flaw needing defensive validation controls.
	RA-5 — Vulnerability Monitoring and Scanning	The answer depends on finding exposed DOPSoft 2 instances and confirming remediation.
	SI-2 — Flaw Remediation	The question is specifically about patching or mitigating a known exploited flaw.
Recommendation — Enforce SI-10 validation on all untrusted inputs and project files processed by the tool. Use RA-5 to inventory affected hosts, verify exposure, and track remediation status. Apply SI-2 to remediate the flaw, then validate that the vulnerable software is removed or updated.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	This CVE requires discovering, prioritising and remediating vulnerable instances.
	CIS-12 — Network Infrastructure Management	The mitigation depends on segmenting and limiting reachability to the affected software.
	CIS-8 — Audit Log Management	Post-remediation review of logs is part of checking for earlier exploitation.
Recommendation — Continuously identify, prioritise, and remediate DOPSoft 2 exposure under CIS-7. Restrict network exposure and isolate the vulnerable workstation under CIS-12. Review and retain logs that could show exploitation, execution, or persistence activity under CIS-8.
NIST CSF 2.0	PR.PS-01 — Configuration Management	Remediation requires updating or removing vulnerable software and constraining its deployment.
	DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events	The answer calls for checking logs and monitoring for signs of prior exploitation.
	RS.AN-01 — Investigation is performed to determine the root cause of events	The answer advises reviewing signs of earlier compromise after patching.
Recommendation — Apply PR.PS-01 to manage the software configuration and remove unsafe deployments. Use DE.CM-01 to detect suspicious activity around the vulnerable host and related services. Perform RS.AN-01 analysis to determine whether the flaw was used before remediation.
OWASP ASVS	V2 — Validation and Business Logic	The vulnerability is an improper input validation issue at the software layer.
Recommendation — Apply V2 validation requirements to reject malformed or unexpected input safely.

Practitioner Guidance

What to prioritise: Treat asset discovery as the first control, not the last. You cannot remediate what you have not found, and engineering tools are often missed on endpoints that look like ordinary office systems.

What to verify: Confirm whether the vendor update or mitigation is actually applicable to the installed build and whether the affected machine still needs the software at all. If it does, verify the host is isolated enough that compromise would not give an attacker a direct path into production systems.

Decision rule: If the host must remain in service and no fix is available, reduce exposure immediately and document the exception. If the host is not essential, removal from service is the safer choice than prolonged compensating controls.

Practitioner takeaway: With end-of-life industrial software, the real remediation goal is not just patch compliance, it is eliminating a reachable attack path before the vulnerable tool becomes a foothold into the control environment.