Ivanti Connect Secure VPN CVE

Table of Contents

• Module 1: Ivanti Connect Secure and Policy Secure Platform Background
  • About Ivanti’s Product Portfolio
  • Ivanti Connect Secure and Policy Secure Overview
  • History of Vulnerabilities in the Product Line
• Module 2: The Vulnerability Chain — Authentication Bypass and Command Injection
  • CVE-2023-46805: Authentication Bypass
  • CVE-2024-21887: Command Injection
  • Chaining the Flaws into Unauthenticated Remote Code Execution
• Module 3: CVSS Scoring and Affected Versions
  • CVSS Breakdown for CVE-2023-46805
  • CVSS Breakdown for CVE-2024-21887
  • Affected Product Versions
• Module 4: Active Exploitation and Threat Intelligence
  • Threat Actor Attribution
  • Malware Toolkit and Indicators of Compromise
  • Scale of Exploitation in the Wild
• Module 5: Risk Assessment for Affected Organizations
  • Why Edge Appliances Are High-Value Targets
  • Key Risk Assessment Questions
• Module 6: Detection and Forensic Preservation
  • The Built-in Integrity Checker Tool
  • Running the External Integrity Checker Tool
  • Preserving Forensic Artifacts Before Reboot
• Module 7: Remediation and Recovery Workflow
  • Applying the Mitigation XML File
  • Recovery Paths When Compromise Is Confirmed
  • Waiting for the Full Vendor Patch
• Module 8: Ongoing Security Practices and Incident Response Follow-Up
  • Continuous Monitoring Recommendations
  • Post-Incident Review Questions
  • Aligning Security Controls to MITRE ATT&CK
• Summary

Module 1: Ivanti Connect Secure and Policy Secure Platform Background

About Ivanti’s Product Portfolio

Ivanti is a technology vendor that specializes in software to help organizations manage and secure their computer systems and mobile devices. Its portfolio spans a range of solutions intended to keep enterprise networks running smoothly, including:

• Endpoint protection and unified endpoint management
• Mobile device management (the Endpoint Manager Mobile / Avalanche product lines)
• VPN gateways and secure remote-access appliances

The VPN gateway product line — Ivanti Connect Secure and Ivanti Policy Secure — is the subject of this briefing.

Ivanti Connect Secure and Policy Secure Overview

Ivanti Connect Secure (ICS) and Ivanti Policy Secure are VPN appliances and associated client applications used by organizations to provide secure remote access to internal networks. These products are the direct descendants of the legacy Pulse Connect Secure product line, which Ivanti acquired and rebranded.

This vulnerability disclosure is unrelated to a separate set of wide-ranging vulnerabilities disclosed roughly a month earlier in Ivanti’s mobile device management suite, Avalanche. However, the Avalanche disclosure had already drawn increased attention from threat actors toward Ivanti’s broader product offerings, making the VPN appliance line an attractive follow-on target.

History of Vulnerabilities in the Product Line

Looking back at the history of the Pulse Connect Secure / Ivanti Connect Secure product, it has been repeatedly targeted by threat actors over roughly the last five years. This is unsurprising: VPN gateways sit at the network edge, are internet-facing by design, and typically provide a direct path into an organization’s internal network once compromised. The vulnerabilities described in this briefing are the latest chapter in that ongoing pattern, not an isolated incident.

timeline
    title Ivanti / Pulse Secure Targeting Timeline (Context)
    ~5 years prior : Pulse Connect Secure repeatedly targeted by threat actors
    ~1 month before disclosure : Wide-ranging Ivanti Avalanche (MDM) vulnerabilities disclosed
    2023-12 : First observed exploitation of the new ICS/Policy Secure vulnerability chain
    2024-01-10 : Public disclosure of CVE-2023-46805 and CVE-2024-21887
    Weeks after disclosure : Known exploitation count grows well beyond initial estimates

Module 2: The Vulnerability Chain — Authentication Bypass and Command Injection

Two separate vulnerabilities were disclosed together. Individually, neither is especially dangerous — but when chained together as a single exploit, they become significantly more powerful, in the same way that individually unremarkable components can combine into something far more consequential when assembled as a unit.

CVE-2023-46805: Authentication Bypass

