How do you patch or mitigate CVE-2020-3433 (Cisco AnyConnect Secure Mobility Client for Windows DLL Hijacking)?

CISA’s required action for CVE-2020-3433 is to apply updates per vendor instructions. In practice, find every instance of Cisco AnyConnect Secure 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 CVE-2020-3433 means for a Windows AnyConnect estate

CVE-2020-3433 is a Windows DLL hijacking issue, so the practical question is not just whether the software is installed, but whether the vulnerable Windows deployment can be reached and influenced in a way that lets an attacker load a malicious DLL. For that reason, the first pass is estate-wide discovery, not just patch verification.

Affected systems should be treated as potentially exposed until you can confirm the vendor update or mitigation has been applied. Vulnerability Management Guide is useful here because this is the kind of issue where asset scope, prioritisation, exception handling and verification matter as much as the fix itself.

When you cannot immediately patch, the response is to reduce reachable attack surface. That usually means removing internet exposure, limiting where the client can be launched, and considering temporary removal from service if the vulnerable software cannot be protected in place.

Why DLL hijacking changes the response

DLL hijacking is not a simple version-mismatch problem. The attacker goal is to place or influence a library that the application loads before the legitimate one, which can turn ordinary client execution into code execution under the application’s context. That makes exposure and execution path more important than the product name alone.

In Windows environments, these issues often sit beside other execution-persistence patterns, which is why post-fix review matters. Persistence Techniques Guide is a useful companion because it frames how attackers commonly retain foothold after an initial execution path is found.

The operational implication is that you should verify not only that the update is present, but also that the vulnerable execution path is no longer reachable. If the client is still exposed to untrusted locations, weak launch contexts, or uncontrolled local write paths, the risk can persist even after a partial hardening effort.

What to do after patching or mitigation

After the update or workaround is in place, review logs and endpoint telemetry for earlier abuse. The important question is whether the flaw was used before you closed it, not just whether the environment is now clean.

That review should include nearby signals such as unusual process launches, unexpected child processes, odd DLL loading behaviour, and post-exploitation changes on hosts that used the client. If you find evidence of misuse, treat it as a host compromise question, not a patching ticket.

For broader exploit-tracking and remediation discipline, the CISA Known Exploited Vulnerabilities Catalog, the NIST National Vulnerability Database, and the CVE Program are the authoritative places to confirm record details, catalogue status and reference data before you close out the finding.

Risk and Threat Considerations

The main risk is code execution through trusted software loading behaviour, which can let an attacker pivot from a vulnerable client into local execution on a Windows endpoint. In practice, that makes a seemingly narrow DLL issue a potential foothold for broader compromise if the host is reachable and the execution path is predictable.

Failure mechanism: An attacker leverages the application’s DLL search or loading behaviour so a malicious library is loaded instead of the intended one, turning a local software weakness into execution on the endpoint.

Impact: The result can include unauthorized code execution, endpoint compromise, and, if the host is used for VPN or remote access, a path into broader internal resources before defenders notice.

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 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-7 — Continuous Vulnerability Management	This is a known exploited vulnerability requiring discovery, prioritisation and remediation tracking.
Recommendation — Prioritise, patch and verify the vulnerable client across the estate.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue is remediated through applying vendor updates and handling exceptions safely.
	AU-6 — Audit Review, Analysis, and Reporting	Post-fix log review is needed to detect signs of earlier exploitation.
Recommendation — Apply the vendor fix and track remediation to closure. Review endpoint and access logs for evidence of pre-patch abuse.
NIST CSF 2.0	DE.CM-01 — Networks and Network Services are Monitored to Find Potentially Adverse Events	Monitoring is needed to spot exploitation signals and suspicious client behaviour.
Recommendation — Monitor endpoints and network activity for exploit indicators.
MITRE ATT&CK	T1574.001 — DLL Search Order Hijacking	The vulnerability type is DLL hijacking, which maps directly to this technique.
Recommendation — Hunt for DLL hijacking conditions and suspicious library loads.

Practitioner Guidance

What to verify: Confirm every Windows instance of Cisco AnyConnect Secure Mobility Client is inventoried, updated or mitigated, and no exposed deployment remains reachable from the internet or other untrusted locations. If you cannot prove that state, treat the host as still at risk.

Decision rule: If the vendor fix cannot be applied promptly, choose containment over convenience, meaning isolate the client, reduce exposure, or remove the service from use until you can close the execution path safely.

What to measure: Track not only patch completion, but also how quickly you can identify vulnerable instances, validate mitigation, and review telemetry for pre-fix exploitation. Fast remediation without validation leaves an evidence gap.

Practitioner takeaway: For DLL hijacking issues, the real control objective is to remove the attacker’s chance to influence what the application loads, then prove that no earlier execution occurred before you declare the estate safe.