CVE-2024-21893: Ivanti Connect Secure SSRF, chained for unauthenticated access and actively exploited
The short version: Ivanti Connect Secure and Policy Secure — widely deployed VPN and access gateways — have a server-side request forgery (SSRF) flaw in their SAML component (CVE-2024-21893) that lets an unauthenticated attacker reach restricted internal resources. In the wild it was used to bypass Ivanti's original mitigation and, chained with a companion command-injection bug, to reach unauthenticated code execution on the appliance. It's in CISA's KEV catalog and was exploited by multiple actors. If you run an affected build, patch and hunt — steady hands, but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Critical — in practice (see below) |
| CVSS v3.1 (NVD) | 8.2 — High · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N |
| EPSS | 99.99% · 99.99th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediate by 2024-02-02 (added 2024-01-31) |
| Known exploited? | Yes — actively exploited by multiple actors; used to bypass the January 2024 mitigation |
| Vulnerability type | CWE-918 server-side request forgery → unauthenticated access to restricted resources (chained to RCE) |
| Requires authenticated session? | No — pre-authentication |
| Affected | Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure (9.x, 22.x), Ivanti Neurons for ZTA |
| Fixed in | Patches released from 2024-01-31 (e.g. Connect Secure 9.1R14.4, 9.1R17.2, 9.1R18.3, 22.4R2.2, 22.5R1.1, 22.5R2.2) and later |
What you need to know
CVE-2024-21893 is an SSRF in the SAML component of the appliance. On its own, SSRF lets an attacker make the appliance issue requests it shouldn't — reaching internal resources without authenticating. That's the 8.2.
The reason it earned a place in the early-2024 Ivanti story is what it was used with and against:
- It defeated the mitigation. When Ivanti shipped an interim mitigation for the earlier Connect Secure exploit chain, attackers used this SSRF to work around it — turning a "temporarily contained" situation back into an exposed one.
- It's a chain link. Combined with the companion command-injection flaw, it contributed to unauthenticated remote code execution on an internet-facing access gateway.
- It was exploited broadly. Security researchers observed exploitation from hundreds of distinct IP addresses, beginning before public proof-of-concept code was even released.
How serious we see it
Critical — in practice, not on paper.
An 8.2 "High" understates it here. This is an internet-facing gateway — the device that fronts remote access to your network — during a period when Ivanti appliances were among the most heavily attacked assets on the internet, and this specific flaw was the technique that unwound the vendor's own stopgap. We rate it by what it did in the field. The bounded, reassuring part: it affects specific product versions, the patches are published, and exposure is quick to determine — though, as with any bug exploited before patches were universal, being patched and being clean are separate questions.
Recommendations
Straight from Ivanti's guidance and CISA:
- Patch now. Move to a fixed build for your product line (Connect Secure, Policy Secure, or Neurons for ZTA).
- Assume the mitigation window mattered — hunt. Follow Ivanti's and CISA's guidance, run the current Integrity Checker, and review for signs of compromise.
- If you find indicators, respond fully. Rebuild the appliance and rotate all credentials, certificates, and secrets it handled — investigators recovered domain-admin credentials from compromised appliances.
- Reduce exposure. Limit who can reach the gateway and its management interface.
- Confirm your exposure first. Verify whether you run an affected Connect Secure / Policy Secure / ZTA build.
How BreachRisk sees it
BreachRisk starts from the outside, the way an attacker does. From little more than your domain it discovers internet-facing Ivanti Connect Secure and Policy Secure interfaces, fingerprints the build, and flags exposure tied to KEV-listed, actively exploited vulnerabilities like this one — surfaced at the top of your results because it's in KEV. We detect and flag the exposed, affected appliance; we don't exploit it.
That continuous, outside-in view is exactly what you want when an edge-device chain breaks: the exposed gateway is already mapped, so you can go straight to patch-and-verify instead of starting with an inventory.