If you modify the probe, do not change PROBE_PREFIXES and do not sweep lengths. 575 bytes is load-bearing. Other PrefixList lengths can destabilize an appliance, in at least one case on a build that carries this fix, so a length sweep is not a safe way to explore this bug and shorter is not safer.

How it Works

Patched builds reject an oversized PrefixList cleanly, with a distinctive message. Unpatched builds fall through the parser and return a generic internal error. One identical request, two different answers:

Two routes are tried, IdP first, stopping as soon as one gives an answer. Either is sufficient alone, and together they cover both SAML roles:

The IdP route goes first because it is the more robust of the two. It is insensitive to the Issuer value, to the AssertionConsumerServiceURL, and to clock skew — an IssueInstant well outside the appliance's skew tolerance still discriminates correctly, because canonicalization precedes the time check as well as the signature check.

The route-1 AuthnRequest must be signed. An unsigned one returns 200 Malformed Assertion sent to Netscaler on patched and unpatched builds, which is byte-identical to the patched signal, so a probe that omits the signature block reports every appliance as patched. The signature does not need to be valid, and this tool's is not; it only has to be present, because its SignedInfo is what carries the PrefixList into the canonicalizer.

Behaviour at the fix boundary

Both supported branches change behaviour exactly at their fix build, on both routes:

13.1-63.16 and 63.18 are consecutive releases, so the change is attributable to the patch itself rather than to drift across intervening builds.

Those are the builds where this fix first appeared, and the probe detects exactly that transition. They are no longer the builds to upgrade to: later bulletins have superseded them, so 13.1-63.18 and 14.1-72.61 both answer PATCHED here while remaining exposed to newer issues. See Remediation for the current fixed builds.

Why not fingerprint the build?

Because it cannot work on this bug, even in principle. 13.1-63.16 and 13.1-63.18, the builds immediately either side of the fix, serve byte-identical tmindex.html, base.css and resources.js — the fix touches no web asset. Static asset hashes also collide across branches, so a hash-based approach can resolve a vulnerable appliance to a patched build and report it as clean, which is the worst failure mode a detection tool has. Build fingerprinting is therefore deliberately not implemented. Patch state comes from the probe, or from show ns version where you have credentials.

Requirements

• Python 3.8+, standard library only — no third-party packages.

Usage

Point the tool at the Gateway or AAA virtual server, not the management interface. The precondition is per virtual server, so an appliance with several VIPs needs each one tested.

Options

Examples

An unpatched appliance, answered on the IdP route and confirmed against the control:

The control line is worth reading closely: the 35-byte request clears the size check and is then rejected for its stale IssueInstant, while the 575-byte probe never got that far. That is the ordering the whole method rests on — canonicalization runs before the time check, just as it runs before the signature check.

A patched appliance, the same request against the fix build. Only the probe line differs — the oversized PrefixList is rejected by name instead of falling through to the internal error:

Falling back to the SP route. Here the IdP endpoint is reachable but no IdP policy is bound to this virtual server, so route 1 abstains and route 2 answers. When neither route matches a policy the verdict is INCONCLUSIVE tagged no-policy-match — never PATCHED, which is the whole reason that verdict exists:

The control caught it. Here the endpoint answered with the patched message at both lengths, so the size check was never exercised and the decisive-looking answer is withdrawn. This is the false-positive guard firing, and the reason it fired is stated rather than left to be inferred:

Scanning a fleet (--brief), one aligned line per target ending in the reason tag. Exit status is 1 if any target is VULNERABLE:

Machine-readable output (--json), which records every route attempted. verdict, reason and detail are the authoritative fields; attempts is the raw evidence, so an individual attempt may read patched on a target whose verdict is INCONCLUSIVE:

Verdicts

Every verdict carries a short reason tag naming the condition behind it. --brief prints the tag as its third column, and --json carries it as reason.

All four INCONCLUSIVE reasons mean the same thing for decision-making — unknown, not patched. Confirm with show ns version. The tag exists to tell an operator which condition to fix before re-running: point the probe at a different virtual server, or bind a matching policy.

INCONCLUSIVE exists as a distinct verdict, with its own exit code, because a vulnerable appliance can decline to answer the probe. If the SAML policy bound to a virtual server does not match the probe's request, the appliance short-circuits ahead of the canonicalizer and returns nothing diagnostic. A scanner that merely fails to match goes silent on such a host, and silence reads as "patched". This tool reports it as unknown instead.

Every verdict is confirmed against a control

PATCHED and VULNERABLE both rest on a single distinguishing response, so the tool verifies that the response actually depends on what was sent. After a decisive answer it repeats the request with a short 35-byte PrefixList — below any size check — and the verdict stands only if the two answers differ. If they match, the endpoint replies the same way whatever it receives, the size check was never exercised, and the result is INCONCLUSIVE.

This is not hypothetical. A service provider configured with samlRejectUnsignedAssertion STRICT rejects the probe for a missing signature before canonicalization, and answers with the patched message at every length. Without the control, such an appliance reports PATCHED with exit 0 — observed on a genuinely vulnerable build. It now reports INCONCLUSIVE with the reason tag flat-response, and the run states in as many words that the size check was never exercised. The same control catches the mirror-image case, where an endpoint returns the generic internal error to requests it never parsed.

Recognized non-diagnostic answers

A NetScaler SAML endpoint has a large set of possible replies, and only two of them establish patch state. The tool recognizes 20 of the others and names the condition on the per-route line rather than echoing a response body, for example:

