Ivanti CVE-2025-22457 is being exploited ITW.
https://forums.ivanti.com/s/article/April-Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-22457

Per Mandiant:

We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.

Gee, who could have imagined that attackers are looking at patches? 🤔

1) This apparently was silently fixed for ICS in 22.7R2.6, as the fix for this was released in February. Per Ivanti, the buffer overflow was considered a "product bug" at that time, as opposed to a vulnerability. Ivanti Policy Secure and ZTA gateways are expected to receive a patch in late April.

2) The advisory still conveys the magical thinking if if your device shows signs of compromise, then you should perform a "factory reset." This is magical in that the ICT won't catch a compromise nor will the "factory reset" reset to factory condition if the attacker is bothering to try.

While Mandiant also parrots the magical thinking of running the ICT tool, which I guess is the best advice if you're not going to throw the device in the trash since there isn't an official integrity checking tool that is sound, they do throw out a tidbit of:

... and conduct anomaly detection of client TLS certificates presented to the appliance.

Bets on whether CVE-2025-22457 is an overflow in the handling of a field in a client-provided certificate? 😂

@wdormann Ah yes, the Ivanti "factory reset". 😆

@cR0w

Please ask the device to reset itself to factory state, and believe it when it tells you how it went.

😂

@wdormann Such a serious company that can be taken seriously.

Given that the web server on an ICS runs as the limited nr user, both the Ivanti and the Mandiant advisory are missing any indication whatsoever how the threat actors are gaining root privileges.

I've reported 4 different ICS LPEs to Ivanti recently, but none of them have been fixed yet.

Back in the CVE-2025-0282 days, Ivanti made up a CVE-2025-0283 CVE to capture the LPE aspect of attacks happening in the wild. I say "made up" because I've seen no evidence whatsoever that any LPE was fixed between 22.7R2.5 and 22.7R2.6.

Knowing what's going on in an ICS device is a huge blind spot, but apparently seeing how attackers are LPE'ing is even blind-er.

Now, regarding the "silent fix" of CVE-2025-22457, which per Ivanti:

This vulnerability has been remediated in Ivanti Connect Secure 22.7R2.6 (released February 11, 2025)

That word remediated...

Careful readers will see that Ivanti didn't fix the vulnerability in 22.7R2.6.

What changed in 22.7R2.6? With this version, Ivanti compiled some of the ICS binaries with exploit mitigations that have been around for 20 years. And wouldn't you know it, it paid off already? Everybody's gotta learn sometime...

@wdormann omfg

@wdormann really enjoyed their phrasing of “oh it was just a BUG when we fixed it in February, seems as though it’s suddenly become a VULNERABILITY… oopsie!”

@pejacoby
They seem to have a history of... How do I phrase it... Not embracing the truth? 😂

And per the excellent folks at watchTowr, we can see what the vulnerability is:
A stack buffer overflow in X-Forwarded-For

No need to find a specific endpoint or do something clever. Simply make a web request to anywhere on an ICS system with a large X-Forwarded-For HTTP header and you'll get a stack buffer overflow on the system. 🤦‍♂️

And due to the fact that the Ivanti web server does a fork() without a corresponding exec(), we get the same memory layout every single time.

Now, about Ivanti's use of remediated... The function where the overflow happens just happens to have been rewritten in a way that avoids the overflow.

Did Ivanti recognize the possibility of a stack buffer overflow and not recognize it as a security issue? Or did they just happen to change code to accidentally avoid the overflow (and decide to use exploit mitigations as well).

You decide...

@wdormann so presumably `s` in the vulnerable code is a fixed sized stack buffer, which is getting overflowed due to the input size being constrained only by the return value of strspn? (the linked post didn't seem to explain this either)

@gsuberland
If you look at where exactly the crash happens with a large-enough X-Forwarded-For header, it's when a value is set to -1 after the strlcpy.

Specifically, here in the disassembly.

If you play with the buffer size, you can get the segfault to occur in a few other places, which is what I assume attackers ITW are doing.

@wdormann right, and since edx is loaded from a pointer stored in the stack you at least get a "write -1 where" bug with an address restricted by the specified character list, or probably more if you can make that not crash.

but where is the stack buffer overflow actually occurring? from the limited info in these screenshots (I don't have the firmware), I presume that `s` is a fixed size stack buffer, yes?

@wdormann or v117, I suppose, although if that first call was trashing the stack frame I'd expect the next strlcpy call to blow up

@gsuberland
Yes, s is an array of size 50.

@wdormann so is v193 in the second screenshot also a stack buffer? if so, lmao

@gsuberland
Yes, in the remediated version of the code v193 is a fixed-size array of 3.

@wdormann ahhhh, gotcha. so the stack still gets smashed but the guard protection catches it. what a crap fix lol

@gsuberland
Actually, no.
I've not seen any crash on a 22.7R2.6 system.
I think there's other checks in place to prevent that snippet of code from being reached.

@wdormann oh weird. any signs that they're building with optimisations off and it just didn't eliminate the dead function? (given the quality of the code, it would not surprise me if they ran with -O0 due to UB)

@gsuberland
Eh, I haven't seen any obvious signs that it is -O0.
Is there an easy way to check for this other than looking at lots of functions with my eyeballs? 😂

@wdormann for gcc one tell is if you dig through a few short functions with no locals or outbound calls (sort by function size is an easy method) and find that they all push a stack frame (push ebp; mov ebp, esp) at the start, then it's probably -O0. this is true with -fstack-protector enabled or disabled. as soon as you go to -O1 it'll start eliding the frames when they're unnecessary, absent additional flags to force them.

@gsuberland
Thanks.
No, I see no evidence of -O0 in the web binary using that tell.

@wdormann interesting. who knows what they're up to, then. at least they turned the protections on even if their code is still garbage. good time to go hunting for logic bugs.

@gsuberland
Only took them about 20 years to figure out that exploit mitigations are a good idea. 😂

@buherator
I mean, this would be discoverable with the dumbest of dumb HTTP fuzzing.
You'd need to know absolutely nothing about the target app or what it expects.

@gsuberland
Now that I look with a debugger, we can see that both the vulnerable and the post-remediation versions end up doing a strlcpy (with an attacker-controlled size) to a fixed-size buffer.

With the vulnerable R2.5 version, we can see some immediate evidence of badness (in my case a partial EIP overwrite with the ascii 1 characters we used in our buffer).

However, in the "remediated" R2.6 version, we can still see a fixed-size buffer that is overflowed with the attacker-provided-size buffer. However, in the "remediated" version of ICS, the overflow doesn't seem to result in a crash or other subversion of anything.

🤔

@wdormann is there another large stack buffer in the same frame that's just happening to eat the overflow, leaving the return pointer unclobbered? easiest way to tell would be to dump the full stack contents between ebp and esp just before the function epilogue where the old frame is restored.

@wdormann also if you can make the header value longer without tripping up Requested Entity Too Large or hitting other artificial limitations in the buffer that'd be worth testing

another thought: what happens if you include the same header twice? if global values get broken by the first call through, but then end up not being touched because you're not calling back into the same code, you might be able to break things with a double header trick (not for stack stuff obviously though)