CVE-2025-22457: Ivanti Connect Secure, Policy Secure, and ZTA Gateways Stack-Based Buffer Overflow Vulnerability

CVE-2025-22457 is a stack-based buffer overflow in Ivanti Connect Secure, Policy Secure, and ZTA Gateways. A remote unauthenticated attacker can trigger it to achieve remote code execution on the device. These products commonly sit at the network edge as secure remote-access or zero-trust gateways, so successful exploitation can give an attacker a foothold for further movement, data theft, or ransomware deployment. Public reporting confirms known ransomware use of this vulnerability, elevating urgency for any organization running the affected software.

How it works

The flaw is classified as CWE-121, a stack-based buffer overflow. In this class of weakness, the application copies attacker-controlled data into a fixed-size buffer allocated on the stack without sufficient bounds checking. When the input exceeds the buffer capacity, adjacent stack memory—such as return addresses or function pointers—can be overwritten. An unauthenticated remote attacker can send a specially crafted request that overflows the buffer and redirects execution to attacker-chosen code, resulting in full remote code execution on the gateway. Exact request formats, offsets, or payload details are not provided here; defenders must obtain those from the vendor advisory and any accompanying technical analysis. Because the attack requires no prior authentication, any internet-facing instance is a potential target.

Am I affected? How to find it in your systems

Ivanti Connect Secure (formerly Pulse Connect Secure), Policy Secure, and ZTA Gateways are typically deployed as virtual or physical appliances that terminate VPN, SSL, or zero-trust network access sessions. They often appear in DMZs or edge networks and may be managed through a web console or CLI. To inventory:

• Query asset-management, CMDB, or vulnerability-scanning tools for hosts advertising Ivanti, Pulse Secure, or ZTA gateway banners or management ports.
• Review network diagrams and firewall rules for devices that accept inbound HTTPS or VPN traffic from the internet or partner networks.
• Log into each appliance’s administrative interface or use vendor-supplied inventory scripts to record the exact product name and software build; compare those values against the fixed versions listed in the official Ivanti advisory. Specific version ranges are not restated here—confirm them directly from the vendor.

For signs of exploitation, examine appliance logs for anomalous unauthenticated requests, unexpected process crashes or restarts, or outbound connections initiated by the gateway itself. Correlate with network telemetry looking for unusual traffic patterns to or from the management or data-plane interfaces. Because public exploit details may evolve, treat any unexplained crash or privilege-escalation event on these devices as suspicious until proven otherwise.

How to remediate

The primary remediation is to apply the vendor-supplied update that addresses CVE-2025-22457. Download the patch or firmware package only from Ivanti’s official channels, verify its integrity, and follow the documented upgrade procedure for each product (Connect Secure, Policy Secure, ZTA Gateways). After installation, reboot if required and re-validate the running version. CISA’s required action is to apply the mitigations set forth in its instructions; treat the vendor patch as the definitive fix and confirm any additional steps against both the Ivanti advisory and CISA guidance. Once patched, re-enable any temporarily disabled features only after confirming they are no longer vulnerable. As a longer-term control for this weakness class, ensure future configuration reviews include strict input-length validation and memory-safety practices wherever custom code or plugins are present.

If you can't patch immediately

If an immediate upgrade is operationally impossible, apply compensating controls to reduce exposure until the patch can be installed:

• Segment the gateways so that only necessary client subnets can reach the data-plane interfaces; place management interfaces on an isolated network reachable solely from jump hosts.
• Deploy a web-application firewall or IPS signature (virtual patching) that blocks oversized or malformed requests known to target the vulnerable component; keep signatures updated as vendors release them.
• Disable any non-essential features, authentication methods, or administrative interfaces that are not required for production traffic.
• Increase monitoring: forward appliance logs to a SIEM, alert on process crashes, unexpected restarts, or new outbound connections, and retain packet captures of traffic to the gateways for later forensic review.

These measures do not eliminate the vulnerability; they only lower the likelihood of successful exploitation while the permanent fix is scheduled.

If your data may have been exposed

Actively exploited vulnerabilities of this severity frequently lead to full device compromise and subsequent data breaches or ransomware incidents. If you discover evidence of exploitation or cannot rule it out, treat the gateway and any systems reachable from it as potentially compromised: isolate the device, preserve forensic images, rotate credentials, and begin incident-response procedures. As a quick personal check, you can run a free exposure scan of your email address against known breach data sets to see whether credentials or personal information have already appeared in public dumps.