Zimbra Collaboration Hardening Guide: Admin Access, Patching and Mail Security

Self-hosted Zimbra Collaboration servers are a repeat target because a single unauthenticated flaw on an internet-facing mail server hands an attacker every mailbox in the organisation. The CISA Known Exploited Vulnerabilities catalogue lists 19 Synacor Zimbra entries, from the 2022 mailbox import chain to cross-site scripting in calendar invitations and command injection through SMTP. This guide covers how authentication, administration and preauth keys work in Zimbra, which ports and services to expose, the configuration settings Zimbra's own security operations notes recommend, and how to detect compromise. It is for mail administrators and security engineers running Zimbra on premises or in a private cloud. For general email controls such as DMARC and gateway filtering, see the Email Security Guide.

Key takeaways

• Patching speed is the main control. Zimbra does not separate security fixes from feature releases, so every patch release may carry a security fix, and exploited flaws such as CVE-2024-45519 (postjournal, CVSS 9.8) allow unauthenticated command execution.
• The admin console must never face the internet. Keep port 7071 internal, publish 9071 through the proxy only if needed, and reach it over VPN or an SSH tunnel.
• The domain preauth key is a master key. Zimbra's documentation warns that zimbraPreAuthKey can generate valid auth tokens for any user in the domain, so treat it as a privileged non-human credential.
• Two-factor authentication needs Network Edition and careful options. Enforce it per Class of Service, disable trusted devices and manage application passcodes for IMAP and ActiveSync clients.
• Logs only help if they show the real client IP. Configure zimbraMailTrustedIP and the originating IP header, and ship audit.log and mailbox.log off the server.

How identity and access work in Zimbra

Zimbra stores accounts, domains, Classes of Service (CoS) and server configuration in its own OpenLDAP directory (port 389, internal only). Users sign in to the web client over HTTPS through the Zimbra proxy (nginx), or connect with IMAP, POP3, SMTP submission and ActiveSync. Authentication can be local, or delegated to an external LDAP or Active Directory per domain.

Two web settings from Zimbra's security operations notes also reduce session theft risk (ATT&CK T1550.004 Web Session Cookie): zmlocalconfig -e zimbra_same_site_cookie="Strict", and zimbraReverseProxyStrictServerNameEnabled TRUE with zimbraVirtualHostName set on each domain so the proxy rejects unexpected Host headers.

The webmail client is itself an attack surface. Several KEV entries are cross-site scripting flaws, including CVE-2025-27915 in the Classic Web Client, where JavaScript embedded in an ICS calendar entry runs when the user views the message. Attacker script running in a logged-in session acts with the user's rights without needing the password, which is why patching the web client matters as much as patching the server.

Admin roles and privileged access

Zimbra has global administrators, who can change anything in the deployment, and delegated administrators, who are granted specific rights over domains or accounts. The admin console and admin SOAP API run on the mailbox server at port 7071, and the proxy can publish them on 9071.

• Keep the admin UI off the internet: Zimbra's notes say not to expose 7071 or 9071 publicly. Use a VPN or an SSH tunnel such as ssh -L 7071:localhost:7071 with a low-privilege SSH user, or proxy the console on 9071 with stronger TLS and firewall 7071.
• Separate admin identities: administrators should use a dedicated admin account with a strong password and two-factor authentication, not their mailbox account. Disable stale admin accounts and consider keeping the built-in admin account disabled except when needed.
• Prefer delegated admin for help desks: password resets and mailbox moves rarely need global rights. Review who holds global admin each quarter.
• Protect the operating system account: the zimbra Unix user runs every service, and successful exploits such as CVE-2026-73570 execute commands as that user. Restrict SSH to known IP addresses, disable password authentication (PasswordAuthentication no) and log all sudo use.
• Admin preauth is stronger still: preauth supports an admin mode (admin=1), so a leaked domain key may reach admin sessions as well as user sessions.

Small deployments with one or two administrators usually get most value from VPN-only console access plus 2FA. Larger providers and universities with many domains should invest in delegated admin, per-domain rights and a privileged access workflow. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Zimbra servers hold several credentials that are not tied to a person. Each one is a non-human identity with an owner, a storage location and a rotation plan, or it becomes the path an attacker uses to persist.

Zimbra's preauth documentation adds three operational warnings: its sample code hard-codes keys, which is unsafe in production; preauth via REST does not log the user's originating IP without extra SOAP configuration; and since 9.0.0 Patch 30 and 8.8.15 Patch 37 preauth redirects only to zimbraPublicServiceHostname. See the Secrets Management Guide for vaulting and rotation patterns.

Also lock down server features that can be abused to reach other systems. Zimbra's notes recommend zmprov mc default zimbraProxyAllowedDomains "" so the proxy servlet cannot fetch arbitrary URLs, which matters because KEV includes Zimbra server-side request forgery flaws (CVE-2019-9621, CVE-2020-7796).

Logging and detection

Zimbra writes runtime logs under /opt/zimbra/log/. Forward them to a central log server, because an attacker with code execution as the zimbra user can edit local logs. With rsyslog, audit.log can be forwarded under the tag zimbra-audit:.