Three of them are length limits — an oversized post body, an oversized RelayState, an over-long extracted username. Those matter most, because they mean the request was rejected by a different length check before reaching the one that distinguishes patch state. That usually means the probe needs to be pointed at a different virtual server, not that the appliance is fine.

One of the 20 shows up on every IdP-route run: the control's message timestamp outside the appliance's skew tolerance. The probe carries a fixed IssueInstant, so a control that clears the size check is then rejected for its age — a property of the probe, not of the appliance. A reply outside the set of 20 is printed as its own first line instead of a named condition.

All of them still produce INCONCLUSIVE, tagged other-saml-error. Recognizing a response never upgrades it to PATCHED: only an explicit patched-build answer does that, and every unrecognized reply falls through to INCONCLUSIVE as well — as unrecognized-reply. The recognition exists to tell an operator why a target could not be classified, not to classify it.

Exit codes

2 is argparse's own exit code for a bad invocation, so the verdict codes skip it. A wrapper script can therefore tell "this appliance could not be classified" (3) from "I called the tool wrong" (2), which a scheme that overloaded 2 could not.

Across a multi-target sweep the code is chosen by priority, not by the worst status: VULNERABLE > INCONCLUSIVE > ERROR > clean. An unreachable host therefore never masks a vulnerable finding in the exit code.

Limitations

• This checks one CVE, not the appliance's patch level. PATCHED and exit code 0 mean the CVE-2026-8452 size check is present on the path the probe reached. They say nothing about any other NetScaler vulnerability, including ones disclosed after this bug and fixed in later builds. Do not read exit 0 from this tool as a clean bill of health for an appliance.
• A non-vulnerable verdict is scoped to the endpoint you probed. The precondition is per virtual server. UNAFFECTED means "not reachable here", not "this appliance is safe".
• Policy matching gates the parser. /saml/login is appliance-wide, but on a virtual server with no IdP policy bound it answers Matching policy not found and short-circuits ahead of the canonicalizer. An IdP whose policy uses an expression rule that the probe's request does not satisfy will land in INCONCLUSIVE rather than give an answer.
• INCONCLUSIVE is not a clean bill of health. It is deliberately distinguished from PATCHED with a separate exit code so that silence is never mistaken for a passing result.
• nFactor deployments with SAML behind a first factor report INCONCLUSIVE. Where the SAML policy sits in a policy label reached by nextFactor rather than bound directly to the virtual server, an unsolicited assertion finds no matching policy and short-circuits ahead of the canonicalizer. Verified on a vulnerable build, which reported INCONCLUSIVE. Since SAML behind a device-posture or login-schema first factor is a common pattern, treat INCONCLUSIVE on an nFactor gateway as "probably reachable, confirm with show ns version", not as a curiosity.
• Not an exploitation check. A VULNERABLE verdict confirms the missing size check, which is the patch state. It does not measure how far an attacker could take the corruption on your build.
• Reachability only. A result reflects what the appliance exposes to the network position you run it from. A WAF in front of the appliance can mask the response.

Remediation

Upgrade to 13.1-63.21 or later, or 14.1-73.32 or later (FIPS and NDcPP: 14.1-73.32 FIPS, or 13.1-37.277 for 13.1-FIPS and 13.1-NDcPP).

The fix for CVE-2026-8452 itself first shipped in 13.1-63.18 / 14.1-72.61 per CTX696604, and that is the transition this tool detects. Those builds have since been superseded by CTX696939 (2026-08-19), which adds CVE-2026-19489 and CVE-2026-19490, the latter a CVSS 9.3 pre-authentication authentication bypass. Its precondition on builds from 14.1-43.56 / 13.1-61.28 onward is a configured SAML action — so an appliance in scope for the bug this tool checks is likely in scope for that one too, and a PATCHED verdict here is not a reason to defer the upgrade. Both bulletins are cleared by the builds above.

Appliances on 12.1 or 13.0 have no fix and will not receive one — those branches are end of life and should be treated as permanently vulnerable and migrated to a supported branch.

Two further notes:

• Patch both nodes of an HA pair. An unpatched secondary is a fully exposed appliance the moment it takes over.

• Scope your inventory by SAML configuration, not by virtual server type. The vendor advisory's wording (Gateway or AAA virtual server) is broader than the trigger condition. Check the running configuration for add authentication samlAction and add authentication samlIdPProfile alongside add authentication vserver and add vpn vserver.

  This is tested, not inferred. On a confirmed-vulnerable appliance we removed every SAML object, bound a non-SAML authentication factor in its place, and left the AAA virtual servers up and serving: the SAML endpoints then returned 404 to every request. They are not merely policy-gated without SAML configuration — they do not exist. So a virtual server with no SAML on it is genuinely out of scope for this bug, and UNAFFECTED on such a target is a real answer rather than a blind spot. The caveat that still applies is the scoping one above: it is per virtual server, so confirm each VIP rather than concluding anything about the appliance.

CVE-2026-8452 shipped alongside five siblings in the same bulletin. The one worth tracking next to it is CVE-2026-8451, a pre-authentication memory overread in the SAML IdP path that has seen active exploitation in the wild. The two share an attack surface, so the same configuration audit covers both.

License

This code is distributed under an MIT license.

Legal Disclaimer

Usage of this tool for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state, and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program.

See Also

• Citrix CTX696604 — NetScaler security bulletin
• Citrix CTX696939 — later NetScaler bulletin superseding those fixed builds
• watchTowr Labs — CVE-2026-8452 technical analysis
• NVD — CVE-2026-8452