A five-month Zimbra zero-day shows what happens after an attacker gets inside an authenticated session.
Identity checks like SSO and MFA verify who's logging in, and some can end a session mid-stream if a risk signal changes. None of them judge whether a specific action fits what the session was opened for. A Zimbra webmail zero-day exploited for at least five months shows what happens when nothing does: an attacker who gets inside an already-authenticated session inherits everything that session is trusted to do. The fix isn't a stronger login. It's judgment that keeps running after login is over.
A zero-day that walked past MFA
Zimbra patched a stored cross-site scripting flaw in the Classic Web Client of its Zimbra Collaboration Suite, tracked as CVE-2025-66376. A crafted HTML email abused how the client's sanitizer handled CSS @import rules—hiding an <svg onload> tag inside a display:none div, then breaking it apart with fake @import directives—to smuggle JavaScript past the filter and run it inside a webmail session the victim had already logged into.
Zimbra shipped a fix on November 6, 2025. Proofpoint says the group exploited the bug as an unknown vulnerability for at least five months during 2025, before that fix existed, and it observed activity through February 2026—months after the patch shipped. Attribution is unsettled: the group is tracked as TA488, CL-STA-1114, LAUNDRY BEAR, and Void Blizzard—the reporting itself notes the mapping may not be one-to-one—and Seqrite ties a separate January 2026 case to APT28 at medium confidence, while Dutch intelligence treats the two as separate actors. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on March 18, 2026.
Session hijacking means taking over a session that has already passed identity checks, instead of cracking the login itself—the attacker inherits whatever that session is trusted to do, and no MFA prompt ever fires along the way. The payload, dubbed ZimReaper, is where it gets interesting. It stole CSRF tokens and browser-autofilled passwords—unremarkable session-hijacking behavior. Then it went further: it pulled 2FA scratch codes straight out of Zimbra's own APIs, and minted an app-specific password (named ZimbraWeb) that can grant IMAP, POP3, or SMTP access with no second factor required at all.
The attacker didn't crack MFA. They didn't need to. MFA had already done its job—verifying the human at login—and the session that resulted from that verification was the thing that got compromised. Extracting scratch codes and minting a second-factor-free mailbox credential wasn't the break-in. It was cleanup, performed by an attacker who was already inside, using the account's own trust in itself.
The same shape, a different vector
This isn't a one-off. A related Zimbra flaw, CVE-2025-27915, used stored XSS via ICS calendar attachments in Zimbra 9.0–10.1 to run script inside a live session and set up mail redirects—same sanitizer-gap-to-live-session pattern, different attachment type. And Zimbra's Classic Web Client kept shipping XSS patches through the 10.1.20 release in July 2026, which fixed four more XSS flaws in that client—the underlying bug class is recurring in this product line, not resolved.
A separate 2026 malware family shows the same structural move from a different angle. ChonkyChicken, a second-stage implant from the Golden Chickens (TAG-195 / Venom Spider) malware-as-a-service operation, launches a browser out of view with remote debugging enabled, then drives the already-authenticated session, using a companion tool that bypasses Chrome's App-Bound Encryption. The result is interactive control of an already-authenticated browser session—control that a password reset alone may not remove, because the attacker was never authenticating as the user in the first place. They were riding a session the user had already authenticated: servers treat a stolen session token as valid proof of identity, so no MFA prompt fires.
Identity answers who's there, not what runs next
Zimbra and ChonkyChicken are webmail and browser incidents, not infrastructure-shell incidents. But the structural gap they expose isn't specific to email clients or browsers—it's a property of identity checks generally. SSO and MFA verify who is logging in. Identity platforms can now re-evaluate a live session mid-token-lifetime—Microsoft Entra's continuous access evaluation does exactly that, ending a session if a risk signal changes.
The Cloud Security Alliance's agentjacking research names the same failure mode one level up, for AI agents rather than human sessions: an agent performs authorized actions under the developer's identity, so most conventional endpoint and network controls aren't designed to address this attack class—the operations all look authorized. The session was authenticated. Everything downstream inherits that authentication by default.
This is the reason execution control exists as a layer distinct from identity: a policy layer decides what an identity is allowed to touch, and a separate layer has to keep judging what actually runs, for as long as the session is open. PAM shells already filter commands—against static allowlists and denylists. What a rule list can't express is whether a command fits what the session said it was for.
What this means for an AI agent's session
Translate the pattern to an AI agent working inside a production environment instead of a webmail inbox. The agent's credentials checked out. Its scope was granted. That clean start is exactly what an attacker inherits by hijacking or injecting into the session—every action afterward is authorized under credentials that already passed, the same way ZimReaper inherited a webmail session's trust and ChonkyChicken inherited a browser's. Continuous access evaluation can still cut the session off if a risk signal changes; what no identity check decides is whether this particular action belongs to what the session was opened for.
For an agent, Alpacon's execution-control layer keeps judgment running inside the session, not just at its start: dynamic permissions define what an agent can execute within a given session, and the commands it runs through Alpacon's command API or MCP are scored against the purpose the session declared. A command whose risk score lands in the uncertain middle can be held for out-of-band human approval before it runs.
The takeaway
SSO and MFA are necessary. They are not sufficient, and the past year of session-hijacking incidents makes that gap concrete rather than theoretical: a five-month zero-day, scratch codes pulled through an app's own APIs, an app-specific password minted after the fact that skips MFA entirely, an already-authenticated browser session taken over through its own remote-debugging interface. None of it required beating identity verification. All of it required an attacker getting inside a session identity verification had already cleared.
If your security model treats "the user authenticated" as the end of the question rather than the start of a longer one, that's the gap worth closing next.