CVE-2023-46805 is an authentication bypass vulnerability in the web component of Ivanti Connect Secure. It also affects Ivanti Policy Secure. The flaw allows an attacker to bypass control checks and access restricted resources without valid credentials. It affects all supported versions of Ivanti ICS and Policy Secure in both the 9.x and 22.x release branches.

CVE-2024-21887: Command Injection

CVE-2024-21887 is a command injection vulnerability in the web component of Ivanti Connect Secure and Ivanti Policy Secure. On its own, it can be abused to execute arbitrary commands, but only by an authenticated user (i.e., an attacker who already holds valid administrative session context). As with CVE-2023-46805, this vulnerability affects supported versions of Ivanti ICS and Policy Secure 9.x and 22.x.

Chaining the Flaws into Unauthenticated Remote Code Execution

The two vulnerabilities were not designed to work together, but they compose cleanly: CVE-2023-46805 supplies the missing authentication that CVE-2024-21887 otherwise requires. An attacker who first bypasses authentication (CVE-2023-46805) can then reach the command injection flaw (CVE-2024-21887) as if they were an authenticated administrator, executing arbitrary commands on the appliance. The result is unauthenticated remote code execution (RCE) — full compromise of the appliance without ever needing valid credentials, which can then be leveraged for further compromise of the surrounding network.

flowchart TD
    A[CVE-2023-46805 alone] -->|Bypasses auth checks,<br/>limited to restricted-resource access| A1[Moderate risk on its own]
    B[CVE-2024-21887 alone] -->|Requires an authenticated<br/>admin session| B1[Limited risk without existing access]
    A --> C{Chained together}
    B --> C
    C --> D[Auth bypass supplies the<br/>authenticated context]
    D --> E[Command injection executes<br/>arbitrary commands]
    E --> F[Unauthenticated Remote<br/>Code Execution on the appliance]
    F --> G[Further compromise of the<br/>internal network]

sequenceDiagram
    participant Attacker
    participant WebComp as ICS/Policy Secure Web Component
    participant Appliance as Underlying Appliance OS
    participant Network as Internal Network

    Attacker->>WebComp: Crafted request exploiting<br/>CVE-2023-46805 (auth bypass)
    WebComp-->>Attacker: Access to restricted resources<br/>without valid credentials
    Attacker->>WebComp: Crafted request exploiting<br/>CVE-2024-21887 (command injection)<br/>using the bypassed auth context
    WebComp->>Appliance: Arbitrary command executed
    Appliance-->>Attacker: Remote Code Execution achieved
    Attacker->>Appliance: Deploy web shells / backdoors<br/>for persistence
    Attacker->>Network: Lateral movement and<br/>further network compromise

Module 3: CVSS Scoring and Affected Versions

CVSS Breakdown for CVE-2023-46805

AV:N  - Attack Vector: Network            (exploitable remotely)
AC:L  - Attack Complexity: Low             (no special conditions required)
PR:N  - Privileges Required: None          (fully unauthenticated)
UI:N  - User Interaction: None             (no victim action needed)
S:U   - Scope: Unchanged
C:H   - Confidentiality Impact: High
I:L   - Integrity Impact: Low
A:N   - Availability Impact: None

CVSS Breakdown for CVE-2024-21887

AV:N  - Attack Vector: Network             (exploitable remotely)
AC:L  - Attack Complexity: Low              (no special conditions required)
PR:H  - Privileges Required: High           (authenticated administrator, on its own)
UI:N  - User Interaction: None              (no victim action needed)
S:C   - Scope: Changed
C:H   - Confidentiality Impact: High
I:H   - Integrity Impact: High
A:H   - Availability Impact: High

Note the difference in “Privileges Required”: CVE-2024-21887 alone requires an authenticated administrator (PR:H), which is why its standalone score, while still critical, does not represent an accessible starting point for an outside attacker. It is precisely this “privileges required” barrier that CVE-2023-46805 removes when the two are chained, effectively converting the combined attack path into one that requires no privileges and no user interaction at all.

Both CVEs were added to CISA’s Known Exploited Vulnerabilities (KEV) catalog, reflecting confirmed active exploitation rather than a theoretical risk.

Affected Product Versions

Both vulnerabilities affect all currently supported versions of both products across both major release branches — this is not a narrow, version-specific issue confined to a handful of builds.

Module 4: Active Exploitation and Threat Intelligence

Threat Actor Attribution

