Post cover image

June 11, 2026

CVE-2025–0282: How a One-Line Bug in Ivanti’s VPN Let Attackers Walk Through the Front Door

A balanced breakdown of the root cause, the exploit chain, and what defenders — and pentesters — should take away.

Kalyan Dev

6 min read

The Setup

Your VPN appliance is supposed to be the thing that keeps attackers out. It sits at the edge of your network, terminates remote connections, and decides who gets in. It's trusted by design.

So when it's the thing that gets compromised first, everything behind it is already lost.

That's exactly what happened with CVE-2025–0282 — a critical vulnerability in Ivanti Connect Secure, one of the most widely deployed enterprise VPN solutions in the world. CVSS score: 9.0. No credentials required. Exploited in the wild before a patch even existed.

This article walks through what the bug actually is, how attackers turned it into a full intrusion chain, what it means if you're doing penetration testing, and what defenders need to do about it.

What Is Ivanti Connect Secure?

Ivanti Connect Secure (formerly Pulse Secure) is a VPN gateway product used by large enterprises, government agencies, and critical infrastructure operators worldwide. It provides secure remote access — employees and contractors connect through it to reach internal systems.

Because of its role, it is:

  • Internet-facing by default
  • Trusted by internal network infrastructure
  • Often whitelisted through firewalls
  • Processing connections before any authentication occurs

That last point matters a lot for this vulnerability.

The Bug: One Wrong Variable

The vulnerability lives in /home/bin/web — the binary that handles all incoming HTTP requests and VPN protocol traffic on a Connect Secure appliance.

Specifically, it's in the code that processes IFT (IF-T) protocol connections — the handshake clients use to establish a VPN session.

Here's the relevant decompiled code (sourced from watchTowr's analysis of version 22.7R2.3):

char dest[256];  // fixed 256-byte buffer on the stack
clientCapabilities = getKey(req, "clientCapabilities");
if (clientCapabilities != NULL) {
    clientCapabilitiesLength = strlen(clientCapabilities);
    connInfo->clientCapabilities = clientCapabilities;
}
memset(dest, 0, sizeof(dest));
strncpy(dest, connInfo->clientCapabilities, clientCapabilitiesLength);

See the problem?

strncpy is called with clientCapabilitiesLength — the length of the input string — as the size limit. But the limit is supposed to be the size of the destination buffer (dest), which is 256 bytes.

If an attacker sends a clientCapabilities value longer than 256 bytes, the copy operation happily writes past the end of the buffer — overflowing into other stack variables and, eventually, into the stored return address.

When the function returns, instead of going back to normal program execution, it jumps to wherever the attacker points it.

That's a stack-based buffer overflow. And because this code runs before authentication, the attacker doesn't need valid credentials — or any prior access at all.

Why Was This Hard to Exploit? (And Why Attackers Managed Anyway)

A few things made this more complex than a typical overflow:

No stack canaries. Stack canaries are values placed on the stack before the return address; if they're overwritten, the program crashes before exploitation can succeed. Ivanti's binary didn't use them here, which simplified the attacker's job.

But there's ASLR. Address Space Layout Randomization randomizes where code and libraries are loaded in memory, making it harder to know where to redirect execution. Attackers dealt with this by building a ROP chain (Return-Oriented Programming) — a technique that chains together small snippets of existing code already loaded in memory, bypassing ASLR without needing to inject new shellcode.

The ROP chain was version-specific: the PoC published by Rapid7 targeted Connect Secure 22.7R2.4 specifically. Other versions required independently building a matching chain — raising the bar for exploitation, but not making it impossible.

Nation-state actors (specifically the China-nexus group UNC5337, tracked by Mandiant) had working exploits running in the wild from December 2024, a full month before Ivanti's patch shipped on January 8, 2025.

The Full Attack Chain

Once initial code execution was achieved, attackers didn't stop at a foothold. The post-exploitation chain observed in the wild was methodical:

1. Reconnaissance Attackers queried specific Ivanti endpoints to fingerprint the exact appliance version — often routing through Tor exit nodes or VPS providers to obscure their origin. Version identification was necessary to select the correct ROP chain.

2. Initial exploitation A crafted IFT packet with an oversized clientCapabilities field triggered the overflow. Code executed as the web process user (nr — a non-root account), providing an initial foothold on the appliance.

3. Defense evasion Attackers disabled SELinux and remounted the filesystem as writable. They also killed syslog forwarding — cutting off the appliance's ability to report suspicious activity to external logging infrastructure. The appliance went partially blind.

