CVE-2024-22024: Ivanti Connect Secure XXE exposing restricted resources without authentication
The short version: Ivanti Connect Secure and Policy Secure have an XML External Entity (XXE) flaw in their SAML component (CVE-2024-22024) that lets an unauthenticated attacker reach certain restricted resources. It emerged during the period of heavy exploitation of Ivanti edge appliances, a public proof-of-concept exists, and it affects specific patched-then-repatched builds. It's not (as of writing) in CISA's KEV, but on an internet-facing gateway it's worth prompt attention. Steady hands — patch to a fixed build.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Moderate — on an internet-facing access appliance (see below) |
| CVSS v3.1 (NVD) | 8.3 — High · AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L |
| EPSS | 94.72% · 99.85th percentile (2026-07-17) |
| In CISA KEV? | No — not listed at time of writing |
| Known exploited? | Not confirmed in the wild; public proof-of-concept exists |
| Vulnerability type | CWE-611 XML External Entity (XXE) → unauthenticated access to restricted resources |
| Requires authenticated session? | No — pre-authentication |
| Affected | Ivanti Connect Secure (9.x, 22.x), Ivanti Policy Secure, ZTA gateways — specific builds including 9.1R14.4, 9.1R17.2, 9.1R18.3, 22.4R2.2, 22.5R1.1, 22.5R2.2 |
| Fixed in | Repatched builds from 2024-02-08 (e.g. Connect Secure 9.1R14.5, 9.1R17.3, 9.1R18.4, 22.4R2.3, 22.5R1.2, 22.5R2.3, 22.6R2.2) and later |
What you need to know
CVE-2024-22024 is an XXE in the SAML component. When an application parses attacker-controlled XML without disabling external entities, the attacker can make it resolve references it shouldn't — here, reaching certain restricted resources without authenticating.
Context is what makes this one notable:
- It appeared mid-storm. It was disclosed during the same early-2024 window in which Ivanti Connect Secure appliances were being exploited at scale, and it affected builds that customers had just patched — so a rushed upgrade could land you on a still-vulnerable version.
- It's unauthenticated and on an edge device. No credential required, on the box that fronts remote access.
- A proof-of-concept is public, which is why its exploitation likelihood scores high even without a confirmed in-the-wild campaign.
How serious we see it
Moderate — on an internet-facing gateway.
The impact metrics are individually modest (limited confidentiality, integrity, and availability), which is why the base score sits at 8.3 rather than higher, and it isn't in KEV. But "unauthenticated access to restricted resources on your VPN appliance" is not something to leave sitting, especially given the elevated attention Ivanti edge devices were under. The reassuring part is that it's bounded and fixable: it affects specific builds, the repatched versions are published, and you can tell quickly whether you're on one of them.
Recommendations
Straight from Ivanti's advisory:
- Patch to a fixed build. Confirm you're on a repatched version — note that some builds released during the January 2024 response were themselves affected.
- Confirm exposure first. Verify your exact Connect Secure / Policy Secure / ZTA build against the fixed list.
- Reduce exposure. Restrict who can reach the gateway and its management interface.
- Hunt if you ran an affected build while exposed. Review appliance logs and run Ivanti's Integrity Checker.
- If you find indicators, respond. Rebuild and rotate secrets the appliance handled.
How BreachRisk sees it
BreachRisk discovers internet-facing Ivanti Connect Secure and Policy Secure interfaces from the outside, fingerprints the build, and flags exposure tied to this and other known Ivanti vulnerabilities. We detect and flag the exposed, affected version; we don't exploit it.
The continuous view matters most during a fast-moving patch cycle like Ivanti's early-2024 sequence: BreachRisk shows you which of your appliances is actually on a vulnerable build right now, so a hurried upgrade doesn't leave you quietly exposed.