Zimbra published a set of advisories in late September and early October 2026 that share one property: the attacker does not need a mailbox on the target server to start the attack.
CVE-2026-93641, CVE-2026-93642 and CVE-2026-93647 are each rated 9.3. CVE-2026-10631 is rated 6.5. All four are classified as XSS or authorization problems in the NVD records, and the first three share a CVSS vector that reads AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N: network-reachable, no privileges, user interaction required, scope changed.

What the three critical issues do

CVE-2026-93641 covers the Zimbra Classic web client. An unauthenticated sender forges a share notification. When a signed-in recipient clicks Accept Share, stored markup executes in the context of the mailbox session, giving the attacker mailbox access and the ability to act as the victim.
CVE-2026-93642 describes the same flow against the Modern web client. Two separate CVEs exist because the two clients render the notification through different code.
CVE-2026-93647 leaves the sharing UI entirely. An unauthenticated calendar sender places active markup in the From address of a COUNTER message. Opening the message in Zimbra Classic is enough.
The trigger in all three is a user action that the product encourages: accepting a share, opening a calendar reply. Nothing in the flow requires the recipient to do anything unusual.

The authorization defect underneath

CVE-2026-10631 is a different class and worth separating. It describes an authorization bypass in the EWS FindItem handler affecting Zimbra Collaboration Suite 10.1.0 through 10.1.19. An authenticated user with EWS enabled can read complete mailbox items, including raw MIME and attachments, from arbitrary local accounts without a share or delegation grant.
No user interaction, no forged notification. The attacker needs an account on the same server and EWS access, and then reads other accounts' mail.
Read together with the three XSS issues, the pair describes a two-step risk. Getting an account on a Zimbra server is often possible through normal provisioning; getting a mailbox session in someone else's account through the XSS chain is not.

Why sharing notifications are structurally hard

A share notification is a message from an external party that the client renders with product-specific formatting and an actionable button. That design puts attacker-controlled content into a privileged rendering context, which is the definition of a stored XSS precondition.
The clients add a second complication. Zimbra maintains two web clients, Classic and Modern, with separate rendering paths. A fix in one does not imply a fix in the other, and this batch demonstrates that with two advisories for what an operator would call one feature.
Calendar is the third complication. A COUNTER message's From address is calendar protocol data, and the client's rendering of it sits outside the mail-reading path that most XSS testing targets.

What to do before and after patching

Check the version against the vendor's advisory page. Zimbra's security advisory wiki lists fixed versions per branch, and the affected range for the EWS issue, 10.1.0 through 10.1.19, is a specific number that can be matched against the installed build.
Review the EWS exposure separately. The EWS endpoint is frequently internet-facing because mobile clients use it. If the deployment does not need external EWS, restricting it to a VPN or a known address range removes the CVE-2026-10631 precondition entirely, independently of patch timing.
Look at what the two client paths mean for your users. If both Classic and Modern are enabled, both fixes are required. A deployment that patched one client and left the other on a vulnerable build has closed half the exposure and would report it as complete.
Consider disabling link and HTML rendering for external senders in calendar replies, where the client allows it. This is a mitigation, not a fix, and it changes user behaviour; it belongs in a change record with an owner and an end date.

Detection is thin, which is the difficult part

The XSS issues execute in a mailbox session, and the evidence they leave is in the victim's browser. Server-side logs show the notification delivery and the share acceptance, not the payload execution.
The EWS issue leaves a clearer trace. An authenticated user reading arbitrary mailboxes through FindItem generates EWS requests for folders and items the account does not own. Where mailbox access logs are retained with the authenticated user and the requested mailbox, that pattern is detectable; where the web server log is the only record, it is not.
The comparison worth making is whether a request for a mailbox the caller cannot access appears anywhere an analyst would look. Zimbra's own audit capabilities vary by deployment, and the practical check is to attempt an out-of-scope read against a test account and confirm that something records it.

References

  • Zimbra Security Advisories wiki: https://wiki.zimbra.com/wiki/Zimbra_Security_Advisories

  • Zimbra Collaboration Suite release notes: https://wiki.zimbra.com/wiki/Zimbra_Releases

  • NVD records: https://nvd.nist.gov/vuln/detail/CVE-2026-93641, https://nvd.nist.gov/vuln/detail/CVE-2026-93642, https://nvd.nist.gov/vuln/detail/CVE-2026-93647, https://nvd.nist.gov/vuln/detail/CVE-2026-10631