Zimbra 66 is the collaborative messaging client deployed by the Pyrénées-Orientales departmental council (CD 66) for all its agents. Beyond sending and receiving emails, the platform centralizes shared calendars, address books, and task management. The question that arises for each department and service is: what settings and practices truly allow for making the most of this tool, and what risks still go unnoticed?
Zimbra 66 Security: Documented Vulnerabilities and Recommended Patches
The majority of guides dedicated to Zimbra in local authorities focus on connecting and customizing the interface. However, the security aspect remains the most critical point for an administration that handles personal data of thousands of users.
Several recent vulnerabilities have affected the classic web client of Zimbra, including password recovery, the WebDAV protocol, and OnlyOffice integration. Some of these vulnerabilities have been listed in the CISA’s catalog of exploited vulnerabilities (the U.S. cybersecurity agency), indicating active exploitation by attackers.
For a departmental IT department, this implies a formalized procedure: monitoring notices published by the Zimbra publisher, testing in a pre-production environment, and then quickly applying patches to production servers. A simple reminder to agents to “choose a strong password” does not cover this risk.
Agents wishing to better understand the functional scope of this messaging system can use Zimbra 66 with Le Off as a starting point before delving into the technical aspects described here.
| Zimbra Component | Reported Vulnerability Type | Recommended Measure |
|---|---|---|
| Classic web client | XSS vulnerability | Client update, input filtering |
| Password recovery | Authentication bypass | Verification of reset flows |
| WebDAV | MFA bypass | Disable the protocol if not in use |
| OnlyOffice integration | Remote code execution | Priority vendor patch |
| ICS attachments (calendars) | Stored XSS via invitation | Filtering calendar attachments |
Multifactor Authentication: Why Webmail Alone Is Not Enough
Enabling multifactor authentication (MFA) on the Zimbra 66 web interface is a first step. However, MFA must cover all access protocols, not just the browser.
Recent information indicates an MFA bypass via WebDAV in certain affected versions. An agent who synchronizes their email on a smartphone via ActiveSync or who uses a heavy client (Thunderbird, Outlook) can therefore access their inbox without going through double verification if these protocols are not covered.
Protocols to Include in the MFA Policy
- Webmail access (browser interface): covered by default in most configurations, but should be verified after each update
- Mobile synchronization (ActiveSync, CalDAV, CardDAV): often overlooked, while professional phones multiply entry points
- Heavy IMAP/SMTP clients: if agents use Thunderbird or another client, the IMAP flow must be subject to the same requirements
- Zimbra administration interface: a compromised access to the administration console gives total control over all mailboxes
The most direct recommendation for the IT department of CD 66: disable unused protocols in the server configuration. Fewer open doors mean less attack surface.
Zimbra 66 Shared Calendars: Attack Surface and Best Practices
Shared calendars are often presented as a simple coordination tool between services. In Zimbra, they also represent a specific attack surface.
A stored XSS vulnerability has been documented: it could be triggered by a specially crafted ICS attachment sent as a calendar invitation. By opening this invitation, an agent inadvertently executed malicious code in their browser.
Two concrete measures reduce this risk:
The IT department should configure the Zimbra server to filter or quarantine ICS attachments from external domains. Agents, for their part, should never automatically accept a calendar invitation from an unknown sender. This setting can be found in the Zimbra calendar preferences, under “Receiving invitations.”
Zimbra 66 and GDPR Compliance: Obligations in Case of an Incident
The use of Zimbra in a departmental administration falls within a strict regulatory framework. Any data leak via messaging constitutes a GDPR incident that must be reported to the CNIL within a constrained timeframe.
The most common scenarios are not sophisticated cyberattacks. An email sent to the wrong recipient, a shared mailbox whose access rights have not been revised after a departure, or a compromised account due to phishing are enough to trigger the notification obligation.
Procedure to Formalize in Each Department
The departmental DPO unit must have a clear reporting circuit. An agent who notices the sending of an email containing personal data to an incorrect recipient must know whom to notify, within what timeframe, and with what information. This circuit should be tested at least once a year, not just documented in a computer charter that no one reads.
Zimbra 66 offers logging functions that allow for reconstructing the timeline of an incident. These logs must be retained and accessible to the DPO unit to meet CNIL traceability requirements.
The weakest link in optimizing Zimbra 66 within CD 66 is not the interface or usability. It is the gap between the technical capabilities of the platform and the procedures actually applied by the departments, whether regarding security patch tracking, the scope of MFA, or GDPR incident management. Reducing this gap requires less budget than organizational rigor.
