Another NetScaler memory overread: when a SAML IDP hands you the heap

This is a memory-safety bug, not a logic flaw, and the distinction matters for how you respond. The weakness is CWE-125, out-of-bounds read: the code trusts a length or an offset it should have validated, and reads memory it was never meant to touch. The affected builds are NetScaler ADC and NetScaler Gateway 13.1 before 63.18 and 14.1 before 72.61, plus the ADC FIPS builds 13.1 before 37.272 and 14.1 before 72.61, and the NDcPP build 13.1 before 37.272. The fix ships in those builds. The exposure only exists when the appliance is acting as a SAML IDP, which narrows the population but does nothing to soften the impact where it applies. NVD scores it 8.8 under CVSS 4.0 and 7.5 under CVSS 3.1, both in the High band. Verifiable security.

The mechanism: one missing bounds check

An out-of-bounds read is one of the quieter memory bugs, and that is exactly why it earns attention here. There is no crash, no shell, no obvious tampering. The appliance keeps answering requests normally. The only difference is that some of the bytes it returns were never supposed to be in the response. Insufficient input validation in the SAML IDP handler lets an attacker influence how much data the appliance copies into a reply. When the requested length runs past the end of the intended buffer, the copy keeps going into adjacent heap, and that adjacent heap goes out on the wire as part of a legitimate-looking SAML response.

What lands in that adjacent region is not attacker-chosen, which is the read primitive's one mercy and also why it is exploited by volume rather than precision. Each request returns a small, semi-random slice of whatever the process happened to have allocated nearby: parts of other users' requests, buffers holding session state, fragments of authentication material still resident in memory. No single response is a jackpot. But the request is cheap, the appliance is happy to answer it thousands of times, and heap contents churn as other sessions come and go. Reassemble enough slices and you have recovered material that belongs to live sessions you never authenticated to.

The read primitive, conceptually. Length N is trusted where it should be bounded, so the copy walks past the buffer into neighbouring heap. Illustrative, not from any specific host.

Why a SAML identity provider is the worst place for this

A memory leak is bad anywhere. A memory leak in the component that mints and validates federated logins is a session-hijack engine. When NetScaler runs as a SAML IDP, its process memory is exactly where authentication material lives: the tokens it is issuing, the assertions it is signing, the session state for everyone currently logging in through it. The bug leaks from the one memory space richest in the credentials an attacker wants. Recover a valid session artifact and you can replay it directly, arriving as an already-authenticated user and stepping straight past the multi-factor prompt, because the appliance believes that session already cleared it.

This is the same shape as the earlier NetScaler overreads: leak memory, reassemble a session, replay it, skip the login and the second factor. The lineage is no coincidence. These are large, long-lived codebases on the perimeter, parsing untrusted input in privileged network paths, where a single unbounded copy in a request handler is all it takes. On an internet-facing identity broker, a read primitive is not a lesser-severity information leak. It is authentication bypass with extra steps.

A memory leak in the component that mints your logins is not an information leak. It is a session-hijack engine.

How to recognize your exposure

You can assess this without sending anything malicious, because the exposure is set by three readable facts.

1. Is a NetScaler appliance internet-facing? ADC and Gateway are by design public. The question is whether you have one answering from the outside, and where.
2. What build is it running? Version is the highest-signal fact. Fingerprint the build and compare it against the fixed thresholds: 13.1 at or above 63.18, 14.1 at or above 72.61, and the FIPS and NDcPP equivalents. A build below the line, on a public interface, is an active-risk box, not a queued ticket.
3. Is a SAML IDP vServer configured? The vulnerable code path only runs when the appliance acts as a SAML identity provider. Confirm whether that role is enabled; it is the difference between a theoretical build match and a reachable bug.

Why patching alone does not close it

Here is the part teams miss, and the part the prior NetScaler bleeds already taught at cost. Upgrading to the fixed build stops the leak going forward. It does nothing about what already leaked. If an attacker harvested session material before you patched, that material is still valid after you patch, because a session token does not know its issuing appliance was just updated. The upgrade closes the door; it does not evict the person already inside.

So the fix is two moves, not one. First, upgrade to the fixed build. Second, and non-negotiably, terminate every active session on the appliance and rotate any secret that could have been resident in memory during the exposure window: session keys, service credentials, anything the SAML IDP path touched. Post-patch session termination is mandatory for this bug class. An appliance that is patched but still honouring pre-patch sessions is an appliance you have half-fixed.

How Celvex catches this

The reason NetScaler keeps producing these is not mystery. A perimeter identity broker parses untrusted input in privileged paths, and one unbounded copy turns a read into a session-hijack. Treat a memory overread on an authentication appliance as what it is, an authentication bypass in slow motion, and respond the way you would to a stolen credential: patch, then revoke, then rotate. Confirm the build, confirm the responses are bounded, confirm the sessions are dead. Then it is closed.

Find it. Prove it. Fix it. Verify the fix held. That is what we ship.