These vulnerabilities have been confirmed exploited by multiple threat actors in the wild. The activity has been most prevalently attributed to a group tracked as UTA0178, assessed to be a Chinese nation-state actor. (Note: this activity has also been publicly tracked under other cluster names by different threat intelligence vendors, reflecting parallel independent analysis of the same campaign.)

Malware Toolkit and Indicators of Compromise

At a high level, the indicators of compromise (IOCs) associated with post-exploitation activity include a custom malware kit deployed onto compromised appliances, along with evidence of file modifications and lateral movement within victim networks. The known malware families associated with this campaign are:

Because several of these tools are embedded directly into legitimate appliance files rather than dropped as standalone new files, straightforward file-presence checks are insufficient — this is precisely the kind of tampering the Integrity Checker Tool is designed to catch (see Module 6).

flowchart LR
    A[Initial Access via<br/>Auth Bypass + Command Injection] --> B[THINSPOOL dropper<br/>remounts filesystem read/write]
    B --> C[LIGHTWIRE web shell<br/>written into legitimate file]
    B --> D[WIREFIRE web shell<br/>trojanized into component]
    C --> E[Persistent command<br/>execution channel]
    D --> E
    A --> F[WARPWIRE credential harvester<br/>embedded in login file]
    F --> G[Plaintext credentials<br/>exfiltrated to C2]
    A --> H[ZIPLINE passive backdoor<br/>hijacks network accept function]
    H --> I[Reverse shell / proxy /<br/>tunneling capability]
    E --> J[Lateral movement<br/>within victim network]
    G --> J
    I --> J

Scale of Exploitation in the Wild

As of the time this briefing was originally recorded, researchers had identified up to roughly 1,700 known attacks, with exploitation activity dating back to the December before public disclosure. Given that several weeks had already passed since that initial estimate, the real figure was expected to be materially higher by the time organizations were reviewing this material — a reminder that exploitation counts for actively-exploited edge vulnerabilities tend to be a lower bound, not a final tally.

Module 5: Risk Assessment for Affected Organizations

Why Edge Appliances Are High-Value Targets

Unlike some vulnerabilities that affect services which have “no business” being exposed to the internet, Ivanti Connect Secure and Policy Secure are edge appliances — VPN gateways that are, by design, exposed to the internet directly or indirectly so that remote users can connect. This makes them structurally harder to defend:

• They typically do not run endpoint detection and response (EDR) agents or similar host-based protection, since they are closed appliances rather than general-purpose servers.
• Their entire value proposition depends on being reachable from outside the corporate network.
• This combination — internet exposure plus minimal in-appliance protection — makes edge devices a consistently popular and effective initial-access method for threat actors.

The appliance does include a built-in Integrity Checker Tool that runs automatically (covered in Module 6), but this is a detection mechanism, not a preventive control, and it comes with real operational trade-offs when used for investigation.

flowchart TD
    A[VPN Gateway / Edge Appliance] --> B{Internet-facing<br/>by design?}
    B -->|Yes| C[No EDR / limited<br/>host-based protection]
    C --> D[Attractive initial-access<br/>target for threat actors]
    B -->|No, internal only| E[Reduced exposure,<br/>still requires patching]

Key Risk Assessment Questions

When assessing organizational risk from these two chained CVEs, the following structured questions are useful:

1. Can the vulnerable method be executed in your environment? In this case, yes — both vulnerabilities can be reached and chained to grant a threat actor access and freedom to move throughout the network.
2. What is the application’s priority level? If the workaround/mitigation has not yet been applied, affected organizations should treat this as a high-priority issue and consider pulling exposed devices offline. IOCs have already demonstrated lateral movement and post-exploitation activity in real environments, so the priority level for unmitigated, internet-facing appliances should be treated as urgent.
3. Has forensic evidence already been collected? Because remediation of this specific appliance line requires actions that can destroy volatile evidence (see Module 6), risk assessment and evidence preservation need to happen together, not sequentially.

Module 6: Detection and Forensic Preservation

The Built-in Integrity Checker Tool

Ivanti Connect Secure and Policy Secure appliances include a built-in Integrity Checker Tool (ICT) that runs automatically. Functionally, it does not do much beyond checking whether files on the appliance have changed or whether new files have appeared — it is not a full alerting or remediation system, but it can give administrators an initial signal of possible tampering.