4. Persistence via PHASEJAM A web shell called PHASEJAM was injected into legitimate Ivanti Connect Secure components. This gave attackers persistent, authenticated access to the appliance that survived reboots and even some remediation attempts.

5. Lateral movement staging Additional payloads — Base64-encoded scripts and ELF binaries — were deployed to use the VPN appliance as a launchpad into the internal network behind it.

The appliance went from "protecting the perimeter" to "hosting the attacker's command and control" in a single exploit chain.

The Penetration Testing Perspective

If you're conducting an external assessment against an enterprise environment, Ivanti appliances are high-value reconnaissance targets.

Version fingerprinting is trivial pre-auth. Certain HTTP requests to Connect Secure return version information before any authentication occurs. On an unpatched engagement, knowing the exact build version is the difference between having a working ROP chain and not.

This falls firmly in the initial access phase. No phishing. No social engineering. No insider access. A network-reachable appliance on a vulnerable build is a direct path to an internal foothold — before you've interacted with a single employee.

Post-exploitation from a VPN appliance is exceptionally powerful. Because these devices are trusted by internal firewalls and routing infrastructure, lateral movement from a compromised gateway is often less noisy and less restricted than movement from a compromised endpoint.

During testing, always check:

  • Ivanti Connect Secure build version (pre-auth fingerprinting)
  • Whether Splunk Web is exposed (ties to the Splunk CVE covered earlier in this series)
  • Exposure of management interfaces that should not be internet-facing

Defender Playbook

Patch. The fixed versions are Connect Secure 22.7R2.5, Policy Secure 22.7R1.2, and Neurons for ZTA gateways 22.7R2.3. If you're below these, you're exposed.

Run Ivanti's Integrity Checker Tool (ICT). Ivanti provides both internal and external ICT scans. Run both. The PHASEJAM web shell was designed to survive superficial remediation — the ICT is the only reliable way to detect it.

If ICT flags compromise: don't just patch. Factory reset the appliance, reinstall patched firmware from scratch, and then restore configuration. Patching a backdoored appliance doesn't remove the backdoor.

Rotate everything. Credentials, API tokens, service account passwords, certificates — anything accessible through or from behind the gateway should be treated as potentially compromised.

Don't trust the appliance's own logs. Attackers killed syslog forwarding as one of their first moves. Forward logs to an external SIEM before you need them. If you weren't doing that, assume the log record for the breach period is incomplete.

Restrict management interface exposure. The Ivanti web management interface should never be accessible from the public internet. If it is, that's the first thing to fix — independently of this CVE.

The Bigger Pattern

CVE-2025–0282 isn't an anomaly. It's part of a clear trend: perimeter devices are now primary targets, not secondary ones.

In 2024 and 2025, critical vulnerabilities in Ivanti, Fortinet, Palo Alto, Cisco, and F5 products repeatedly provided unauthenticated initial access at the network edge. The pattern is consistent: these devices are internet-facing, they're trusted, they're under-monitored, and they often run proprietary operating systems that receive less security scrutiny than mainstream server software.

The attack surface calculus for threat actors is simple. Why invest in a sophisticated phishing campaign with uncertain success rates when a CVE in the VPN appliance gives you pre-auth RCE with near-certainty?

For defenders, the implication is equally clear. Perimeter devices need to be treated with the same — arguably more — scrutiny as internal servers. They need to be included in vulnerability management programs, patched on the same timeline as everything else, and have their logs forwarded somewhere the appliance itself can't tamper with.

A zero-day can happen to any vendor. A month-old known vulnerability sitting unpatched on an internet-facing gateway is a different category of problem.

Summary

CVE CVE-2025–0282 Product Ivanti Connect Secure, Policy Secure, Neurons for ZTA Vulnerability type Stack-based buffer overflow (CWE-121) Root cause strncpy called with source length instead of destination buffer size Auth required None CVSS 9.0 Critical Exploited in wild Yes — December 2024, before patch release Patched January 8, 2025 Fixed versions Connect Secure 22.7R2.5+

References

  • Ivanti Security Advisory: SVD-2025–0102
  • watchTowr Labs technical analysis and exploitation walkthrough
  • Mandiant threat intelligence on UNC5337 campaign
  • CISA Advisory on CVE-2025–0282 active exploitation
  • Rapid7 PoC (CVE-2025–0282, targeting 22.7R2.4)

This article is part of Vulnerability Decoded — a series breaking down real CVEs, real attack chains, and what they mean for practitioners on both sides of the line.

If you found this useful, follow for the next post. Feedback and corrections welcome in the comments.