What happened
Citrix disclosed CVE-2023-4966 on 10 October 2023, a vulnerability later nicknamed Citrix Bleed. The National Vulnerability Database entry describes it as a sensitive-information disclosure affecting NetScaler ADC and NetScaler Gateway when configured as a gateway or an AAA virtual server, and records a critical severity rating from the vendor. A joint advisory published on 21 November 2023 explains the practical effect: sending crafted HTTP requests with malformed host headers could extract valid NetScaler session cookies from an appliance's memory, letting an attacker hijack a legitimate user's session and bypass password and multi-factor authentication requirements entirely, because the attacker was never asked for either. The advisory said LockBit 3.0 ransomware affiliates were actively exploiting the flaw, with activity identified as early as August 2023, weeks before the public disclosure.
Because the attack extracts a working session rather than a password, a session obtained before an appliance was patched does not automatically stop working once the patch is applied. The advisory's recommendations reflect that gap: beyond applying Citrix's patches, it calls for isolating vulnerable appliances until they can be updated, and rotating credentials for any identities that were provisioned to access an affected appliance, rather than treating the patch alone as sufficient remediation.
Confidence and limits
The vulnerability's mechanism and severity are established by the NVD record and the joint advisory. The attribution to LockBit 3.0 affiliates is the advisory's own assessment; the underlying vendor bulletin from Citrix could not be retrieved for this record because its support portal did not render outside a browser session, so any additional vendor-specific guidance beyond what the advisory describes is not reflected here.
Why it mattered
The case illustrates a distinction that a simple patch-compliance report can miss: a system can be fully patched and still be actively compromised, because the compromise lives in a session token issued before the patch, not in the code the patch replaces. Organisations that treated the update as the end of their response, without checking for signs of prior exploitation, could have left an active intrusion in place.
Defensive takeaway
After patching an appliance affected by a session-hijacking flaw, terminate all existing sessions and rotate credentials for accounts that had access through it, and check your logs for the affected window before assuming the patch alone resolved the exposure.
- When you patch a vulnerability described as session hijacking or token theft, does your process include ending existing sessions, not only installing the update?
- Do you retain logs from your remote-access appliances covering the weeks before a public disclosure, in case exploitation began earlier than the advisory date?
- Are credentials and API keys ever rotated after a security incident affecting the systems that provisioned them, or only after a confirmed compromise of the credential itself?
A patch closes the door a vulnerability opened, but it does not, by itself, evict anyone who is already inside, and Citrix Bleed is a concrete illustration of why those two steps need to be treated separately.