Zimbra Collaboration Suite CVE-2026-93631

Exploitation requires a Zimbra Collaboration Suite Network Edition deployment with the OAuth extension and an external provider actually configured - on deployments without a configured provider the flaw is not reachable. The attacker must first obtain a fresh authorization code for their own account at that provider, and the victim must be concurrently signed into Zimbra and induced to load the attacker's crafted OAuth callback (the UI:R user-interaction requirement). The root cause is that the OAuth callback does not bind its state value or authorization code to the initiating Zimbra session and instead selects the destination mailbox from the browser's current authentication cookie. Limiting factors: this is Network Edition only, the external provider must be pre-configured by the administrator, the victim must be authenticated and tricked into loading the callback, and full disclosure of newly created or edited appointments additionally requires bidirectional CalDAV synchronization to be enabled on the linked data source.

This is a genuine but conditional priority rather than a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N, base 7.1) shows a network-reachable, low-complexity flaw requiring no attacker authentication but requiring victim interaction (UI:R), with high confidentiality impact and low integrity impact. The vuln.today decision label is 'this_week', signalling prompt but not emergency remediation. No CISA KEV listing is present and no EPSS score was supplied, so there is no evidence of widespread automated exploitation; the attack is socially-driven (a signed-in victim must load a crafted callback), which points to targeted rather than mass exploitation. The signals are broadly consistent: a medium-high CVSS, a 'this_week' priority, and a credible vendor-independent write-up by Rapid7, with no KEV/EPSS to elevate it further. One nuance to verify: the PR:N rating treats the attacker as unauthenticated, but real-world exploitation also depends on a server-side precondition - the OAuth provider must be configured on the deployment - which the base vector does not capture and which materially narrows the exposed population. EPSS and KEV data are both absent from the input, so exploitation-probability cannot be quantified here.

An attacker registers an account with the external OAuth provider that a target Zimbra Network Edition deployment supports, then obtains a fresh authorization code for that attacker account. The attacker lures a victim who is already signed into Zimbra webmail into loading a crafted OAuth callback URL; because the callback binds to the browser's current auth cookie rather than the initiating session, the attacker's external account is linked to the victim's mailbox. Rapid7 has published a technical research write-up of this technique, though the input does not confirm packaged working exploit code.