#From Recon to Mass Exploitation: Tracking Citrix Netscaler CVE-2026-3055 Across 13 Days of Honeypot Telemetry

Citrix NetScaler CVE-2026-3055 went from vendor disclosure to mass exploitation in under a week. That timeline is compressed but not unusual for critical network appliance vulnerabilities - especially ones that share a vulnerability class with a prior high-profile CVE.

What’s worth documenting is the attacker preparation that preceded widespread exploitation, and how that preparation was visible in honeypot telemetry days before public exploit code existed. With a little bit of intuition and correlation, the upcoming attack signals were observable in the data.

#The Vulnerability

Citrix published security bulletin CTX696300 on March 23rd, 2026, disclosing two vulnerabilities in NetScaler ADC and Gateway:

• CVE-2026-3055 - CVSS 9.3. Out-of-bounds memory read via insufficient input validation in the SAML service provider implementation. Unauthenticated, network-accessible, low attack complexity. Requires the appliance to be configured as a SAML Identity Provider. The vulnerability class - memory overread triggered by crafted authentication payloads - is the same as CitrixBleed (CVE-2023-4966).

• CVE-2026-4368 - Lower severity, patched in the same bulletin.

The SAML IDP prerequisite narrows the attack surface, but not by as much as you’d hope. NetScaler is a highly popular edge device, where deployments frequently serve as identity providers in enterprise SSO configurations, and the appliance’s exposure profile - internet-facing by design - makes it a reliable target. Even with low percentage rate adoption as an IdP, we are talking thousands of targets.

#Preliminary Signal - March 16th

A week before Citrix published CTX696300, our NetScaler honeypots registered a spike in exploitation activity targeting older vulnerabilities.

In a 24-hour period, we observed over 500+ exploit attempts of both CitrixBleed variants - CVE-2025-5777 and CVE-2023-4966 - across multiple deployment regions. The payloads themselves weren’t new, but the exploit quantity was far above baseline.

This kind of resurgence in older exploit activity against a specific vendor’s appliance is a pattern worth watching. It doesn’t guarantee a new vulnerability is inbound - but when attackers are aggressively re-surveying a product’s attack surface, the timing often correlates with either upcoming disclosure or private exploit circulation. In this case, the bulletin dropped seven days later.

#Disclosure - March 23rd

CTX696300 published with both CVEs. The advisory confirmed SAML IDP configuration as a prerequisite for CVE-2026-3055 and provided patching guidance.

At this point, no public exploit code existed. The disclosure was vendor-initiated, and the vulnerability details - while sufficient to guide exploitation for anyone with SAML expertise and appliance access - didn’t include a proof of concept.

The gap between disclosure and public exploit availability is where honeypot telemetry becomes most operationally useful.

#Reconnaissance - March 27th

Four days after disclosure, our honeypots captured two distinct behavioural changes in traffic targeting NetScaler infrastructure.

#Auth Method Fingerprinting

Attackers began probing /cgi/GetAuthMethods on our NetScaler decoys. This endpoint returns the authentication flows enabled on a given appliance - critically, whether it’s configured as a SAML Identity Provider.

The connection to CVE-2026-3055 is direct: the vulnerability only impacts instances where ADC is configured as an IDP. This fingerprinting activity identifies exactly that configuration. It’s target qualification - the attacker is narrowing a broad scan surface to the subset of instances that are actually exploitable.

[FILL: Add volume - how many probes to /cgi/GetAuthMethods, over what time window, from how many distinct IPs. If you have data on whether the same IPs were involved in the Mar 16 CitrixBleed activity, that’s a strong signal worth calling out.]

#ADFS Endpoint Probing

Separately, we observed requests targeting /wsfed/passive - an ADFS-specific endpoint used in federated SSO implementations. At the time, the relevance wasn’t immediately clear.

In hindsight, this was the exploit path. The /wsfed/passive endpoint interacts with the same SAML processing pipeline as /saml/login, and attackers were mapping the appliance’s federated authentication surface to identify the right entry point for payload delivery.

The two behaviours together - enumerating IDP configuration and probing federated auth endpoints - constitute a targeting workflow. This wasn’t scanning; it was preparation for exploitation of a specific vulnerability.

#Exploitation - March 27th (Later)

On the same day as the reconnaissance activity, we captured the first exploit attempts using CVE-2026-3055.

The auth method fingerprinting (POST /cgi/GetAuthMethods) began at 00:19 UTC on March 27th, originating from 45.77.108.53 - a Vultr (AS20473, The Constant Company) instance in the US. The request headers were crafted to mimic a legitimate NetScaler AJAX call: X-Requested-With: XMLHttpRequest, X-Citrix-IsUsingHTTPS: Yes, Sec-Fetch-Mode: cors, Sec-Fetch-Site: same-origin. Whoever built the tooling understood the appliance’s expected request format.

