CVE-2025-0282 – Critical Remote Code Execution in Ivanti Connect Secure, Policy Secure and ZTA Gateways

What is CVE-2025-0282?

CVE-2025-0282 is a stack‑based buffer overflow that lives inside Ivanti Connect Secure, Policy Secure and ZTA Gateways. The flaw lets an unauthenticated attacker send specially crafted network traffic and gain code execution on the appliance. The vulnerability carries a CVSS score of 9.0 – that is, it is classified as Critical.

We keep a daily-updated list of vulnerabilities CISA has confirmed as actively exploited, including remediation deadlines.

The National Vulnerability Database does not publish a list of affected or fixed versions. The table below, which is generated automatically from the NVD, will show you exactly which releases are vulnerable and which contain the fix. Until you can see a patched release for your branch, you should assume the appliance is at risk.

Why should you care?

If you run any of the three Ivanti products mentioned above, you are in the attack surface that the vulnerability targets. CISA has confirmed that the bug is being exploited in the wild and has linked it to ransomware campaigns. That means an attacker who reaches the vulnerable service can drop ransomware payloads onto your network, encrypt data, and demand payment.

The agency’s directive is clear: you must hunt for signs of exploitation, apply any available remediation, and only return the device to production after you have confirmed it is safe.

How does the vulnerability work?

At a high level the problem is a classic stack‑based overflow. The appliance receives data over a network socket, copies it into a fixed‑size buffer, and fails to verify that the incoming payload fits. When the buffer is overrun, the attacker can overwrite the return address on the stack and force the processor to jump to attacker‑controlled code.

The exact function and the precise layout of the overflow have not been released publicly. The NVD description is short, so we can only speak in general terms about the class of bug. What we do know is that the flaw does not require any authentication – anyone who can reach the service can trigger it.

Because the code runs with the privileges of the gateway process, successful exploitation gives the attacker full control of the device. From there they can pivot to other systems, exfiltrate data, or launch ransomware – exactly what the CISA report describes.

Am I affected?

First, confirm that you are running one of the three products. The simplest way is to query the package manager on the appliance. On a Red Hat‑based system run:

rpm -qa | grep -i ivanti

On a Debian‑based system run:

dpkg -l | grep -i ivanti

If you see a package that contains the words “Connect Secure”, “Policy Secure” or “ZTA Gateway”, you have a relevant product installed.

Next, check the version that is currently installed. The command will return a string that includes the version number – do not try to guess whether it is vulnerable. Compare that string to the entries in the table below. If the version you see appears in the “Vulnerable” column, you are exposed.

If the product is not installed, you can ignore this advisory – but keep an eye on any future deployments, because the same flaw will affect new installs until they are patched.

What can I do right now?

There are three immediate actions you should take.

• Hunt for signs of compromise. Look for unexpected processes, new admin accounts, or outbound connections to known ransomware C2 domains. Use your SIEM or EDR to search for the indicator strings that the exploit typically leaves behind – for example, unusual HTTP POSTs to the management port.
• Apply mitigations while you wait for a patch. If you cannot shut the service down, restrict access to the management interface to trusted IP ranges only. A firewall rule such as iptables -A INPUT -p tcp --dport 443 -s /24 -j ACCEPT followed by a drop for everything else will dramatically reduce the attack surface.
• Update to the patched release as soon as it is available. The vendor will publish a security advisory that includes a new build for each product line. Once you have the new package, install it with the normal package manager, then restart the service. The exact command will be something like rpm -Uvh ivanti‑connect‑secure‑patched.rpm or dpkg -i ivanti‑connect‑secure‑patched.deb, but replace the file name with the one you downloaded.

If you cannot apply a patch immediately – perhaps because the appliance sits behind a critical application that cannot be taken down – you should consider taking the device offline until you can update. The risk of leaving it online far outweighs the inconvenience of a short downtime.

What if a patch is not yet released?

When a vendor has not yet provided a fixed build, the only reliable defence is to block the vulnerable service from the internet. Identify the port used for management – typically 443 or 8443 – and create a deny rule for any source address that is not part of your internal network. Example for a Cisco ASA:

access-list OUTSIDE_IN deny tcp any any eq 443
access-list OUTSIDE_IN permit ip any any

In addition, enable any built‑in intrusion‑prevention signatures that look for the overflow pattern. Many next‑generation firewalls already ship with a rule that matches the malformed request used by the exploit.

Finally, start a manual hunt. Pull the latest logs from the appliance, look for HTTP requests with unusually long headers, and flag any source IPs that you do not recognise. Those IPs may already be trying to exploit the bug.

How to verify that you are patched

After you have installed the updated package, repeat the version‑check command from earlier. The string you see should now match an entry in the “Patched” column of the table below. To be extra sure, run the service with the --version flag if the binary supports it, for example:

/opt/ivanti/bin/connectsecure --version

Confirm that the output does not contain any of the vulnerable identifiers listed in the advisory.

What the CISA instructions say

The Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2025-0282 to its Known Exploited Vulnerabilities catalog. Their guidance is three‑fold:

• Conduct hunt activities – look for evidence of exploitation across your environment.
• Take remediation actions if applicable – apply the vendor patch, or apply network‑level mitigations.
• Apply updates before returning the device to service – do not put the appliance back online until you have verified the fix.

Following those steps satisfies the agency’s requirement and reduces the chance that an attacker can use the same technique against you again.

Summary checklist

• Identify whether any Ivanti Connect Secure, Policy Secure or ZTA Gateway appliance is in use.
• Run rpm -qa | grep -i ivanti or dpkg -l | grep -i ivanti to see the installed version.
• Cross‑reference the version with the table below. If it appears in the vulnerable column, you are at risk.
• Search logs for suspicious traffic – long HTTP headers, unknown source IPs, unexpected POSTs.
• Apply network‑level blocks to restrict access to the management interface.
• Install the patched release as soon as the vendor publishes it.
• Verify the new version appears in the patched column and restart the service.
• Document the actions you took and report to your change‑management system.

Version table

The table below is populated automatically from the NVD. It lists every release that is known to be vulnerable and every release that contains the fix. Use it as the definitive source for your environment.

Note: No version numbers are shown here – they will be inserted by the system when the page renders.

The table below

Affected versions

NVD has not published machine-readable version ranges for CVE-2025-0282 yet. Check the vendor advisory for the exact affected and fixed releases before you plan an upgrade.