Critically, this is not a simple alert or flag: running the check meaningfully requires rebooting the appliance, and a reboot wipes out the system’s volatile memory. This has a direct forensic consequence: any evidence that only exists in memory (e.g., running processes, active network connections, in-memory artifacts of an in-progress compromise) will be lost the moment the appliance reboots.

Running the External Integrity Checker Tool

In addition to the built-in check, Ivanti also provides an external Integrity Checker Tool that can be run against the appliance. As part of the recommended remediation workflow, organizations should run both the built-in and the external Integrity Checker Tool to look for signs of tampering.

Preserving Forensic Artifacts Before Reboot

Because the built-in check requires a reboot, and because that reboot destroys volatile memory contents, organizations must collect forensic artifacts before triggering any check that involves a reboot. At minimum, this means collecting:

• Log files from the appliance
• Network packet captures, where available
• A full disk/system snapshot of the appliance, if the organization has the technical means to take one

sequenceDiagram
    participant Admin as Security Team
    participant Appliance as ICS / Policy Secure Appliance
    participant Storage as Forensic Evidence Store

    Admin->>Appliance: Collect logs
    Admin->>Appliance: Collect network captures
    Admin->>Appliance: Capture disk/system snapshot (if possible)
    Appliance-->>Storage: Artifacts preserved
    Admin->>Appliance: Run built-in Integrity Checker Tool
    Note over Appliance: Reboot required — volatile memory wiped
    Admin->>Appliance: Run external Integrity Checker Tool
    Appliance-->>Admin: Pass/Fail result

Module 7: Remediation and Recovery Workflow

Applying the Mitigation XML File

Once the built-in and external Integrity Checker Tools have both been run (after evidence collection), the next step depends on the result:

• If both checks pass (no signs of tampering found): apply the mitigation XML file provided by Ivanti. This file does not fix the underlying vulnerability itself, but it prevents the vulnerabilities from being leveraged until the full vendor patch is released.
• Once the mitigation file has been imported, administrators should not update the file or modify the appliance’s configuration afterward, since doing so can reverse the effect of the mitigation. The mitigation must remain in place, untouched, until Ivanti’s full patch is available and applied.

Recovery Paths When Compromise Is Confirmed

• If the checks find issues (evidence of tampering or compromise): the organization moves into recovery mode. This means either:
  • Restoring the appliance from a known-good backup, or
  • In the worst case, performing a full factory reset followed by a complete reconfiguration of the appliance.
• Regardless of which recovery path is used, the mitigation XML file still needs to be applied afterward, since the appliance remains vulnerable to the underlying flaws until the full patch is released.

flowchart TD
    A[Collect logs, packet captures,<br/>and snapshot before any reboot] --> B[Run built-in Integrity<br/>Checker Tool]
    B --> C[Run external Integrity<br/>Checker Tool]
    C --> D{Both checks pass?}
    D -->|Yes| E[Apply mitigation XML file]
    D -->|No, tampering found| F{Good backup available?}
    F -->|Yes| G[Restore from known-good backup]
    F -->|No| H[Factory reset + full reconfiguration]
    G --> E
    H --> E
    E --> I[Do NOT modify config or<br/>the mitigation file afterward]
    I --> J[Wait for and apply the<br/>full vendor patch]

Waiting for the Full Vendor Patch

The mitigation XML file is explicitly a stopgap, not a fix. Organizations must continue monitoring for the release of Ivanti’s full patch for these CVEs and apply it as soon as it becomes available, since the mitigation only prevents exploitation — it does not remove the underlying vulnerabilities from the appliance’s code.

Module 8: Ongoing Security Practices and Incident Response Follow-Up

Continuous Monitoring Recommendations

Regardless of an organization’s current exposure status, a set of evergreen best practices applies:

• Monitor for suspicious traffic on an ongoing basis. Several of the known IOCs for this campaign represent relatively “low-hanging fruit” from a detection standpoint — malware files, unexpected file changes, and log-clearing activity are all comparatively noisy behaviors that defenders can look for.
• Stay current with future advisories related to these CVEs and the affected products.
• Keep systems up to date with the latest patches, especially once Ivanti releases the full patch addressing these specific vulnerabilities.

Post-Incident Review Questions

For teams that responded to this incident (or a similar one), a useful postmortem process includes asking:

