erroneo.us
Search all guides⌘K

Security Digest · Aug 12, 2024 · Vulnerability · Network edge

Ivanti vTM CVE-2024-7593: Admin Auth Bypass, Exploited

Unauthenticated admin creation in Ivanti Virtual Traffic Manager, in KEV. Fixed in 22.2R1 to 22.7R2, now mostly unsupported. Move to 22.9 and audit admins.

Published By erroneo.us Security Desk · Updated 3 min read8 sources

Our verdict

Check exposure

Patched vTM is safe from this bug, but most of the fixed trains are now out of support; find any vTM still unpatched or with an internet-reachable admin interface, move it to 22.9, and check the audit log for exploit-created admins.

Who must act: Anyone running Ivanti vTM 22.2, 22.3, 22.3R2, 22.5R1, 22.6R1 or 22.7R1, and anyone whose vTM admin interface is reachable from untrusted networks.

Who can relax: vTM deployments on 22.9, or on a fixed build with the admin server bound to a private management IP, once the audit log comes back clean.

Affected
vTM 22.2 (before 22.2R1)
vTM 22.3 and 22.3R2
vTM 22.5R1
vTM 22.6R1
vTM 22.7R1
Fixed in
22.2R1 (released Mar 26, 2024)
22.7R2 (released May 20, 2024)
22.3R3, 22.5R2, 22.6R2 (released Aug 19, 2024)
Only 22.9 LTS is still supported (end of support Jul 15, 2028)
CVSS
9.8 (v3.1, NVD)
EPSS
100.0% (percentile 100.0)
CISA KEV
Yes, listed as known exploited
Exploitation
Exploited in the wild
Severity
Critical

What to do

  1. List every vTM instance, including lab and cloud instances, and record its version.
  2. Upgrade anything below 22.2R1, 22.3R3, 22.5R2, 22.6R2 or 22.7R2 now, then plan the move to 22.9 LTS.
  3. Bind the admin server to the management interface IP (System > Security > Management IP Address and Admin Server Port > bindip) and allow only trusted IPs.
  4. Search the audit log for exploit-created admins and compare the admin list with your records.
  5. If you find a rogue admin, rebuild the instance and rotate admin passwords, certificates and backend credentials in its config.

How to check if you are affected or compromised

  • Search vTM audit logs for OPERATION=adduser entries where USER, GROUP, AUTH and IP are all !!ABSENT!!, which Ivanti says marks an account added by the exploit.
  • Compare local administrator accounts with your records and treat any unknown admin as a compromise.
  • Check whether the admin interface has been reachable from the internet since August 2024, for example with an external scan of vTM addresses.

What happened#

On August 12, 2024, Ivanti published an advisory for CVE-2024-7593 in Virtual Traffic Manager (vTM), its software load balancer. An incorrect implementation of an authentication algorithm lets a remote, unauthenticated attacker bypass the admin panel login and create an administrator account. Ivanti scores it CVSS 9.8 (CWE-287, CWE-303), and so does NVD. At disclosure, Ivanti said it knew of no exploited customers but that "a Proof of Concept is publicly available." Its August security update post shipped the fix alongside other products.

Part of the fix was already out. Ivanti says 22.2R1 (March 26, 2024) and 22.7R2 (May 20, 2024) contained it, which is why the CVE record describes every version "other than 22.2R1 or 22.7R2" as affected. Fixes for 22.3, 22.5 and 22.6 followed on August 19, the day Censys counted 97 exposed vTM devices online. CISA added the CVE to KEV on September 24, 2024. As Help Net Security noted, neither CISA nor Ivanti described the attacks. CISA has not said what exploitation prompted the listing.

Who is affected#

Self-managed vTM 22.2 (fixed in 22.2R1), 22.3 and 22.3R2 (fixed in 22.3R3), 22.5R1 (22.5R2), 22.6R1 (22.6R2) and 22.7R1 (22.7R2). The bug is reachable only through the admin interface. Exposure therefore depends on where the admin server listens. Ivanti says customers who bound it to an internal network or private IP "significantly reduced their attack surface."

Do you really need to act?#

If you patched in 2024, this bug is closed. The catch is lifecycle. Ivanti's support schedule gives a release 12 months of support, or 36 for long-term-support (LTS) releases. 22.2r1 LTS reached end of support on January 19, 2026, and 22.8R2 on April 15, 2026. Only 22.9 LTS, supported until July 15, 2028, remains. A box fixed on 22.3R3, 22.5R2, 22.6R2 or 22.7R2 is now on unsupported code and will not get the next fix.

A vTM still below a fixed build, with its admin interface reachable from an untrusted network, is a different matter. The exploit is public and needs no credentials, and it leaves an attacker-controlled admin on the device that routes your production traffic. Treat it as possibly compromised.

What to do now#

  1. Inventory every vTM instance and record its version, including lab and cloud copies.
  2. Upgrade anything below 22.2R1, 22.3R3, 22.5R2, 22.6R2 or 22.7R2 now, then schedule the move to 22.9.
  3. Apply Ivanti's mitigation. Under System > Security, open Management IP Address and Admin Server Port and set bindip to the management interface IP. Use the setting above it to allow only trusted addresses.
  4. Audit administrators and the audit log as described below. Delete unknown accounts and change all admin passwords.
  5. If you find a rogue admin, rebuild from a clean image and rotate the certificates and backend credentials held in the configuration.

How to tell if you were hit#

Ivanti's advisory shows how exploit-created admins look in the audit log output. A legitimate addition records who did it, for example USER=admin GROUP=admin AUTH=local IP=… OPERATION=adduser MODUSER=user1 MODGROUP=admin. An account added by the exploit has those fields empty: USER=!!ABSENT!! GROUP=!!ABSENT!! AUTH=!!ABSENT!! IP=!!ABSENT!! OPERATION=adduser. Export the audit log and run grep -F 'USER=!!ABSENT!!' audit.log | grep adduser, going back to at least August 2024. Then compare the current admin list with your records. Review configuration changes made after any unexplained account appeared.

Timeline#

  • — vTM 22.2R1 ships, already containing the fix.
  • — vTM 22.7R2 ships, also fixed.
  • — Ivanti publishes the advisory and notes a public proof of concept.
  • — 22.3R3, 22.5R2 and 22.6R2 ship. Censys counts 97 exposed vTM devices.
  • — CISA adds CVE-2024-7593 to KEV, with an October 15 federal deadline.
  • — vTM 22.2r1 LTS reaches end of support.
  • — vTM 22.8R2 reaches end of support, leaving 22.9 as the only supported line.

Vulnerability records

  • CVE-2024-7593 · KEV 2024-09-24 · Incorrect implementation of an authentication algorithm in Ivanti vTM other than versions 22.2R1 or 22.7R2 allows a remote unauthenticated attacker to bypass…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

  1. Ivanti — Security Advisory: Ivanti Virtual Traffic Manager (vTM) (CVE-2024-7593) hub.ivanti.com
  2. Ivanti — Product End of Support / End of Engineering Schedule: Ivanti virtual Traffic Manager (vTM) hub.ivanti.com
  3. Ivanti — August 2024 Security Update ivanti.com
  4. CVE record — CVE-2024-7593 cve.org
  5. NVD — CVE-2024-7593 nvd.nist.gov
  6. CISA — Known Exploited Vulnerabilities: CVE-2024-7593 cisa.gov
  7. Censys — Authentication Bypass in Ivanti vTM (CVE-2024-7593) censys.com

Coverage and analysis

  1. Help Net Security — Ivanti vTM auth bypass flaw exploited in attacks, CISA warns helpnetsecurity.com