CVE-2024-45519

What it actually does

This is an unauthenticated command injection vulnerability in the Zimbra Collaboration postjournal service. A remote attacker can send specially crafted SMTP content that is processed by postjournal and causes attacker-controlled input to be interpreted as an operating system command. Successful exploitation allows command execution in the context of the Zimbra service account, commonly the zimbra user, without requiring valid credentials. From there, an attacker may download tools, create persistence, read mail data accessible to the service, deploy web shells, pivot to other services on the host, or attempt privilege escalation.

Why it matters to the business

Because Zimbra servers are often internet-facing and handle sensitive email, exploitation can lead to mailbox compromise, theft of business communications, credential harvesting, malware deployment, service disruption, and use of the mail server as a foothold into the wider network. This issue is listed in CISA KEV, has a very high EPSS score, and is actively exploited in the wild, so unpatched systems should be treated as high-priority exposure. The CISA remediation due date was 2024-10-24, meaning any remaining vulnerable deployment is significantly overdue for remediation.

How an attack unfolds

An attacker identifies an internet-accessible Zimbra Collaboration server with the vulnerable postjournal component enabled or reachable through mail-processing paths. The attacker then sends a crafted SMTP message containing shell metacharacters or command-substitution syntax in fields that postjournal processes. When the vulnerable service handles the message, it fails to safely neutralize the input and passes attacker-controlled content into a command execution context. The attacker typically uses the first command to verify execution, then downloads a payload using tools such as curl or wget, launches a shell, creates files under writable Zimbra or temporary directories, or installs a web shell for persistence. Post-exploitation activity may include mailbox access, credential theft, lateral movement, cleanup of obvious artifacts, and repeated access through planted scripts or scheduled tasks.

How to fix it

Upgrade Zimbra Collaboration to a fixed release immediately: 8.8.15 Patch 46 or later, 9.0.0 Patch 41 or later, 10.0.9 or later, or 10.1.1 or later. For source-based consumers, ensure the relevant fixes are present, including zimbra/zm-build commit ac6081fa002b1511e926aba37740d2b6c20f3f43, zimbra/zm-mailbox commits a28371d6e77de652833e208a1c9d074f94ce36b4 and d30e647f21ecef5490f21facf2e06e228b44a36e, and zimbra/zm-zcs-lib commit 74ca4ff049d001731d7e1a22f667e32ad9a672e1. If immediate patching is not possible, restrict access to Zimbra mail-processing services to trusted mail relays only, disable or isolate postjournal if it is not required, block direct internet access to administrative and nonessential Zimbra ports, and monitor aggressively for exploitation. Because exploitation is active, patching alone is not sufficient for already-exposed systems; perform compromise assessment before returning systems to normal trust.

How to confirm the fix worked

Confirm the installed Zimbra version and patch level using supported Zimbra administrative commands and package inventory, and verify it is at or above the fixed release for the deployed major version. Confirm that postjournal-related packages or binaries have been updated and that services were restarted after patching. Validate network exposure by confirming only intended SMTP relays can reach mail-processing paths and that administrative interfaces are not broadly exposed. Review logs around the period before patching for crafted SMTP input, shell metacharacters in recipient or header fields, unexpected child processes launched by the zimbra account, outbound connections from the mail server to unfamiliar hosts, and new files under Zimbra web, temporary, or configuration directories. If feasible, run an authenticated vulnerability scanner or vendor-supported health check to confirm the vulnerable build is no longer present.

Typical attack path

1. Scan the internet or known mail infrastructure for exposed Zimbra Collaboration servers.
2. Determine whether the target version is vulnerable or attempt exploitation opportunistically over SMTP/mail-processing paths.
3. Send a crafted message containing command-injection characters that are processed by the postjournal service.
4. Trigger execution of a simple command to confirm remote code execution.
5. Use the command-execution primitive to download or write a second-stage payload, web shell, reverse shell, or reconnaissance script.
6. Enumerate the host, Zimbra configuration, mailbox data, credentials, and network reachability.
7. Establish persistence or repeatable access, then exfiltrate data or pivot further into the environment.

How to detect it

Investigate whether exploitation already occurred by reviewing mail, system, process, and Zimbra application logs for the vulnerable exposure window. Prioritize /var/log/zimbra.log, /var/log/mail.log or /var/log/maillog, /opt/zimbra/log/mailbox.log, /opt/zimbra/log/audit.log, postjournal-related logs if present, shell history for the zimbra account, process accounting or EDR telemetry, web server access logs, and file-integrity records under /opt/zimbra. Look for SMTP transactions with unusual recipient, sender, or header values containing shell metacharacters such as semicolons, pipes, backticks, dollar-parentheses command substitution, redirection operators, or encoded command payloads. Correlate those messages with processes spawned by Zimbra services, especially sh, bash, curl, wget, nc, ncat, python, perl, openssl, busybox, chmod, chattr, or base64. Search for unexpected outbound HTTP, HTTPS, DNS, or raw TCP connections from the mail server shortly after suspicious SMTP messages. On disk, look for recently created or modified JSP, PHP, shell scripts, ELF binaries, or hidden files in Zimbra web roots, temporary directories, and user-writable locations. Also review cron, systemd units, authorized_keys, and Zimbra configuration for persistence. If EDR is available, hunt for command-line ancestry where postjournal, postfix, java, or Zimbra service processes spawn a shell or downloader, as that is strongly suspicious for exploitation.

• /var/log/zimbra.log
• /var/log/mail.log
• /var/log/maillog
• /opt/zimbra/log/mailbox.log
• /opt/zimbra/log/audit.log
• /opt/zimbra/log/nginx.access.log
• /opt/zimbra/log/nginx.log
• /opt/zimbra/jetty_base/webapps/zimbra/
• /opt/zimbra/jetty_base/webapps/zimbraAdmin/
• /opt/zimbra/jetty_base/webapps/service/
• /opt/zimbra/log/
• /tmp/
• /var/tmp/
• /dev/shm/
• postjournal
• zmpostjournal
• RCPT TO:<*;*
• MAIL FROM:<*;*
• $(
• `
• ;curl
• ; wget
• |curl
• | wget
• curl -fsSL
• curl -o
• wget -O
• bash -c
• sh -c
• /bin/bash
• /bin/sh
• python -c
• python3 -c
• perl -e
• base64 -d
• chmod +x
• /dev/tcp/
• nc -e
• ncat -e
• mkfifo
• nohup
• crontab -e
• authorized_keys
• .jsp
• webshell
• cmd=

What your security team should do

• Treat any unpatched internet-facing Zimbra server as potentially compromised due to active exploitation, KEV listing, and very high exploitation probability.
• Patch immediately to 8.8.15 Patch 46, 9.0.0 Patch 41, 10.0.9, 10.1.1, or later as applicable.
• Before or immediately after patching, preserve relevant logs and perform forensic review for command execution, suspicious SMTP payloads, unexpected files, and outbound connections.
• Restrict SMTP and Zimbra service exposure so only trusted relays and required clients can reach the server.
• Hunt for web shells, reverse shells, unauthorized cron jobs, modified Zimbra scripts, and suspicious processes running as the zimbra user.
• Rotate credentials and secrets accessible from the Zimbra host if compromise is suspected, including administrative, LDAP, mailbox, and service credentials.
• Add SIEM detections for SMTP fields containing shell metacharacters combined with command utilities such as curl, wget, bash, sh, nc, python, perl, or base64.
• Review mailbox access and forwarding rules for unauthorized changes after any suspected compromise.