Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2021-22893 (Ivanti Pulse Connect Secure Use-After-Free) being…
Threats, Abuse & Incident Response

Is CVE-2021-22893 (Ivanti Pulse Connect Secure Use-After-Free) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-22893 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Ivanti Pulse Connect Secure contains a use-after-free vulnerability that allow a remote, unauthenticated attacker to execute code via license services.

What “exploited in the wild” means for this CVE

For a vulnerability like CVE-2021-22893, the practical question is not whether proof-of-concept code exists, but whether defenders should treat exposure as active. CISA’s KEV listing is the strongest operational signal for that, because it reflects reliable evidence of exploitation rather than theoretical risk. For this CVE, the exposure concern is especially high because the flaw sits in a remote attack surface and can be reached without prior authentication.

When a CVE is already in KEV, the right mental model is “incident response underway,” not “routine patch backlog.” That changes prioritisation, containment, and verification work. It also means appliance owners should assume opportunistic scanning, repeated exploitation attempts, and possible follow-on credential or session theft until the device is confirmed clean and remediated.

How to confirm exposure and scope the response

Start by confirming whether the vulnerable Ivanti Pulse Connect Secure appliance is present anywhere in your estate, including decommissioned, standby, and externally managed instances. VPN and edge appliances are often missed by conventional asset inventories, so the discovery step should include network perimeter review, remote admin records, and any third-party-operated devices that terminate user access.

Once you know the appliance exists, check whether it was internet-facing during the exploitation window and whether it handled privileged remote access, partner access, or administrative sessions. That context matters because VPN appliances can expose more than the software itself, they can expose authenticated sessions, passwords, or other material used to reach internal systems. See the broader VPN Security Guide for why perimeter VPN devices deserve special treatment during incident triage.

What remediation should look like for an actively exploited appliance

The first priority is to follow the vendor advisory and the CISA KEV entry for authoritative remediation steps, then treat the appliance as a high-risk edge system until verified otherwise. In practice that means applying the fix or vendor mitigation as soon as operationally possible, then validating that the device is no longer exposing the vulnerable path and that administrative access is still constrained.

If the appliance is part of a broader remote-access stack, do not treat patching as the end of the work. Review remote access controls, disable or retire stale access paths, and tighten entry-point authentication so a single exposed service cannot remain a durable foothold. The Remote Access Identity Guide is useful here because it frames VPN security as an access-governance problem as much as a patching problem.

Risk and Threat Considerations

This CVE is risky because it combines remote reachability, unauthenticated exploitation, and confirmed active abuse. In a perimeter device, that combination can turn a single software flaw into broad network exposure, especially if the appliance brokers privileged user access or stores authentication material.

Failure mechanism: A remote attacker can trigger the use-after-free condition on the VPN appliance, gain code execution, and then use the device’s trust position to pivot into sessions, credentials, or internal services.

Impact: Successful exploitation can lead to device compromise, persistent access, interception of remote access traffic, and broader intrusion into the environment served by the appliance.

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.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementKEV-listed exploitation requires rapid discovery and prioritization of vulnerable edge appliances.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities in exposed appliances immediately.
NIST SP 800-53 Rev 5RA-5 — Vulnerability Monitoring and ScanningThis CVE needs continuous identification, tracking and response for exposed systems.
IR-4 — Incident HandlingActive exploitation requires containment, investigation and recovery actions beyond patching.
IA-5 — Authenticator ManagementExploited VPN appliances can expose credentials and sessions that may need rotation.
Recommendation — Scan for the vulnerable appliance and track remediation until exposure is closed. Treat confirmed exploitation as an incident and execute containment and recovery steps. Rotate exposed credentials, tokens and sessions after compromise is suspected.
NIST CSF 2.0DE.CM-09 — Continuous Monitoring for Exposures and VulnerabilitiesThe answer hinges on identifying exposed appliances and watching for active exploitation.
Recommendation — Continuously monitor external-facing assets for exploitable exposure and abuse.

Practitioner Guidance

What to prioritise: Treat KEV-listed edge appliances as urgent exposure, not routine vulnerability management. If the device is internet-facing and still in service, remediation and containment should move ahead of lower-risk remediation work elsewhere.

What to verify: Confirm whether the appliance handled privileged logins, partner access, or administrative traffic, then check for signs of post-exploitation activity such as unexpected configuration changes, new accounts, altered access policies, or unusual outbound connections.

Decision rule: If you cannot patch immediately, isolate the appliance, restrict administrative access, and increase monitoring for compromise before assuming business continuity alone is an acceptable exception.

Practitioner takeaway: For KEV-listed perimeter flaws, the main question is not only “is it patched?” but “has this appliance already become an access path?”

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org