Is CVE-2024-21893 (Ivanti Connect Secure, Policy Secure, and Neurons Server-Side Request Forgery (SSRF)) being exploited in the wild?

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

Yes. CISA added CVE-2024-21893 to its Known Exploited Vulnerabilities catalogue on 31 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. Ivanti Connect Secure (ICS, formerly known as Pulse Connect Secure), Ivanti Policy Secure, and Ivanti Neurons contain a server-side request forgery (SSRF) vulnerability in the SAML component that allows an attacker to access certain restricted resources without authentication.

What “exploited in the wild” means for this Ivanti CVE

For a CVE like this, “exploited in the wild” is not a theoretical label. It means the flaw has moved from disclosure into active attacker use, so exposure is no longer just about whether the product is vulnerable, but whether the organisation can prove it is not already being probed, abused, or used as an initial access path.

That distinction matters because Ivanti edge appliances sit at a trust boundary. When a server-side request forgery flaw affects a remote access platform, attackers are often trying to reach internal-only resources, harvest data from adjacent services, or pivot into follow-on access. The relevant question is not only “is this a bug?”, but “what trusted network paths does this bug let an attacker reach?”

Resources that explain both the vulnerability class and the surrounding response playbook are especially useful here, including the SSRF Prevention Guide and the VPN Security Guide, because exploitation on a perimeter appliance is rarely isolated to one code path.

How to confirm exposure and decide whether you are affected

Start by identifying every instance of Ivanti Connect Secure, Ivanti Policy Secure, and Ivanti Neurons in scope, including internet-facing appliances, managed services, and any environment that inherited access routes from them. For this question, exposure is not limited to a version inventory check. You also need to know whether the appliance can reach sensitive internal services, because SSRF risk depends heavily on reachable targets.

Confirm whether the appliance has been publicly reachable during the relevant window, whether it has been used for administrative access, and whether it has access to metadata endpoints, internal APIs, directory services, or management interfaces. If you have only a partial inventory, treat that as an exposure gap rather than a clean bill of health.

When you need a broader response workflow for a KEV-listed issue, the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide are the most relevant internal references because they focus on triage, emergency remediation, and verification after exposure.

Containment, patching, and what to do if you cannot remediate immediately

If remediation is delayed, the priority is to reduce what the appliance can reach and what an attacker can gain from it. Restrict administrative access, review exposed services and egress paths, and isolate the appliance from high-value internal resources where feasible. On systems like these, containment is often the difference between a contained defect and a pivot into the rest of the environment.

Apply the vendor’s guidance and CISA’s KEV tracking for version-specific remediation details rather than relying on secondary summaries. If patching must wait, treat that delay as an exception that needs compensating controls, not as a passive acceptance of risk. That usually means tighter network segmentation, aggressive monitoring, and a shorter review cycle until the device is remediated.

Because this is a perimeter access technology, the most relevant supporting read is the Remote Access Identity Guide, which ties exposure management to practical remote-access hardening decisions. For SSRF-specific defensive detail, the SSRF Prevention Guide is the better companion.

Risk and Threat Considerations

SSRF on a remote access appliance is dangerous because it can convert the appliance into a trusted proxy into internal-only systems. That creates a path to data exposure, credential harvesting from adjacent services, and lateral movement when the appliance can reach privileged resources or metadata services.

Failure mechanism: An unauthenticated attacker sends crafted requests that the appliance processes on its behalf, then uses the appliance’s trust position and network reach to touch restricted internal targets that should not be directly reachable from the internet.

Impact: The likely consequences are unauthorized access to internal resources, reconnaissance of private services, and possible compromise expansion if the appliance can contact management planes, identity services, or other privileged back-end systems.

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 NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Documented	This question is about a KEV-listed exploited vulnerability and exposure assessment.
	PR.AA-05 — Resilience Against Identity Impersonation	Exploitation of a perimeter access appliance can expose internal trust and access paths.
	DE.CM-01 — Networks and Network Services Are Monitored	Active exploitation calls for monitoring abnormal appliance traffic and outbound requests.
Recommendation — Identify Ivanti appliances in scope and document exposure to reachable internal resources. Restrict trusted access paths and harden appliance reachability to sensitive services. Monitor appliance egress and admin activity for signs of SSRF abuse or pivoting.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The issue is an actively exploited vulnerability requiring prioritised vulnerability handling.
	SI-4 — System Monitoring	Detecting SSRF abuse depends on monitoring unusual request patterns and outbound connections.
	SC-7 — Boundary Protection	SSRF abuse exploits a trust boundary between the appliance and internal resources.
Recommendation — Continuously track the appliance against KEV status and prioritise remediation. Alert on anomalous appliance requests to internal-only targets and metadata endpoints. Segment appliance network access and limit outbound reach to only required destinations.
OWASP ASVS	V4 — API and Web Service Security	SSRF is a web-service request-routing flaw that needs request validation and destination control.
Recommendation — Validate outbound request destinations and block access to sensitive internal endpoints.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The CVE is exploited through an internet-facing appliance vulnerability.
Recommendation — Hunt public-facing appliance exploitation and correlate it with initial-access activity.

Practitioner Guidance

What to prioritise: Treat internet-facing Ivanti access appliances as high-priority assets for exposure review, because a single SSRF weakness can matter more than many ordinary application flaws when the device sits at a network trust boundary.

What to verify: Confirm not only whether the appliance is patched or mitigated, but also whether it has already been used as a stepping stone. Review authentication logs, unusual outbound requests, admin access patterns, and any signs that the device contacted internal-only endpoints it normally would not touch.

Decision rule: If the appliance is externally reachable and can reach sensitive internal services, assume blast radius is material until proven otherwise. If you cannot patch immediately, reduce reachability first, then investigate for compromise, then restore normal access only after confidence is rebuilt.

Practitioner takeaway: With KEV-listed SSRF on a perimeter access platform, the right question is not whether exploitation is possible, but whether the appliance has already been turned into an internal access path.

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