How attackers are hijacking Citrix sessions with a single weird HTTP request (a.k.a. “CitrixBleed 2”)
This week, we're exploring the latest exploitation technique attackers are using to takeover active Citrix sessions. Interestingly this involves no user clicks!
Imagine being able to hack into a company’s entire internal network, not by breaking passwords, not by phishing employees, not by deploying malware but simply by sending a bizarre, incomplete HTTP request.
Sounds almost absurd, right?
Yet that’s exactly what attackers are doing right now, in what’s quickly becoming one of the most dangerous exploitation scenarios of 2025.
Welcome to the “CitrixBleed 2.”
🐛 The mindset of an attacker
When attackers go hunting for bugs, they’re rarely looking for tiny vulnerabilities that compromise just one laptop.
They’re after the golden bugs — single points of failure that, if broken, open the doors to hundreds or thousands of systems.
In other words:
🔍 “One compromise to rule them all.”
A remote gateway is a textbook example of such a target.
🌐 Why remote gateways are so critical
Most companies today let employees work from anywhere.
That means internal apps, intranets, financial dashboards, code repositories — all must be accessible over the internet.
To secure this, organizations use remote gateways, like Citrix NetScaler Gateway, which act as the front door:
Employees visit a URL (e.g.
vpn.company.com),Enter credentials,
And the gateway brokers secure connections to internal apps.
But here’s the catch:
If you break into the gateway, you don’t just get one account.
You potentially get them all.
This is why attackers flock to vulnerabilities in products like Citrix, Pulse Secure, Fortinet, and other remote access solutions.
🔥 The CitrixBleed 2 exploit: a step-by-step attack flow
Let’s break down how attackers are exploiting the latest Citrix NetScaler bug, using incredibly simple HTTP requests.
Attacker identifies internet facing Citrix Gateway login page (using Shodan).
Attacker enters random username & password > Intercepts the POST request > POST parameters look something like this:
POST /login
…
login=rohit&passwd=testpass
…Here's the interesting part: Attacker now sends the request to include just 'login' parameter with no value:
POST /login
…
login
…And guess what? In a weird twist, the server starts leaking random info from memory (see pic for clarity, credits: watchtowr).
Now attacker sends the same request again > And server leaks new info from memory.
The attacker repeats this dozens of times harvesting new random bits of memory > Eventually, server leaks session IDs, tokens etc. > Attacker replays them > Compromises any user!
💡Key Insights & Lessons
What's happening here is this: The backend code takes the value of 'login' parameter and assigns it to a local variable and displays it back. But there is a problem: the local variable is not initialized. So, when you don't assign any value at all for 'login', it just displays whatever value existed in that memory space from before! This is a classic memory leak issue in C-language.
When hunting for bugs, attackers look for one thing above all: a single bug that can lead to thousands of compromises. A remote gateway is perfect for this. It serves as the front door for thousands of employees to access internal apps. Break it, and you do not just get one account, you could get them all.
The attacker had a simple question: "What if we just provide the login parameter, but don’t provide the equal sign or a value (expected by the HTTP spec) to try and trigger parsing issues? What happens then?". If you're a security analyst, realizing the power of "what if" can immensely benefit you in uncovering these less obvious bugs.
Uninitialized variables often expose invisible state. Developers might think an empty variable is harmless, but in languages like C, it could hold arbitrary leftover data from previous operations. That’s why attackers love probing with incomplete or malformed inputs. They can accidentally reveal data that was never meant to leave memory.
Memory leaks reveal far more than just passwords. What leaks out isn’t limited to credentials. It could be encryption keys, session cookies, database queries, or even parts of other users’ transactions. This turns a simple coding oversight into a full-blown data breach that attackers can keep mining with repeated requests.
History has a way of repeating itself in cybersecurity. In 2023, Citrix faced a similar memory leak zero day that caused widespread damage, known as Citrix Bleed. Now, this new CVE with a CVSS score of 9.3 is published this week, and reports show Citrix Bleed 2 is already being heavily exploited.
How to defend? 1) Apply the patches released by Citrix 2) Audit external NetScaler exposure 3) Implement n/w ACLs if patching is delayed. 4) After patching, terminate all active sessions.