Zimbra Collaboration Suite CVE-2026-93628

Exploitation requires the attacker to know three specific values for an existing meeting: the meeting UID, the organizer's address, and the target attendee's address, and to send a non-outdated iCalendar REPLY component to the Zimbra server. No authentication is required (PR:N) and no organizer or attendee interaction is needed - the participation-status change is applied automatically during message delivery. Affected deployments are ZCS 10.1.16 and 10.1.21. The principal limiting factor is knowledge of the meeting UID, which is often non-trivial to obtain or guess; impact is also bounded to altering an attendee's participation status (integrity only - no data disclosure or service disruption).

This is a moderate-severity integrity flaw, not an emergency, and the signals are internally consistent. The supplied CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3) describes a network-reachable, unauthenticated flaw with no confidentiality or availability impact and only Low integrity impact - matching CWE-290 (authentication bypass by spoofing): Zimbra passes a null sender identity for iCalendar REPLY components, so the attendee authorization filter is skipped and an attacker can forge another attendee's participation status. The vuln.today decision label is 'this_month' (not act_now/emergency), which aligns with a Low-integrity, limited-impact bug. No EPSS score, no CISA KEV listing, and no confirmed working exploit were provided, so there is no evidence of active exploitation - a Rapid7 technical write-up exists but is a research blog, not verified weaponized exploit code. The one factor the raw CVSS understates is the practical prerequisite: the attacker must already know the meeting UID, organizer address and attendee address, which constrains opportunistic/automated abuse even though the vector scores AC:L. Net: a real but targeted integrity/spoofing issue suited for scheduled patching rather than crisis response.

An attacker who has learned a specific meeting's UID plus the organizer and attendee email addresses crafts an iCalendar REPLY email and sends it to the Zimbra server; because Zimbra processes it with a null sender identity, the authorization check is bypassed and the forged attendee's status (e.g., accepted/declined) is silently written into the organizer's calendar during delivery with no interaction. A Rapid7 research write-up documents the technique, but no verified working exploit code is confirmed in the provided data.