Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2024-21887 (Ivanti Connect Secure and Policy Secure…
Threats, Abuse & Incident Response

Is CVE-2024-21887 (Ivanti Connect Secure and Policy Secure Command Injection) 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-2024-21887 to its Known Exploited Vulnerabilities catalogue on 10 January 2024, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.

What being in CISA KEV means for CVE-2024-21887

A KEV listing is not a theoretical risk signal, it means CISA has judged the issue to have reliable evidence of active exploitation. For CVE-2024-21887, that changes the operational posture immediately: treat internet-facing Ivanti appliances as exposed until proven otherwise, and prioritise this issue ahead of routine backlog work. Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for authoritative action details.

That urgency is especially important for edge devices because they often sit outside normal endpoint tooling and can be reachable before compensating controls notice abuse. For a practical remediation lens, use the Zero-Day and Exploited Vulnerabilities Guide to anchor triage on exploitability, emergency mitigation, and post-fix hunting rather than on severity labels alone.

Why Ivanti command injection problems are operationally serious

Command injection on a remote access appliance is high-impact because the attacker is not just touching an application, they may be reaching a trust boundary that brokers user access, authentication flows, and administrative functions. Once that boundary is crossed, the appliance can become a launch point for credential theft, session abuse, lateral movement, or further tampering with access paths. The Ivanti Connect Secure exploitation 2024 write-up shows why these events are treated as more than ordinary software bugs.

For defenders, the practical issue is blast radius. A single compromised edge appliance may expose user secrets, service credentials, API keys, or certificates that support broader access. The Remote Access Identity Guide is a useful companion because it frames VPN and remote access hardening as an access-governance problem, not just a network configuration problem.

How to confirm exposure, contain it, and look for earlier compromise

Start by confirming whether any Ivanti Connect Secure or Policy Secure instances are reachable from the internet or otherwise in scope for this issue. If the product is present, assume exposure until you have checked version, configuration, and vendor guidance, then move straight to patching or the published mitigation path. If patching must wait, narrow access, restrict management interfaces, and monitor for signs that the appliance has already been used as an entry point.

After remediation, review authentication, admin, and appliance logs for suspicious command execution, unexpected configuration changes, new accounts, unusual outbound connections, and any evidence of credential harvesting. If you cannot trust the appliance state, treat downstream secrets and sessions as potentially exposed and rotate them in a blast-radius-aware order, starting with the credentials that can reach production systems. The Vulnerability Management Guide is a good reference for prioritisation, exception handling, and verification discipline.

Risk and Threat Considerations

Internet-facing remote access appliances are attractive targets because they often bridge users, internal applications, and privileged access. Once command injection is available, attackers can use the appliance as a foothold to persist, steal secrets, or pivot into internal services before the compromise is obvious.

Failure mechanism: The attacker abuses injectable command handling in the appliance to run operating system commands in a trusted perimeter position, then uses that access to collect credentials, alter configuration, or stage follow-on activity.

Impact: The result can include full remote access compromise, stolen sessions or credentials, internal lateral movement, and a need to rotate multiple downstream secrets rather than only patching the appliance itself.

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 ManagementThis is a live exploited vulnerability on a perimeter appliance.
Recommendation — Prioritise exposed Ivanti assets for immediate remediation and verification.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationThe issue requires rapid correction and validation of a known software flaw.
AU-6 — Audit Record Review, Analysis, and ReportingPost-exploitation hunting depends on reviewing appliance and authentication logs.
AC-4 — Information Flow EnforcementContainment depends on restricting reachability and management paths on the edge device.
Recommendation — Apply Flaw Remediation to accelerate patching and mitigation of the appliance. Review appliance audit logs for signs of exploitation and follow-on activity. Restrict access paths to the appliance while remediation is pending.
NIST CSF 2.0ID.RA-01 — Asset Vulnerabilities Are Identified and DocumentedExposure confirmation begins with identifying vulnerable Ivanti instances.
Recommendation — Document affected appliances and confirm their exposure status.

Practitioner Guidance

What to prioritise: Triage this as an exposed-edge-device incident, not a normal vulnerability ticket. If the appliance is internet-facing, remediation and compromise assessment should move ahead of lower-risk patch work.

What to verify: Confirm whether the device has been patched or mitigated, whether any management exposure remains, and whether logs show unusual commands, account changes, or outbound activity around the exploitation window.

Decision rule: If you cannot establish that the appliance was clean before remediation, assume the trust boundary is compromised and rotate the credentials, sessions, and keys that device could have exposed.

Practitioner takeaway: With KEV-listed edge vulnerabilities, the key judgment is not whether exploitation is possible, it is whether you can still trust the appliance and anything it authenticated or issued on behalf of users.

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