CVE-2023-46805: Ivanti Connect Secure authentication bypass, actively exploited and chained to RCE
The short version: CVE-2023-46805 is an authentication bypass in the web component of Ivanti Connect Secure and Ivanti Policy Secure. On its own it lets a remote attacker reach restricted resources without valid credentials; chained with the command-injection flaw CVE-2024-21887, it yields unauthenticated remote code execution. It was exploited as a zero-day before patches were available and is in CISA's KEV catalog. If you run an affected build, this is patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice, as the entry half of an unauthenticated RCE chain |
| CVSS v3.0 (NVD) | 8.2 — High · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N |
| EPSS | ~99.99% · 99.98th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2024-01-22 |
| Known exploited? | Yes — exploited as a zero-day, chained with CVE-2024-21887 |
| Vulnerability type | Authentication bypass → access to restricted resources; enables the CVE-2024-21887 command-injection chain |
| Requires authenticated session? | No — pre-authentication |
| Affected | Ivanti Connect Secure 9.x and 22.x; Ivanti Policy Secure 9.x and 22.x |
| Fixed in | Patched builds per Ivanti's advisory (staggered release began 2024-01-31); interim mitigation XML published earlier |
What you need to know
CVE-2023-46805 is a flaw in how the web component enforces access control. A remote, unauthenticated attacker can send crafted requests that bypass the checks meant to gate restricted endpoints. By itself that's an access-control failure; the reason it earned top-of-queue attention is the pairing.
- It's the front half of a chain. Combined with CVE-2024-21887 — a command injection in the same product — the bypass gets an attacker to an endpoint they should never reach, and the injection turns that reach into code execution. Together they are unauthenticated RCE on the appliance.
- It's an internet-facing access gateway. Connect Secure is a VPN/remote-access appliance meant to sit on the perimeter, so it's reachable by design and a foothold on it reaches inward.
- It was live before the fix. The pair was documented under in-the-wild exploitation before patches shipped, so an affected appliance may have been touched during the zero-day window.
How serious we see it
High — in practice, above its 8.2 base score.
The 8.2 reflects the bypass in isolation. In the real world it wasn't used in isolation: it was the opening move of an unauthenticated remote-code-execution chain against an internet-facing security appliance, exploited before a patch existed. We rate it by how it actually gets used. The bounded, reassuring part is that it affects specific products, fixes and mitigations are published, and exposure is quick to determine — but because it was a pre-patch zero-day, being patched and being clean are separate questions.
Recommendations
Straight from Ivanti's advisory and CISA:
- Patch now. Apply the fixed builds from Ivanti's advisory for your Connect Secure / Policy Secure version. If you applied only the interim mitigation earlier, move to the actual patch.
- Hunt for prior compromise. Because it was exploited pre-patch, follow Ivanti's guidance and run the external Integrity Checker Tool; review logs for anomalous access.
- If compromised, respond fully. Rebuild the appliance from a known-good image and rotate all credentials, keys, and certificates it held.
- Harden exposure. Restrict who can reach the gateway; never expose the management interface to the internet.
- Confirm your exposure first. Verify whether you run an affected Connect Secure or Policy Secure build at all.
How BreachRisk sees it
BreachRisk works from the outside in, the way an attacker does. From little more than your domain it discovers internet-facing Ivanti Connect Secure and Policy Secure interfaces, fingerprints the product and version, and flags exposure tied to KEV-listed, actively exploited vulnerabilities like this one — pushed to the top of your results because it's in KEV and because our severity take reflects the chained, real-world impact rather than the 8.2.
That continuous, attacker's-eye view is the point: when an access-gateway zero-day breaks, the exposed appliance is already mapped, so you go straight to patch-and-verify instead of starting an inventory.