Approximately 12 hours later, at 12:28 UTC, a separate IP - 38.54.88.49, Kaopu Cloud HK Limited (AS138915, JP) - hit /wsfed/passive?test&wctx via GET. The ?test&wctx parameter combination suggests the operator was probing whether the WS-Federation endpoint was live and processing context parameters, consistent with mapping the ADFS/SAML attack surface before sending actual exploit payloads. Different infrastructure, different User-Agent string (Chrome/145 vs Firefox/148 on the earlier probe) - likely a separate actor or a deliberate separation of recon and exploitation tooling.

The shift from enumeration to endpoint probing took under 12 hours. Both requests targeted port 443, both against our Citrix NetScaler decoys.

#Mass Exploitation - March 29th

By March 29th, exploitation was widespread.

Attackers were sending crafted SAMLRequest payloads to /saml/login, omitting the AssertionConsumerServiceURL field to trigger the appliance to leak memory contents via the NSC_TASS cookie. The payload structure matched the watchTowr proof of concept published around the same timeframe.

#The Exploit Request

The exploit is straightforward. A POST to /saml/login with a Content-Type: application/x-www-form-urlencoded body containing a single SAMLRequest parameter. The User-Agent across most of our captures was a Safari/macOS string - likely hardcoded in the tooling rather than reflecting actual client diversity.

The SAMLRequest value is Base64-encoded. Decoded, it’s a minimal SAML AuthnRequest:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_1"
Version="2.0" ProviderName="my provider"
Destination="http://watchtowr/saml.php"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>
  <saml:Issuer>http://watchtowr/saml.php</saml:Issuer>
</samlp:AuthnRequest>

The key detail: there is no AssertionConsumerServiceURL attribute in the request. In a legitimate SAML flow, this attribute tells the IDP where to send the authentication response. When it’s absent, the NetScaler SAML implementation attempts to read the value from memory - and overshoots, returning adjacent heap contents in the NSC_TASS cookie set on the response.

The Destination and Issuer values (http://watchtowr/saml.php) are lifted directly from the watchTowr proof of concept. Most of the payloads we captured used these values verbatim - operators copy-pasting the PoC without modification. The ID field is set to a minimal _1, and ProviderName to a placeholder string. None of these values matter for triggering the vulnerability; the missing AssertionConsumerServiceURL is the only condition.

This is the same vulnerability class as CitrixBleed - a memory overread triggered by malformed authentication input, leaking session material that can be used for session hijacking or credential theft. The difference is the entry point: CitrixBleed used malformed HTTP headers; CVE-2026-3055 uses malformed SAML payloads.

#What To Look For

If you’re running NetScaler ADC or Gateway with SAML IDP configuration, the following log indicators are relevant:

• Requests to /cgi/GetAuthMethods from external IPs (reconnaissance)
• Requests to /wsfed/passive from external IPs (endpoint mapping)
• POST requests to /saml/login containing SAMLRequest payloads (exploitation)
• SAMLRequest XML missing the AssertionConsumerServiceURL attribute (trigger condition)
• Unusual NSC_TASS cookie values in responses (memory leak indicator)

Immediate actions: Patch per CTX696300. If patching is delayed, restrict external access to SAML endpoints. Review access logs for the indicators above - presence of the reconnaissance patterns (GetAuthMethods, wsfed/passive) should be treated as evidence that the appliance was identified as a target, even if no exploit payload followed.

#Network IOCs - Source IPs

IP Address	Organization	ASN	Country
193.24.211.86	Data Campus Limited	AS215929	🇭🇰
173.164.73.25	Comcast Cable Communications	AS7922	🇺🇸
91.92.243.126	Omegatech LTD	AS202412	🇸🇨
194.31.223.238	PLAY2GO INTERNATIONAL LIMITED	AS215439	🇬🇧

Full IOC set available in Defused telemetry.

#Summa Summarum

The sequence documented here - old-CVE resurgence, vendor disclosure, targeted reconnaissance, exploitation - played out over 13 days. The honeypot telemetry captured each phase as it happened.

This showcases the operational value of continuous telemetry against internet-facing infrastructure: the signal exists before its significance is apparent. Whether it gets acted on is a patching and triage decision, not an intelligence gap.

For defenders running NetScaler or similar appliances: the gap between disclosure and exploitation is shrinking. For CVE-2026-3055, it was four days from bulletin to first exploit, six days to mass exploitation. Doable, but exploit timeframes are constantly shrinking and are expected to continue to shrink thanks to advances in AI vulnerability research.

Quality intel and reaction speed will judge your defensive posture in the AI era.

---

Parts of the technical analysis above have been AI-assisted.