CVE-2024-7593

What it actually does

CVE-2024-7593 is a critical remote authentication bypass in Ivanti Virtual Traffic Manager caused by an incorrect implementation of the admin-panel authentication algorithm. A network-accessible attacker can reach the administrative interface and be treated as authenticated without valid credentials. Because the interface controls the traffic manager, successful exploitation can provide full administrative control, including reading configuration and secrets, changing traffic-routing behavior, creating or modifying users, deploying malicious configuration, and potentially using built-in administrative functions to achieve further system compromise.

Why it matters to the business

An exposed vulnerable Ivanti Virtual Traffic Manager can be taken over remotely without a password, creating a high risk of service disruption, data exposure, traffic interception, and compromise of applications routed through the appliance. The vulnerability is in CISA KEV, has been exploited in the wild, and has an extremely high EPSS score, so organizations should treat internet-facing or partner-accessible management interfaces as urgent remediation priorities. Although it is not specifically marked by CISA as ransomware-used, compromise of a traffic-management control plane can materially affect availability, incident containment, and trust in routed services.

How an attack unfolds

An attacker first identifies an Ivanti Virtual Traffic Manager administrative interface, commonly exposed on a management port or reachable through a management network. The attacker then sends crafted unauthenticated requests that exploit the faulty authentication logic and obtains administrative access to the vTM admin panel without supplying valid credentials. Once inside, the attacker can enumerate configuration, users, traffic pools, certificates, and application routing policy. Depending on privileges exposed through the interface, the attacker may add accounts or API credentials, alter traffic-handling rules, export sensitive configuration, tamper with virtual servers or pools, deploy malicious traffic scripts, disrupt application delivery, or use the appliance as a foothold for further access. Because exploitation has been observed in the wild and the issue is listed in KEV with a 2024-10-15 remediation due date, exposed instances should be assumed high-risk until patched and reviewed.

How to fix it

Upgrade Ivanti Virtual Traffic Manager to a fixed release immediately. Based on Ivanti’s affected-version statement, versions 22.2R1 and 22.7R2 are not affected by this vulnerability; systems on other vulnerable releases should be upgraded to an appropriate fixed/supported branch. If immediate upgrade is not possible, restrict access to the admin panel to a dedicated management network or VPN, block internet access to administrative ports, enforce network allowlisting, and monitor for unexpected administrative activity. Rotate administrative credentials and API keys after patching if there is any possibility the admin interface was exposed. Review and remove unknown local users, API credentials, traffic scripts, configuration changes, and uploaded files. Because authentication bypass can invalidate trust in prior admin activity, perform a post-remediation configuration integrity review rather than relying only on patch status.

How to confirm the fix worked

Confirm the appliance version reports 22.2R1, 22.7R2, or a later fixed Ivanti-supported release. Verify the administrative interface is not reachable from the internet or untrusted networks by using external scanning and internal segmentation tests. Attempt unauthenticated access to the admin panel and administrative/API functions to ensure authentication is enforced. Review firewall, load balancer, and exposure-management results for open management ports, especially TCP/9090 or any organization-specific management listener. Validate that no unknown administrator accounts, API credentials, traffic scripts, configuration backups, certificates, or routing changes were introduced before or during remediation. Finally, confirm centralized logging is receiving admin/audit events from the vTM appliance so future administrative actions are detectable.

Typical attack path

1. Scan for Ivanti Virtual Traffic Manager administrative interfaces exposed to the internet or reachable from less-trusted networks.
2. Fingerprint the product and version to identify vulnerable releases prior to the corrected 22.2R1 or 22.7R2 branches.
3. Send crafted unauthenticated requests to the admin panel that trigger the authentication-bypass condition.
4. Access administrative functions without valid credentials.
5. Enumerate configuration, local users, certificates, pools, virtual servers, rules, logs, and API settings.
6. Create persistence by adding or modifying administrative users, API credentials, configuration backups, or traffic scripts.
7. Modify traffic routing, intercept or disrupt application traffic, export secrets, or pivot toward systems reachable from the traffic manager.
8. Clean up obvious traces or blend activity into normal administrative actions.

How to detect it

To determine whether exploitation already occurred, collect Ivanti vTM admin/audit logs, web/admin access logs, syslog exports, authentication logs, configuration-change history, backup/export records, and network flow logs for the management interface. Look for successful admin-panel or REST/API activity from unfamiliar source IPs, especially if there is no corresponding normal login event. Hunt for administrative actions shortly after unauthenticated or failed-access attempts, including user creation, role changes, API credential creation, configuration export/import, traffic script edits, pool or virtual-server changes, certificate access, and service restarts. Compare current configuration against a known-good baseline and investigate any unexplained differences. Review external network telemetry for connections to vTM management ports from scanners, hosting providers, anonymization infrastructure, or addresses not used by legitimate administrators. Because public exploitation exists, treat unexplained admin access to exposed instances during the vulnerable period as potentially malicious even if no malware artifact is found.

• TCP/9090
• /apps/zxtm/
• /api/tm/
• /opt/zeus/zxtm/log/
• /opt/zeus/zxtm/conf/
• /opt/zeus/zxtm/conf/users
• /opt/zeus/zxtm/conf/traffic_managers
• /opt/zeus/zxtm/conf/rules
• /opt/zeus/zxtm/conf/pools
• /opt/zeus/zxtm/conf/vservers
• configuration export
• configuration import
• traffic script
• new admin user
• role change
• admin login
• REST API

What your security team should do

• Immediately inventory Ivanti Virtual Traffic Manager instances and identify any running vulnerable versions or exposed admin interfaces.
• Prioritize emergency upgrade for internet-facing, partner-accessible, or broadly reachable management interfaces; this vulnerability is in CISA KEV and exploitation is active in the wild.
• Restrict administrative access to trusted management networks only; block direct internet access to vTM admin services.
• After patching, rotate admin passwords, API credentials, and any secrets that may have been visible through the admin panel if exposure existed.
• Review vTM admin/audit logs for successful administrative actions from unusual IP addresses, user agents, geographies, or times, especially where no normal login sequence is present.
• Inspect configuration for new users, modified roles, changed pools, altered virtual servers, suspicious traffic scripts, certificate exports, or unexpected configuration backups.
• Preserve appliance logs and configuration snapshots before reimaging or major cleanup where compromise is suspected.
• Hunt for follow-on activity against applications routed through the traffic manager, because an attacker with vTM control may have redirected, intercepted, or disrupted traffic.
• Create SIEM alerts for external access to the vTM admin interface, new admin-user creation, privilege changes, configuration export/import, traffic-script changes, and administrative login anomalies.
• If compromise is suspected, engage incident response and consider rebuilding the appliance from a trusted image and known-good configuration rather than only removing visible artifacts.