Is CVE-2021-22899 (Ivanti Pulse Connect Secure Command Injection) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-22899 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Ivanti Pulse Connect Secure contains a command injection vulnerability that allows remote authenticated users to perform remote code execution via Windows File Resource Profiles.

What CVE-2021-22899 Means for Exposure and Exploitation

The practical answer is that this is not a theoretical weakness. CISA’s KEV listing means defenders should treat the issue as actively exploited until proven otherwise, and the immediate question becomes whether any Internet-facing Pulse Connect Secure appliance is still reachable, still vulnerable, or already showing signs of post-exploitation activity. For remote-access products, exposure is often broader than the patched host itself because credentials, sessions, and admin access paths can be touched during abuse.

A command injection flaw is especially serious in a VPN appliance because the device sits at a trust boundary. If an authenticated attacker can translate application access into operating-system command execution, the appliance can become a bridge into internal networks rather than just a remote access endpoint.

In practice, teams should verify whether the appliance is publicly reachable, whether it is running the affected branch, and whether administrative or user sessions were active during the risk window. The more valuable test is not just “is it patched”, but “was it a pivot point for deeper access?”

Patch, Mitigation, and the Right Priority Order

For actively exploited edge-device flaws, the priority order is exposure reduction first, patching second, and validation third. If the vendor fix is available, apply it using the vendor advisory and corroborate version-specific guidance against the CISA Known Exploited Vulnerabilities Catalog rather than relying on memory or an internal ticket summary. If the device cannot be patched immediately, isolate it as tightly as possible and remove any unnecessary management exposure.

For this class of appliance, compensating controls are only acceptable as a short bridge. Disable unused administrative paths, restrict source IPs where possible, and make sure the device is not being treated as an always-trusted access layer. If remote access must stay up, that exception should be time-bounded and tracked as a formal risk acceptance, not an open-ended workaround.

Because this is a perimeter system, the business impact of delayed remediation is usually higher than the patching inconvenience. That is why the safest approach is to treat the appliance like a high-value asset, not just another server in the patch queue.

What to Check for After a VPN Appliance Command Injection

Once a VPN appliance flaw has been exploited, the main concern is not only code execution on the box, but what the attacker could have done next. Hunt for new or modified accounts, suspicious administrative changes, unusual command execution, unexpected child processes, tampered configuration, and any sign that the appliance was used to reach internal systems. If logs are sparse, assume the attacker may have relied on the device’s trusted position to reduce visibility.

This is also the point to review whether credentials, sessions, or device-level secrets could have been exposed. The answer depends on how the appliance was configured and used, but for remote access systems it is prudent to assume that authenticated sessions and adjacent access material may need review even when no clear misuse has yet been confirmed.

Where logs exist, preserve them before rebooting or rebuilding the device. A full compromise assessment is more useful than a narrow vulnerability scan because exploitation of a VPN appliance often leaves evidence in authentication records, configuration drift, and lateral movement artifacts rather than in a single obvious malware sample.

Risk and Threat Considerations

VPN and remote-access appliances are high-value targets because they sit between the Internet and the internal environment. A command injection flaw in that position can turn a legitimate access pathway into an initial foothold, and once the appliance is trusted, detection of follow-on activity can be delayed.

Failure mechanism: An authenticated attacker uses command injection to move from application-level access to operating-system command execution, then leverages the appliance’s privileged network position to expand access, harvest credentials, or modify configuration.

Impact: The compromise can extend beyond the appliance itself and create internal network exposure, credential risk, session abuse, and persistence opportunities that outlast the original vulnerability.

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-7 — Continuous Vulnerability Management	Actively exploited CVEs require rapid identification and remediation prioritisation.
Recommendation — Prioritise and remediate KEV-listed appliances before lower-risk backlog items.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This question is about verifying exposure and tracking an actively exploited vulnerability.
	SI-2 — Flaw Remediation	The core action is applying the vendor fix or approved mitigation quickly.
	AU-6 — Audit Review, Analysis, and Reporting	Post-exploitation review depends on log analysis and suspicious activity detection.
Recommendation — Use continuous vulnerability monitoring to confirm appliance exposure and remediation status. Apply the vendor remediation promptly and document any temporary exception. Review appliance and authentication logs for signs of exploitation or pivot activity.
NIST CSF 2.0	ID.RA-01 — Risk Identification	KEV status changes the risk posture and should drive response priority.
Recommendation — Treat KEV-listed exposure as an identified risk requiring urgent action.

Practitioner Guidance

What to prioritise: Treat Internet-facing remote-access appliances as emergency assets when they appear in KEV. If the device is exposed and the patch cannot be applied immediately, reduce reachability first, because exploitation risk is driven by both exposure and trust boundary placement.

What to verify: Confirm not only that the vendor fix is installed, but also whether the appliance shows signs of suspicious admin activity, unexpected configuration change, or internal pivoting. For this type of issue, absence of visible malware is not strong evidence of safety.

Practitioner takeaway: For an actively exploited VPN flaw, the real decision is whether you can still trust the appliance as an access boundary, not whether the vulnerability exists in isolation.

Deepen Your Knowledge

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