1. Were we prepared to deal with these vulnerabilities? Did the team feel it had enough information to make a decision — for example, whether the mitigation needed to be applied?
2. Was the team sufficiently prepared operationally? Did responders have the necessary tools and system access to respond efficiently?
3. Was forensic evidence backed up appropriately before any destructive remediation steps (such as the mandatory reboot for the Integrity Checker Tool) were taken?
4. Were security controls validated afterward? This means deliberately selecting the attack techniques from the MITRE ATT&CK framework that align with these CVEs (or similar vulnerability classes) and confirming that the organization’s security posture and controls are actually effective against those specific techniques.

Aligning Security Controls to MITRE ATT&CK

The recommended follow-up discipline is to use the attacker’s actual techniques as the yardstick for control validation: select the relevant MITRE ATT&CK techniques associated with this exploit chain (initial access via public-facing application exploitation, execution via command injection, persistence via web shell/file trojanization, credential access via harvesting, and lateral movement), and verify that detection and prevention controls are mapped and tested against each of them — rather than relying on general assurances that “security controls are in place.”

mindmap
  root((Post-Incident Review))
    Preparedness
      Sufficient information to decide on mitigation
      Team access and tooling readiness
    Evidence Handling
      Logs collected before reboot
      Packet captures preserved
      Snapshot taken if possible
    Control Validation
      Map to MITRE ATT&CK techniques
        Initial Access - public-facing app exploitation
        Execution - command injection
        Persistence - web shell / trojanized files
        Credential Access - harvesting
        Lateral Movement
      Confirm controls detect/prevent each technique
    Continuous Improvement
      Monitor future advisories
      Apply full vendor patch when released
      Keep monitoring for IOCs

Summary

Two vulnerabilities disclosed together for Ivanti Connect Secure and Ivanti Policy Secure — CVE-2023-46805 (authentication bypass, CVSS 8.2) and CVE-2024-21887 (command injection, CVSS 9.1) — are individually limited but, when chained, allow unauthenticated remote code execution against internet-facing VPN appliances running any supported 9.x or 22.x release. Active exploitation dating back to December, before public disclosure, has been attributed primarily to the nation-state-linked threat actor tracked as UTA0178, using a custom malware toolkit (ZIPLINE, THINSPOOL, LIGHTWIRE, WIREFIRE, WARPWIRE) that trojanizes legitimate appliance files to maintain persistence and steal credentials. Known exploitation had already reached roughly 1,700 confirmed attacks at the time of this briefing, with the real number almost certainly higher.

Because these are edge appliances with minimal host-based protection by design, and because remediation via the built-in Integrity Checker Tool destroys volatile memory on reboot, organizations must collect forensic evidence before running integrity checks, then apply Ivanti’s mitigation XML file (or restore/rebuild first if tampering is found) as an interim safeguard until the full vendor patch is released — and must not modify the appliance configuration or the mitigation file afterward.

Mitigation Checklist

• Identify all internet-facing Ivanti Connect Secure and Ivanti Policy Secure appliances (9.x and 22.x) in the environment.
• Collect logs, network packet captures, and a system/disk snapshot before running any check that requires a reboot.
• Run the built-in Integrity Checker Tool.
• Run the external Integrity Checker Tool.
• If both checks pass, apply Ivanti’s mitigation XML file immediately.
• If tampering is found, restore from a known-good backup or perform a factory reset and reconfiguration, then still apply the mitigation XML file.
• Do not modify the appliance configuration or the mitigation file once applied — doing so can reverse the fix.
• Hunt for known IOCs: ZIPLINE, THINSPOOL, LIGHTWIRE, WIREFIRE, and WARPWIRE artifacts, plus unexpected file changes and log-clearing activity.
• Monitor for and apply Ivanti’s full vendor patch as soon as it becomes available.
• Validate security controls against the MITRE ATT&CK techniques relevant to this exploit chain (public-facing application exploitation, command injection, web-shell persistence, credential harvesting, lateral movement).
• Conduct a post-incident review covering team preparedness, evidence-handling discipline, and control validation.

Search Terms

ivanti · connect · secure · vpn · cve · vulnerability · briefings · networking · systems · security · affected · cvss · product · assessment · authentication · breakdown · bypass · checker · command · compromise · cve-2023-46805 · cve-2024-21887 · exploitation · forensic