Zimbra Collaboration Suite EUVD-2026-108984

Exploitation requires (1) the OPTIONAL dnscache package to be installed on the ZCS host - this is not present in a default ZCS deployment - which provides the zmunbound wrapper and the passwordless sudo policy, and (2) local control of the Unix 'zimbra' account (an existing low-privilege foothold). The specific enabling conditions are the passwordless sudo rule that permits arbitrary arguments to zmunbound and the wrapper forwarding those arguments to Unbound without restricting the configuration path, allowing an attacker-supplied config that retains root and disables chroot. Limiting factors: there is NO remote or network vector (AV:L), no unauthenticated path (the zimbra account is required), and hosts without the optional dnscache package are not affected; this is confirmed present in ZCS 10.1.16 and 10.1.21.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8 HIGH) is internally consistent with the description: this is a local privilege-escalation issue requiring attacker control of the already-provisioned Unix 'zimbra' service account (PR:L), no user interaction, and low complexity once that foothold exists - there is no network-facing exploitation path here, so it should not be triaged like a remote RCE. The vuln.today Decision label is 'this_week' (not act_now/emergency), which aligns with a serious-but-locally-scoped flaw. EPSS is not provided in the input, so exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV and there is no confirmation of active exploitation; a public technical write-up from Rapid7 (the reporter) is referenced, but it is a blog reference, not verified as working exploit code. The realistic risk is therefore conditional: it is a genuine priority for any organization running the optional dnscache package on ZCS because it converts a compromised or malicious zimbra account into root-level file disclosure and corruption, but it is not a mass-exploitable internet-facing threat. Key missing data: no EPSS score, no independent fixed-version confirmation, and no SSVC automatable/technical-impact fields were supplied - these should be verified against the Zimbra security advisory before final prioritization.

An attacker who already controls the Unix 'zimbra' account (via a web-app compromise, stolen credentials, or a malicious insider) writes a crafted Unbound configuration file and invokes zmunbound through the passwordless sudo policy. Because the wrapper forwards arbitrary arguments and does not restrict the config path, Unbound runs as root with chroot disabled, letting the attacker use Include directives and an attacker-chosen logfile path to read root-only files (password hashes, private keys) and create or append to root-owned files. A public technical PoC reference from Rapid7 exists but is not verified as working exploit code; local access and low complexity make this straightforward once the zimbra foothold is obtained.