• Get the real client IP: set zimbra_http_originating_ip_header to X-Forwarded-For and add the loopback and proxy addresses with zmprov mcf +zimbraMailTrustedIP. Without it, every request appears to come from the proxy.
• Track last logon: zimbraLastLogonTimestampFrequency controls how often last logon is recorded; a short interval helps find dormant accounts that suddenly sign in.
• File integrity: use Zimbra's integrity check script to checksum installation files and find unexpected changes, a common sign of a web shell after exploitation.
• Debug only when needed: zmprov addAccountLogger <user> zimbra.soap debug gives per-account detail during an investigation; remove it afterwards.

If you find an unexpected JSP file or shell process, follow the Web Shell Response Playbook, then rotate the preauth key, LDAP passwords and admin credentials, because code execution as zimbra exposes all of them.

Metrics

• Days from a Zimbra security patch release to deployment on every node (target within your critical-patch window for KEV-listed issues).
• Number of internet-reachable ports per node compared with the approved list.
• Percentage of active accounts with 2FA enrolled, and number of application passcodes per user.
• Number of accounts holding global admin, and admin sign-ins from outside the management network (target zero).
• Integrity check exceptions per month and time to explain each one.

Hardening baseline

Network exposure

Use a host firewall that fails closed (Zimbra's notes give an iptables example and caution that firewalld can leave ports open if it fails), mirror the rules for IPv6, and restrict SSH to known addresses. For network-level patterns see the Network Device Management Plane Hardening Guide.

Configuration settings

• Relay control: set zimbraMtaMyNetworks to loopback and the networks that genuinely relay, never a wide range.
• Header hygiene: zmprov mcf zimbraSmtpSendAddMailer FALSE to stop advertising the mailer version.
• Crawlers: zimbraMailKeepOutWebCrawlers TRUE and an X-Robots-Tag: noindex response header.
• Attachments: keep zimbraMtaBlockedExtension populated (for example exe, bat, vbs) with warnings to admin and recipient.
• Attachment scanning dependency: install pax so Amavis does not fall back to cpio; CVE-2022-41352 abused cpio to upload arbitrary files.
• Kernel and supported versions: run a supported OS and Zimbra line. Zimbra's advisory page lists fixes for 10.1.x, 10.0.x, 9.0.0 and 8.8.15 patch lines; anything older is unpatched for current flaws.

Patching and rollout

1. Subscribe: follow the Zimbra security advisory RSS feed and the CISA KEV catalogue for Synacor entries.
2. Set a severity clock: Zimbra's own example policy is immediate or end of business day for high-rated fixes, end of the working week for medium and a monthly window for low. KEV-listed or unauthenticated remote code execution flaws belong in the fastest lane. See the Emergency Out-of-Band Patching Playbook.
3. Snapshot and test: snapshot the VM or back up /opt/zimbra and LDAP, then patch a staging node and test web sign-in, 2FA, ActiveSync and mail flow.
4. Patch every node: follow the node order and steps in the release notes for your patch line (Zimbra advises reviewing them because security and feature changes ship together), and reboot after kernel updates.
5. Roll back: revert the snapshot if mail flow fails, keeping the node off the internet until the fix can be retried.
6. Hunt after emergency patches: for exploited flaws, check for web shells and new admin accounts on every node, because patching does not remove an attacker who arrived first.

Framework mapping

Common misconfigurations

• Admin console reachable from the internet: exposing 7071 or 9071 turns every admin authentication flaw into an internet-facing one. Firewall them first, before anything else on this page.
• Falling behind on patch lines: unsupported versions share the flaws of supported ones but get no fixes. The 2022 chain of CVE-2022-37042 (authentication bypass in MailboxImportServlet) and CVE-2022-27925 (mboximport file upload) gave unauthenticated code execution on unpatched servers.
• Preauth keys left in portal code: a key copied into a web portal's source or configuration repository can sign in as anyone in the domain, and REST preauth does not log the originating IP.
• 2FA with trusted devices left on: a "trusted" browser skips the second factor, so a stolen password plus a reused device defeats 2FA. Disable trusted devices in every CoS.
• No real client IPs in logs: without zimbraMailTrustedIP, investigators see only the proxy address and cannot scope spraying or session theft.
• Assuming a patch ends the incident: exploitation of mail servers is often found weeks later. After a KEV-listed Zimbra flaw, hunt for web shells, new admin accounts and mail forwarding rules even if you patched quickly.

Practitioner checklist

• Firewall 7071 and 9071 from the internet and reach the admin console only through VPN or an SSH tunnel.
• Confirm every node runs a supported Zimbra patch line and subscribe to the advisory feed and KEV.
• Apply the port table: only 25, 443, 465, 587 and required IMAPS or POP3S externally; LDAP and backend ports internal.
• Enforce 2FA through CoS, disable trusted devices and review application passcodes.
• Set zimbraAuthFallbackToLocal FALSE on externally authenticated domains and disable alias login.
• Inventory every zimbraPreAuthKey, move keys into a vault and regenerate any found in code or tickets.
• Configure zimbraMailTrustedIP and the originating IP header, and forward audit.log, mailbox.log and nginx logs centrally.
• Run the integrity check after each patch and investigate every unexpected change.
• Install pax, set strict SameSite cookies and strict server name checking on the proxy.
• Rehearse the web shell and credential rotation steps for a Zimbra compromise.

Standards and references

• Zimbra: Security Advisories
• Zimbra: Security Operations Tips
• Zimbra: Preauth
• Zimbra: Ports
• Zimbra: Two-factor authentication
• Zimbra: Log Files
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Email Security Guide · Web Shell Response Playbook · Emergency Out-of-Band Patching Playbook · Secrets Management Guide