What is CVE-2025-22457?
CVE-2025-22457 is a stack‑based buffer overflow discovered in three Ivanti products – Connect Secure, Policy Secure and the Zero Trust Access (ZTA) Gateway. The flaw lets an unauthenticated attacker send specially crafted network traffic that overwrites memory on the device and gains the ability to run arbitrary code. Because the attacker does not need valid credentials, the risk is extremely high.
For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.
Who should be worried?
If you run any of the three products mentioned above in a production environment, you are in scope. The vulnerability exists in every release up to the point where the vendor issued a fix. It does not affect unrelated Ivanti tools, and it does not apply to devices that have already been upgraded to the patched release for their branch.
How does the flaw work?
The vulnerability belongs to the classic class of stack‑based buffer overflows. In simple terms, the software allocates a fixed‑size buffer on the call stack to hold incoming data. An attacker can supply more data than the buffer can hold, causing the excess to spill over into adjacent memory locations. By carefully crafting the overflow, the attacker can overwrite the return address or function pointers, redirecting execution to malicious code that they control.
Because the overflow occurs in code that processes network packets, the attacker can trigger it from anywhere on the Internet that can reach the device’s management interface. The NVD entry confirms that remote code execution is possible without any prior authentication. The exact packet format and the precise memory layout have not been published, so you will not find a public proof‑of‑concept that shows the raw bytes. What matters for you is that the vulnerability has already been weaponised in the wild.
How serious is the problem?
Three factors push this issue into the highest severity band:
- CVSS base score of 9.0 – the vendor and the scoring authority label it as critical.
- Confirmed exploitation – the vulnerability has been observed in active attacks, and CISA added it to its Known Exploited Vulnerabilities catalogue the day after publication.
- Link to ransomware – CISA notes that threat actors have used the flaw as an entry point for ransomware campaigns.
Because an attacker can gain full control of the appliance, they can pivot to the rest of the network, steal credentials, or encrypt data. In short, the impact is “complete compromise”.
How can you tell if you are exposed?
The first step is to verify the exact version of each Ivanti component you are running. The products expose a command‑line interface (CLI) and a web‑based administration console. Use whichever method you prefer, but be consistent.
From the CLI, log in as an administrator and run:
show version
The output will contain a line similar to “Product Version: …”. Compare the string you see with the entries in the table below. If the version string appears in the “affected” column, you are vulnerable.
If you prefer the web UI, navigate to the “System Information” page. The version number is displayed near the top of the page. Again, cross‑reference with the table.
Do not rely on any guesswork – the only reliable way to know is to read the version string directly from the appliance.
Immediate mitigations you can apply today
CISA has published a short list of mitigations that can reduce the attack surface while you arrange for a patch. Apply as many as you can, in the order that makes sense for your environment.
- Restrict inbound management traffic. Limit access to the administration ports (typically 443 and 8443) to a handful of trusted IP addresses. Use firewall rules or ACLs on the perimeter device.
- Enforce strong authentication. Disable any form of anonymous or default login. Require multi‑factor authentication for all admin accounts.
- Deploy a Web Application Firewall (WAF) or Intrusion Prevention System (IPS). Enable signatures that detect malformed packets targeting the vulnerable services.
- Monitor logs for suspicious activity. Look for repeated connection attempts from unknown sources, especially on the management ports. Set up alerts for any “invalid request” or “buffer overflow” messages.
- Segment the appliance. Place the device in a network zone that does not have direct Internet exposure. Only allow traffic that is required for its intended function.
These steps do not eliminate the flaw, but they make it much harder for an attacker to reach the vulnerable code path.
Patch – the definitive fix
The vendor has released a patched release for each product line. The fix removes the unsafe memory handling and adds proper bounds checking. To remediate, you need to upgrade to the patched release for your branch. Follow the standard upgrade procedure supplied by Ivanti – download the update package from the official support portal, verify the checksum, and run the installer or import the package through the web UI.
After the upgrade, repeat the version check described earlier to confirm that the new version appears in the “fixed” column of the table below. Then restart the services or the appliance as instructed by the release notes.
If you cannot patch right away
Sometimes organisations cannot reboot critical infrastructure on short notice. In those cases, combine the mitigations above with additional controls:
- Enable “fail‑closed” mode on any front‑end load balancer – drop traffic that does not match known good patterns.
- Turn on “strict TLS” settings – reject weak cipher suites that could be used to downgrade the connection.
- Schedule a maintenance window within the next 48‑72 hours – the longer the window stays open, the higher the chance of a successful compromise.
Document the temporary measures you have taken, and report the status to your change‑management board. Treat the situation as a high‑priority incident until the patch is applied.
What to do after you have patched
Once the upgrade is complete, run a quick scan with your vulnerability scanner to verify that CVE-2025-22457 no longer appears. Review the audit logs for any signs of attempted exploitation that may have occurred before the patch. If you see evidence of a breach, follow your incident‑response plan – isolate the affected appliance, collect forensic evidence, and notify any relevant stakeholders.
Finally, update your asset inventory to mark the device as “patched”. This will keep future scans from flagging the same issue and helps auditors see that you have addressed the risk.
Reference – version table
The table below is generated automatically from the National Vulnerability Database. It lists the range of versions that are vulnerable and the point at which the fix was introduced. Use it only as a cross‑reference after you have obtained the version string from your own system.
Affected versions
Straight from the NVD record for CVE-2025-22457. If your build is inside one of these ranges, treat it as vulnerable.
| Product | Affected range | Fixed in |
|---|---|---|
connect_secure |
* up to 22.7 | 22.7 |
policy_secure |
* up to 22.7 | 22.7 |
zero_trust_access_gateway |
* up to 22.8 | 22.8 |
