how it happened
- whoattackerszero-day CVE-2023-4966
- the gapsession tokensskip password and MFA
- thenpatched, not killedstolen sessions stayed valid
- the resultBoeing, ICBC, DP Worldamong the victims
what everyone assumed
Patching is how you end an exposure. You install the fix, the hole closes, and the door the attacker was using is gone. For most vulnerabilities that is exactly true, which is why “we patched it” is the standard way to mark an incident resolved.
what happened
CVE-2023-4966 let an unauthenticated request read memory from the appliance, and in that memory were valid session tokens for authenticated users. A stolen token is a live session: it carries the user past login and past MFA without either. Applying the patch stopped new tokens from leaking, but it did nothing to the tokens already taken. Those sessions stayed valid until they were explicitly killed, and a reboot did not kill them. In the window between patching and terminating sessions, a patched appliance and an exposed one looked the same from the inside.
step by step
- a flaw leaks appliance memoryAn unauthenticated request can read live session tokens.
- stolen tokens skip login and MFAUsed for access at Boeing's distribution business, ICBC, DP World and others.
- teams patch and think they are doneThe patch stops new leaks; sessions already taken stay valid, even after a reboot.the assumption breaks here
- CISA and the FBI: patching is not enoughAll active and persistent sessions have to be killed.
how it surfaced
The flaw was exploited as a zero-day before the fix existed, and it was used for initial access against Boeing’s distribution business, the Industrial and Commercial Bank of China, and DP World, among others. CISA and the FBI issued joint guidance stating plainly that patching alone was not enough and that all active and persistent sessions had to be terminated. The vulnerability scored 9.4. The lesson scored higher.
A patch closes the way in, it does not evict whoever already came through.
When the prize is a live session, the session has to be ended deliberately, because it does not expire just because the hole it came from is gone.
picture it at a company like yours
The company here is made up. The other two paths are not: they happened, and each links to the story.
- in this storythe day it mattersAn attacker reuses a stolen session and skips the password and the code.what it costs youThe patch was applied. The door was still open, because nobody ended the old sessions.
- or it goes like thisit happenedReddit, 2023howA fake login page passes the password and code to the real site as they are typed.what leavesinternal documents, code and dashboardswho ends up with itthe attacker behind the page
- or it goes like thisit happenedUber, 2022howLogin prompts keep coming until a tired employee taps approve.what leavesadmin tools and company chatwho ends up with itan attacker who bought a contractor's password
sources
your turn
what you can do about it
this week
For any session-bearing system you patched under pressure, check whether the remediation step also forced existing sessions to re-authenticate, or whether it stopped at the version number.
Think about the last urgent patch your team applied to anything that holds user sessions, a VPN, a gateway, an SSO appliance. The version was confirmed, the ticket was closed. With CitrixBleed, the difference between those two was the whole incident.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →
