One over-long handshake: the Ivanti Connect Secure IF-T stack overflow (CVE-2025-0282)

This piece is about the mechanism, not a working exploit. We name the affected product, Ivanti Connect Secure, and the specific flaw, CVE-2025-0282, because being concrete is the point. We walk through how an over-long field in a handshake becomes a control-flow hijack, why the severity is rated 9.0, and where a defender should be precise about scope. We do not publish exploit code, offsets, or a memory-corruption recipe. The goal is that you can look at your own perimeter and answer one question honestly: is a version of this appliance reachable from the internet that still carries the bug. Verifiable security.

The class in one paragraph

CVE-2025-0282 is a stack-based buffer overflow, one of the oldest and best-understood memory-safety failures there is. The setting is the IF-T/TLS protocol, the mechanism a Connect Secure client uses to negotiate its capabilities with the gateway when it first connects. During that negotiation the appliance parses a client-supplied capabilities field. The vulnerable handler copies that field into a fixed-size buffer that lives on the call stack, without first checking that the incoming value actually fits. Public reverse-engineering of the patched and unpatched builds attributes the overflow to an over-long clientCapabilities value copied into a 256-byte stack buffer with no length validation. When the attacker supplies more bytes than the buffer can hold, the copy runs off the end of the destination and writes over whatever sits next to it in the stack frame, including the saved control data the function depends on to return safely. That is the entire root cause in one sentence: attacker-controlled length, fixed destination, no bounds check.

Two details in that paragraph deserve a flag. First, the 256-byte figure and the specific clientCapabilities field name come from third-party researcher analysis of the binary, not from the vendor advisory. Present them as strong external evidence for the shape of the bug, not as a vendor-confirmed constant. Second, the location matters as much as the mechanism. A buffer overflow buried deep inside an authenticated administrative feature would be serious but bounded. This one sits in the pre-authentication handshake path, the very first conversation the appliance has with anyone who can open a connection to it, which is what turns a memory bug into a pre-auth remote code execution.

How the overflow becomes code execution

A buffer overflow by itself is just a memory-safety violation. Getting from there to a reliable shell is a separate, harder problem, and CVE-2025-0282's CVSS vector records that difficulty explicitly with its AC:H, high attack complexity, rating. Here is the chain at a conceptual level, without the parts that would make it a weapon.

The overflowing copy overwrites adjacent stack state. On the stack, next to a local buffer, sit values the function relies on for correct execution: saved registers and the saved return address that tells the processor where to continue once the current function finishes. Corrupt those, and when the function returns the processor jumps not back to legitimate code but to an address the attacker's bytes now control. That is the transition from data corruption to control-flow hijack. The reason it takes effort, and the reason the vector is AC:H rather than AC:L, is that modern appliances ship with memory-safety mitigations that stand between an overflow and reliable execution: stack canaries that detect the overwrite, address-space layout randomization that hides where useful code lives, and non-executable memory that stops the attacker from simply running bytes they placed on the stack. Converting the overflow into dependable code execution means shaping the payload to work around those defenses, which is exploit-development labor, not a one-line trick. Once that work is done, though, the attacker runs native code in the context of the web and VPN handler that parsed the handshake, on a device with no further authentication in the way.

The path from a single unauthenticated handshake to execution on the boundary. Conceptual and illustrative; offsets and payload construction are deliberately omitted.

Why a VPN appliance is the worst place for this

The CVSS base score is 9.0, and the vector explains why the number is that high despite the high attack complexity: AV:N network reachable, PR:N no privileges required, UI:N no user interaction, S:C scope changed, and C:H/I:H/A:H total loss of confidentiality, integrity, and availability. The scope-changed flag is the one worth dwelling on. It records that a successful exploit does not stay contained within the component that was attacked. That is exactly the story of a perimeter gateway: the appliance sits between the untrusted internet and the trusted internal network, brokering VPN sessions and holding the credentials and session material that make those sessions work. Code execution on that box is not a foothold at the edge of the environment, it is a foothold at the seam the entire environment trusts.

The practical consequences follow directly. An attacker with native execution on the gateway can read and steal credentials and active session tokens as they pass through, giving them authenticated access to the systems behind the VPN without ever cracking a password. They can plant persistence that survives reboots, and in observed campaigns they deployed purpose-built implants for exactly that. Because the appliance is a trusted transit point, traffic it originates toward the internal network draws far less suspicion than traffic from an unknown host. No credential is required to start the chain, and no user has to click anything. Anyone who can open a connection to the gateway can attempt it.

A perimeter VPN is not on the edge of the network, it is the seam the whole network trusts. Code execution there is a foothold at the center, not the periphery.

Be precise about scope

The brand is precision, so be exact about who is affected and who is not. CVE-2025-0282 affects Ivanti Connect Secure before 22.7R2.5, with the vulnerable range spanning 22.7R2 through 22.7R2.4. It also affects Ivanti Policy Secure before 22.7R1.2 and Ivanti Neurons for ZTA gateways before 22.7R2.3. A deployment already on the fixed build, or one where the affected product is not internet-reachable, carries a small fraction of the risk of an exposed, unpatched, pre-auth-reachable gateway. The work for a defender is not to assume every Ivanti box is on fire, it is to determine which specific products, at which specific versions, answer from outside, and to treat those as the active exposure.

One more distinction keeps analysts honest. CVE-2025-0282 is frequently discussed alongside CVE-2025-0283, a separate, lower-severity stack-based overflow in the same product family that was published in the same advisory window. They are different vulnerabilities with different severities, and CVE-2025-0283 is not the one that was seen exploited pre-auth in the wild at disclosure. When you read incident reporting, confirm which identifier a given detail belongs to before you act on it, because remediation urgency differs between the two.

What the intruders did next, and how to spot it

The reason this vulnerability matters beyond its score is that it was not theoretical. Incident responders documented real campaigns that used CVE-2025-0282 as the entry point and then dropped a tooling ecosystem onto the compromised appliances. Public reporting names the SPAWN implant family (SPAWNANT, SPAWNMOLE, and SPAWNSNAIL), along with tooling tracked as PHASEJAM and DRYHOOK, and a later-reported implant named RESURGE. The details vary by actor and campaign, but the objective is consistent: persistence on the appliance and harvesting of the credentials and sessions that flow through it.

That post-exploitation behavior is also where detection lives. Ivanti ships an Integrity Checker Tool (ICT) for exactly this class of appliance tampering, and the guidance is to run it both internally and externally, because a sophisticated implant may attempt to defeat an on-box integrity check. Watch for ICT results that report mismatches or fail unexpectedly, for files on the appliance that should not be there, and for the specific indicators published in the incident reporting linked below. A crucial operational point from that reporting: if an appliance is found compromised, patching alone is not sufficient. The vendor guidance is to perform a factory reset before returning the device to service, so that any implanted persistence is removed rather than merely papered over by a software update.

What to do about it

How Celvex catches this

The uncomfortable lesson of CVE-2025-0282 is that a decades-old bug class, a stack buffer copied without a length check, still lands pre-auth on the exact device an organization trusts most. What we add is not a new vulnerability, and we are skeptical of anyone who claims one without proof. It is the exposure determination for your environment: which gateways are reachable, on which versions, and therefore which carry the catalog's risk right now, delivered as a signed capsule you can verify yourself.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.