As self-confessed hoarders of internet “background noise” and connoisseurs of deploying random appliances on the internet to “see what happens”, we can think of little better than watching a vulnerability get exploited in the wild, in real time, against technology that half the internet relies upon.
After the disclosure of any vulnerability affecting edge devices, including the likes of Citrix NetScaler, but really any SSL-VPN, reverse proxy, or managed file transfer solution – we eagerly await what comes next – the shift to indiscriminate in-the-wild exploitation, as everyone with a keyboard and a prompt window comes for them at once.
These latest vulnerabilities are slightly different from the long run of information disclosure bugs (CitrixBleed, et al.) we’ve been getting used to, with Remote Code Execution via log poisoning (in 2026!) being back on the table.
Since disclosure, our global sensor network has watched what has felt like the entire internet target the same appliance at once, with throwaway proof-of-concept one-liner’s out-of-band callbacks, C2 implants, and webshells flowing through our logs.
We want to walk through some of the highlights captured so far, including the good, the bad, the vibe-coded, and frankly… the boring.
It should go without saying, but if you have an internet-facing Citrix NetScaler appliance and haven’t applied the most recent patches, assume compromise – and start triaging, and even if you are fully patched up – review your appliance for signs of historical compromise.
We’ve included Indicators of Compromise to assist defenders in hunting across their environments too.
Vulnerability Overview
In the advisory released by Citrix (CTX697096) on Sunday 27th September, a batch of eight vulnerabilities was addressed. Out of them, the two that were actively exploited in-the-wild as zero-day vulnerabilities were:
- CVE-2026-88771 – An unauthenticated command injection vulnerability, allowing an attacker to issue a single specially crafted request, poison an on-disk log file, and trigger command execution when a scheduled NetScaler job runs.
- CVE-2026-88772 – An unauthenticated memory corruption vulnerability in the DTLS implementation, allowing a remote attacker to establish a DTLS connection, and overflow the fixed-size reassembly buffer to gain code execution.
Both of these were leveraged in targeted intrusions against government and wider enterprise targets across a variety of industry sectors.
What makes CVE-2026-88771 particularly interesting for defenders is that exploitation is inherently disjointed. The malicious request issued by the attacker and eventual code execution are separated. The vulnerability is exploited through a single poisoned log entry in a file, but the detonation only happens when a maintenance job processes it, potentially hours apart.
If you’re interested in a deep dive into the vulnerabilities themselves, check out our Labs blog(s) here:
- https://labs.watchtowr.com/oh-look-the-foot-gun-went-off-again-citrix-netscaler-preauth-command-injection-cve-2026-88771/
- https://labs.watchtowr.com/here-we-go-again-citrix-netscaler-dtls-preauth-memory-overflow-cve-2026-88772/
Timeline
| Event | Date |
|---|---|
| Rumours of Citrix NetScaler zero-days begin to circulate | September 26th, 2026 |
| watchTowr triggers Rapid Reaction response | September 26th, 2026 |
| Citrix advisory CTX697096 published, patches released, CVEs assigned | September 27th, 2026 |
| CVE-2026-88771 added to CISA KEV | September 27th, 2026 |
| First signs of mass, in-the-wild exploitation observed | September 28th, 2026 |
| Escalation in the sophistication of exploits, including C2 implants, webshells, and backdoors | September 29th, 2026 |
| Bulk theft of credentials and secrets observed | September 30th, 2026 |
What is watchTowr Intel observing?
Our sensor network is made up of many real NetScaler appliances, actual boxes that are spread across varied infrastructure, geographies, and masqueraded verticals designed to capture real end-to-end exploitation. Since Citrix published their advisory, those boxes have logged thousands of exploitation attempts against CVE-2026-88771 – every one trying to do something slightly different and all of them effectively competing to get their code to detonate first.
As you’d expect with any newly-disclosed vulnerability, the overwhelming bulk of what we’ve seen is noise. About 85% of all attempts we have observed are extremely simple Out-of-Band (OOB) callbacks designed to run a simple curlcommand, or equivalent, to connect to attacker-controlled infrastructure, trigger a DNS or HTTP callback, prove the appliance is vulnerable, and stop there.
Most of what we’ve seen fits into a few different buckets:
- OOB callbacks, proving the bug fires and nothing more.
- Proof-of-concept exploits that run
idorwhoamiand publish the result into an internet-facing directory, or smuggle it back inside the request itself. - A full C2 implant, staged using popular open-source tooling (Sliver)
- A backdoored SSH binary
- Interactive access, via webshells, reverse shells or remote script loaders
- Smash-and-grab attempts creating backdoor access by spraying SSH keys and webshells in numerous locations, and exfiltrating every possible credential and secret on systems.
- Spraying of publicly released Indicators of Compromise to measure Internet-wide exposure
Across everything we captured, we saw attackers of just about every motivation and level of sophistication. Some were loud and extremely aggressive, sending hundreds of exploit attempts and repeatedly coming back and iterating. Others were quiet and targeted, writing payloads designed to blend in and remain persistent.
As exploitation of CVE-2026-88771 is already well underway, successful exploitation actually becomes non-trivial. An attacker can only plant their command in the log. A scheduled NetScaler cron job related to the Management and Analytics System (MAS) then executes the command at some point over the next 24 hours, meaning attackers are not in control of when their exploit runs.
Worse (for them), only the last and latest entry in the log will detonate. This is due to how ns_monuploadd_err.plgreps the attacker-controlled line [1], keeps only the last entry with tail -1, and carries it over to [2] where it executes. Meaning attackers are genuinely racing with each other to get their exploit to trigger.
Now if someone were to crash the process via a malformed CVE-2026-88772 DTLS requests, or via the new SAML DoS CVE-2026-88779, that’s a different story. Then the process crash would trigger a warm reload upon restart and result in an instant execution for the last poisoned log entry.
Initial Probes
Exploit this vulnerability, make no mistakes.
One day after Citrix’s advisory, we saw “first blood” against our sensors – though “exploitation” would probably be generous for what we captured.
The payload is injected into the NetScaler log file, and runs the id command when the scheduled maintenance job next processes it, writing the output to /var/tmp/wtw888 and stopping there. We watched the same thing play out a few more times, with /var/tmp/cve88771 and /var/tmp/cve88771_round2 a few minutes later. The issue with this payload is that /var/tmp isn’t internet-accessible. The only way to read that file back is to already have access to the appliance, or to leverage another vulnerability.
Our best guess is that this was probably a faithful attempt by an LLM to reproduce the vulnerability from publicly available information and knock together a quick exploit, shipped without review. None of this is particularly dangerous, and it serves as an easy indicator for defenders to hunt for, with anything unusual present in /var/tmp worth a detailed look.
Call me when you get home
As we mentioned, most of the initial traffic that followed were benign probes designed to trigger Out-of-Band callbacks, and made up the largest single category of traffic we’ve observed so far.
Most attempts captured pointed at well-known OOB domains such as oast[.]fun, dnshook[.]site, webhook[.]siteand an endless list of others, including purpose-built lookalike domains such as ctrxsrv[.]com.
Here are just two example attempts we captured:
Everything across simple DNS-based callbacks, exfiltration of command output, creation of files in public directories, evaluation of mathematical expressions and more filled our logs. We could write about these all day with endless examples, but we’ll move on to the more exciting things.
Full Command and Control
As we continued into the days after disclosure, we started to see the sophistication and purpose of exploitation grow and change, with one of the attempts captured skipping the entire “slowly ramping up in sophistication” game, and going for a compiled Sliver C2 implant.
Seeing fetch being used is exciting! A FreeBSD command, and not what most folks used to Linux systems reach for by default. In this instance, it was used to pull down a remote binary, stage it to /var/vpn/ns_helper and execute it. The implant would connect back to the same attacker IP that delivered the exploit on either port 80 or 443 with a hard-coded User-Agent string Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.9565.730 Safari/537.36.
We sinkholed this request, and acquired the staged binary for analysis. It used a basic configuration where it had a 60-second beacon to the operator’s IP address at the following endpoints:
/scripts/bundles/scripts/app.js?m=.../script/bundles/bundles/route.php?n=.../script/scripts?c=.../javascripts/javascripts/javascripts?m=...
Reduce, Reuse, Recycle?
Another interesting choice of tooling we saw was telnet. We encountered a few probes designed to exfiltrate the contents of /etc/passwd, and in a second request, we saw the operator go reaching for .ctxs.receiver, a well-known webshell path documented in other public reporting:
Our current suspicion here is that attackers were on the hunt for working credentials used by the original publicly documented .ctxs.receiver webshell. It contained a redacted password delivered via a CsrfToken cookie, which if obtained can be leveraged without re-exploitation.
We also captured many follow-up attempts like the below carrying the webshell password and attempting to execute the id command, suggesting that they were likely successful elsewhere.
Not everything tried phoning back home
In another instance, we captured an attacker attempting to deploy a backdoor that is not a C2 implant at all, instead opting for a trojanized build of Dropbear SSH 2025.88, compiled statically for FreeBSD so that it carries no library dependencies onto the appliance.
The backdoor allows for two forms of access: a hard-coded backdoor password support1 authenticating any account on the box, and a hard-coded RSA-2048 key that gets accepted before authorized_keys is checked. No changes to existing SSH configurations are made, and instead it runs as an SSH server on tcp/37512.
Although simple and effective, it’s something that is not guaranteed to be a successful backdoor on NetScaler appliances, unless the service is exposed explicitly via the ns.conf config file on Gateway SSLVPN appliances. It will bind that service to the designated port, but it just won’t be externally accessible. We get it, hacking is hard.
She Sells Web Shells
Something a bit more interesting washed up on our edge appliance network shore that we believe deserves a bit more of a walkthrough.
We saw an instance of a Perl stager update_c08937.pl being used to drop a number of different capabilities, including a password-keyed webshell, config exfiltration, persistent admin account, and for what we can only assume to be stylistic reasons, a lovely dark-mode login panel.
The Perl script had a lot going on, so we decided to break it down in sections below with its most interesting traits.
Inside Door access?
The stager’s first act is to mint itself an administrative user, reading the /flash/nsconfig/ns.conf file, stripping out any existing gw_health account, and writing a fresh one with full superuser privileges. The entire contents of the /flash/nsconfig are safely compressed and exfiltrated later on, obviously, for safekeeping.
What was quite interesting here is that the bind system user ... superuser is actually a management-plane account, designed to authenticate via the CLI and management GUI only, and not through the public SSL-VPN / Gateway surface which the attacker originated from.
In the majority of public deployments, quite sensibly, the management interface is never publicly accessible, and so the operator created a perfectly good administrator account for an auth mechanism they can’t necessarily get to.
A webshell dressed in style
The second act of the Perl stager is slightly more interesting, base64-decoding a PHP webshell to a hidden file under the real, internet-accessible NetScaler logon path /var/netscaler/logon/LogonPoint/, and then modifying the appliance’s httpd config to serve it:
For anyone keeping up with other publications on the active exploitation of these vulnerabilities, the behavior in this configuration likely looks suspiciously familiar.
The httpd configuration is used so that any request destined toward paths shaped like /logon/LogonPoint/css/LogonUISimple.html.style.min.<HEX>.css is instead routed toward the webshell, where the support for random hex is a cache-buster to avoid NetScaler caching.
The shell itself
The webshell dropped into .local_journal is a reasonably compact, single-file PHP backdoor with a password of 01ndx0Fk2oK%bCqj that is seeded by the Perl stager in the form of a SHA-256 hash and used to overwrite the static $KEYvalue. On each inbound request, it checks a submitted password against the stored hash, sets a session flag if it matches, and exposes the usual trio of command execution, file upload, and download capabilities.
(Shell intentionally snipped in places for brevity)
Functionally, this is a reasonably standard webshell that we’re quite used to seeing. However, as you’ve seen from the image above, if the shell is accessed without a valid session, it renders a nice login page. This felt like an unnecessary bit of polish, but did make us smile.
And then it all falls apart
In a final crescendo to quite an enjoyable exploration through a reasonably well-formed stager, we saw the superuser written into ns.conf, the httpd config patched, the webshell decoded into place and the service reloaded – and yet it just… didn’t work.
The reason is NetScaler-specific, and due to the webshell’s stateful authentication. When an attacker provides the correct password, the webshell validates it, sets $_SESSION['ok'] and relies on the Set-Cookie: SESSID response header to carry the session forward across webshell requests.
On a NetScaler under the default configuration, any requests to /logon/* are handled by nsppe, which consistently strips the Set-Cookie header before it ever reaches the client, killing the use of the webshell as no session cookies can ever be issued to authenticate it.
Smash and Grab
If we had any thoughts that our previous webshell operator was being too “careful” or “safe” to avoid detection with elegant backdoor placement, this next one is firmly the opposite.
Across our examined window, we kept seeing a single source returning again and again, each time with a larger base64 blob and progressively improving payloads, in what feels like a clear example of an operator iterating in near-real-time and improving their exploit.
In their earliest attempts to poison our log files, each of the injected base64 blobs was designed to plant an attacker-controlled SSH key in as many plausible locations as it could reach, across /root/.ssh/, /nsconfig/ssh, and /nsconfig/.ssh , likely on the assumption that at least one of them would land and survive a reboot.
(The below has been trimmed or decoded where appropriate)
In each returning visit, their payload continued to grow, and in the end we felt they may have got frustrated, and just started spraying webshells and command output into as many directories and files as possible.
While it was pretty crude, it’s a functional way to increase their success rate. After writing as many webshells as possible across 14 directories, the final iteration of their payload searched for every possible secret, key, token, and credential on the box.
This included private keys, Git and cloud credentials, SMTP secrets, bearer tokens, and API keys – and with this being 2026, a dedicated sweep for all things LLM, with OPENAI, ANTHROPIC, GEMINI , and CLAUDE environment variables being checked.
Everything it identified, including harvested secrets, shell history files, credentials, and a full tar of the appliance’s configuration directories was shipped out using three different mechanisms to three locations:
For defenders, it goes without saying that this activity is incredibly loud, and leaves a great number of artifacts behind that can be identified, including authorized_keys entries, multiple webshells, pwn.txt marker files in web-accessible directories, and outbound POST requests of tar archives to any of the above destinations.
Wrapping Up
These were just a handful of the highlights from thousands of exploit attempts we captured over the week following the initial disclosure of the vulnerabilities. We watched the evolution of probes and exploitation volumes grow from attempts at proving the bug works to attackers attempting to perform post-exploitation in various ways. The large volume of exploitation was done by less sophisticated attackers in a blind, and potentially “vibe-driven” way. We saw attack sophistication ramp up aggressively, but NetScaler-specific system knowledge proved to be a hurdle for some. Working with these appliances is no walk in the park, we know.
The bottom line hasn’t moved since the top of this post: if your Citrix NetScaler appliance is internet-facing and unpatched, assume compromise and start hunting. Even if fully patched, these vulnerabilities were originally exploited as zero-days, and you should also assume compromise and review appliances for any anomalous behaviour that suggests prior exploitation.
We are proactively sharing a variety of Indicators of Compromise available in the following repository that can be used to hunt for many of the exploitation attempts shared in this blog, but also some wider indicators that didn’t quite make the cut:
As a final note, given the variety of different exploitation we have observed, make sure where possible to capture as much forensic logs and evidence before devices are restarted, patched, or re-imaged. Any volatile evidence such as running processes, listening sockets, or memory-resident implants will be destroyed.
And that’s it… for now.
Speak soon.
