.png)
4 hours ago
2
On June 17, 2025, Citrix published an advisory detailing CVE-2025-5777 and CVE-2025-5349. Affected products include:
- NetScaler ADC and NetScaler Gateway 14.1 prior to 14.1-43.56
- NetScaler ADC and NetScaler Gateway 13.1 prior to 13.1-58.32
- NetScaler ADC 13.1-FIPS and NDcPP prior to 13.1-37.235-FIPS and NDcPP
- NetScaler ADC 12.1-FIPS prior to 12.1-55.328-FIPS
On June 25, 2025, they also published an advisory detailing CVE-2025-6543. Affected products include:
- NetScaler ADC and NetScaler Gateway 14.1 prior to 14.1-47.46
- NetScaler ADC and NetScaler Gateway 13.1 prior to 13.1-59.19
- NetScaler ADC 13.1-FIPS and NDcPP prior to 13.1-37.236-FIPS and NDcPP
Of the three vulnerabilities, two of them have been receiving a bit of buzz:
- CVE-2025-5777
- The description of this issue has led many to believe that it is a memory disclosure issue similar to CVE-2023-4966 (aka CitrixBleed) and has since been dubbed CitrixBleed 2, though in a blog post, the Citrix Cloud Security Group has claimed that two vulnerabilities are not related.
- Citrix claims that they have not seen evidence of this being exploited in the wild, though other security firms dispute this.
- CVE-2025-6543
- The description of this issue indicates that it is a memory corruption vulnerability that could lead to control flow issues or a denial of service.
- Citrix has stated that they are aware of this issue being exploited in the wild, and CISA has added it to their Known Exploited Vulnerabilities catalog.
While we’ve developed a working exploit for one of these issues… it’s kinda hard to know which is which given the sparse technical details in the advisories. That said, based on the descriptions of the issues, the similarities to CitrixBleed, and the versions of Citrix NetScaler available to us for testing, we believe we’ve developed a working exploit for CVE-2025-5777. It’s also totally possible we’ve stumbled upon some other related issue that was inadvertently patched in these releases.
We’ll skimp on a bunch of internal background information for NetScaler for the sake of brevity, but if you’re interested in reading further, here are a few good write-ups to get you started:
- Bishop Fox’s initial write-up on CVE-2023-4966
- Assetnote’s blog series on CVE-2023-3519
- Assetnote’s additional weaponization of CVE-2023-4966
Long story short, after digging through patch diffs of the nsppe binary (NetScaler Packet Parsing Engine – the module responsible for handling the NetScalar Gateway features, AAA authentication mechanisms, and other such functionality), we stumbled upon some new cleanup sections that zero out buffers and memory regions related to HTTP request data prior to reusing them again – things such as request header length, request body length, and other http request attributes.
This is where we’d normally show a screenshot or snippet of code to illustrate these changes… but given the slight differences among nsppe versions and the sheer size of the binary, we’re opting to demonstrate these changes with a targeted example further downstream in the code flow.
The example we’ve chosen is a login request to the /p/u/doAuthentication.do endpoint. This endpoint accepts requests roughly in the following format:
Typical doAuthentication.do requestResponses will indicate success or failure as you’d normally expect. The important thing to note about this endpoint (and other endpoints affected by this vulnerability) is that regardless of success or failure, the user-supplied login value is reflected in the response.
User-controlled value reflected in responseFor this particular endpoint, the request data is parsed into a structure that is later used to build the response data via the annotated function here:
As mentioned earlier, the majority of diffs in the code indicated lots of clearing of buffers and cleanup. So where does that come into play here? Well, the code path that leads to this particular function only requires the successful parsing of a login form key. It doesn’t care if the associated form values are actually there. So when our param_2 structure gets created, it points to adjacent memory, which is neatly null-terminated for us within the function itself so that we can leak a whole 127 bytes of arbitrary data, which includes the potential for sessions tokens or other sensitive information to be leaked.
doAuthentication.do request with missing form values
Leaked memory
Leaked memoryOk great, a log snippet. Not the most novel thing in the world… but this is much much worse than it initially appears. Take a look at the following video where you’ll see that it’s possible to receive legitimate user session tokens via this vector. In the upper left hand corner we have a browser window simply refreshing the page a bunch of times as a demonstration. The attacker script in the bottom right polls the vulnerable doAuthentication.do repeatedly looking for interesting items, such as strings that match the format of session tokens.
This isn’t just limited to endpoints accessible to normal users. The configuration utilities administrators use to manage Netscaler Gateway endpoints ALSO utilize this memory space, meaning those tokens are vulnerable to theft as well.
In the above, we can see a session token leaked that belongs to the “nsroot” user for the entire Citrix NetScaler ADC instance. Not only that, but we’ve also come across plaintext credentials from legitimate login requests.
Leaked login request body (credentials)Since we don’t have a lot to go on in terms of technical details from the vendor, it’s difficult to recommend good indicators of compromise, though we believe the following is a good starting point:
- Depending on logging configurations, log entries with non-printable characters are a pretty good indicator that something is amiss. For the login endpoint example used in this article, if debug logging is enabled, ns.log may have entries like:
- The Citrix advisory recommends terminating existing ICA and PCoIP sessions, which leads us to believe that endpoints related to those features are being targeted. Entries for those logs may similarly contain contents of leaked memory, which may or may not include session tokens.
- Auditing active sessions is also recommended. As an example, a single session being used from multiple client IP addresses could be an indicator that the session may have been compromised.
- Active sessions for NetScaler Gateway can be found in the WebUI via “NetScaler Gateway -> Active User Sessions -> Select applicable context -> Continue”
- Session information can also be viewed on the command line by running commands such as “show sessions” or “show <service> session”
Multiple Sessions for a single user
GUI locations for monitoring connections and active sessions“test_user” being accessed from multiple IPs around the same time period
Multiple nsroot sessionsIn terms of post-exploitation activities, we assume similar actions from the original CitrixBleed may be taken. These actions include adding backdoor accounts, dumping and modifying the running config with persistence mechanisms, and installing remote access utilities. Each of these actions are captured by many of the default logging mechanisms, though it should be noted that if admin sessions or credentials are compromised, logging configurations could also be modified, which itself is a pretty clear indicator of compromise.
If configuration backups are in place, showing the current running config via show ns runningConfig -withDefaults and comparing it to a known good back up with some sort of diffing utility (such as via diff -u backup.config current.config) is a good starting point.
Addition of a backdoor account in config diffsGiven the long tail that CitrixBleed initially had, here are a few references to previous TTPs, backdoors, and threat actor write-ups:
- https://unit42.paloaltonetworks.com/threat-brief-cve-2023-4966-netscaler-citrix-bleed/
- https://www.cisa.gov/sites/default/files/2023-11/aa23-325a_lockbit_3.0_ransomware_affiliates_exploit_cve-2023-4966_citrix_bleed_vulnerability_0.pdf
- https://cloud.google.com/blog/topics/threat-intelligence/session-hijacking-citrix-cve-2023-4966/
In more recent campaigns regarding other vulnerabilities, threat actors have been observed adding backdoor admin accounts and dumping configurations for edge devices:
- https://www.fortiguard.com/psirt/FG-IR-24-535
- https://www.fortinet.com/blog/psirt-blogs/analysis-of-threat-actor-data-posting
Publishing security advisories for such critical issues with such limited information only serves to hurt defenders and threat hunters in the long term. At best, it causes some minor confusion amongst security experts while triaging the issue. At worst, it leaves organizations scrambling and wondering if they’ve fallen victim to the issue, even after patches have been applied since there’s no way to really know what to look for in their environments.
In cases like this, where multiple vulnerabilities are in play, there isn’t even enough information to be 100% confident about which vulnerability we’ve written an exploit for or if we’ve stumbled across something totally new.
In the absence of actionable details from the vendor, as well as other public analysis, hopefully the indicators of compromise and other information we’ve detailed in this post allow system administrators and incident response to better manage their exposure and triage any suspected compromises. Anticipating possible avenues of attack from other recent threat actor activity regarding edge devices might give additional avenues to pursue for additional IoCs.
Get a NodeZero Demo:
See how NodeZero helps you uncover hidden vulnerabilities before attackers do—schedule a demo.
