How do you patch or mitigate CVE-2021-22893 (Ivanti Pulse Connect Secure Use-After-Free)?

CISA’s required action for CVE-2021-22893 is to apply updates per vendor instructions. In practice, find every instance of Ivanti Pulse Connect 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-2021-22893 means for Pulse Connect Secure operators

This is a memory-safety flaw in an internet-facing VPN appliance, so the first job is to confirm where Pulse Connect Secure is deployed and whether any instance is still reachable from the public internet. For edge devices, the exposed service itself is the risk boundary, because compromise can occur before a user signs in or a host-based control sees anything unusual.

If the appliance is still in service, the right baseline is the vendor update path, not compensating controls alone. For vulnerable remote-access infrastructure, NHI Management Group recommends treating the appliance as a privileged access path and validating that the patch or mitigation actually removes the exploitable condition, not just the symptom.

How to patch or mitigate when downtime is limited

Apply the vendor security update or the documented mitigation exactly as directed by Ivanti and CISA. If patching cannot be completed quickly, remove the device from internet exposure or take it out of service, because leaving a vulnerable VPN gateway externally reachable preserves the attack path even when the rest of the network is hardened.

Where temporary containment is the only option, reduce exposure first: restrict access to the smallest possible set of management sources, remove unnecessary external publishing, and plan for a rapid service replacement if the appliance cannot be brought back to a trusted state. The strongest mitigation for an edge VPN vulnerability is usually to stop trusting the exposed instance at all.

For broader patching context, it helps to work from a Vulnerability Management Guide so the appliance is not handled as a one-off emergency but as part of your normal asset scope, exception handling and verification process.

What to check after remediation

After patching or containment, review logs for signs of earlier exploitation and assume the appliance may have been targeted before the fix landed. Because this class of issue affects an internet-facing access path, post-remediation validation should include evidence that the device was actually updated, that exposure has been removed where required, and that no suspicious administrative or session activity remains unexplained.

If you find indicators of compromise, treat the VPN as a potential credential and session exposure point. That may require resetting credentials or rotating access material that traversed the appliance, especially for privileged users or service accounts that relied on the affected gateway.

Risk and Threat Considerations

Internet-facing VPN appliances are high-value targets because they sit at the edge of trust, see legitimate user traffic, and can provide a direct route into internal systems. When exploitation is active in the wild, the main concern is not just service disruption, but silent foothold creation, session abuse, and follow-on credential harvesting.

Failure mechanism: A use-after-free condition can let an attacker influence appliance memory during request handling, turning a remote request into code execution or reliable crash conditions depending on how the bug is reached and what defenses are present.

Impact: Successful exploitation can expose remote access sessions, internal connectivity, stored secrets, or administrative control, which is why exposure reduction and compromise review matter even after a patch is applied.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The question is about patching and mitigating a known exploited flaw.
Recommendation — Prioritise and verify remediation for the affected appliance before returning it to service.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	CVE remediation requires applying the vendor fix or mitigation and validating outcome.
	RA-5 — Vulnerability Monitoring and Scanning	Operators need asset discovery and validation to find every exposed instance and confirm exposure is removed.
	IR-4 — Incident Handling	The direct answer calls for log review for signs of earlier exploitation.
Recommendation — Apply approved updates or mitigations and verify the vulnerability is remediated. Scan and inventory exposed appliances, then confirm the vulnerable service is no longer reachable. Investigate the appliance for compromise indicators after remediation.
OWASP Non-Human Identity Top 10	NHI-06 — Insecure Cloud Deployment Configurations	Internet-exposed remote access appliances create the same exposed trust-boundary problem this control addresses.
Recommendation — Remove unnecessary external exposure from the remote-access entry point until it is fully trusted again.

Practitioner Guidance

What to prioritise: Inventory every Pulse Connect Secure instance first, then separate internet-exposed appliances from those already isolated or retired. The exposed systems deserve immediate patching or shutdown because they carry the highest likelihood of exploitation.

What to verify: Confirm the vendor update or mitigation was applied to the exact appliance instance, not just planned or queued. Then verify that the device no longer presents the vulnerable service externally and that logs cover the full pre-remediation window.

Decision rule: If you cannot prove the fix was applied cleanly, or if the appliance cannot be removed from exposure quickly, treat removal from service as the safer outcome. For this kind of edge-device flaw, uncertainty is itself a security condition.

Practitioner takeaway: The real objective is not to “patch a VPN box”, it is to re-establish trust in the remote-access path by removing exposure, proving remediation, and checking for prior abuse before the appliance is allowed back into normal use.