The Russian espionage campaign exploiting a Zimbra zero-day highlights how dangerous email-platform vulnerabilities can become when they are used for intelligence collection.

The flaw, tracked as CVE-2025-66376, affected Zimbra’s Classic Web Client and involved a stored cross-site scripting vulnerability. Attackers used crafted HTML emails that executed malicious JavaScript when viewed in a vulnerable Zimbra session. In practical terms, simply opening or previewing a malicious email could be enough to trigger the exploit.

That makes this incident especially serious. Users did not need to download an attachment, enable macros, enter credentials on a fake page, or run a command. The exploit abused the webmail client itself, allowing attacker-controlled code to run inside the victim’s authenticated mailbox session.

The campaign reportedly targeted Western government and commercial organizations, with activity linked to a Russian state-supported espionage group known by names including Laundry Bear, Void Blizzard, CL-STA-1114, and TA488. The exact naming may vary between security vendors, but the operational lesson is the same: the goal was intelligence collection, not noisy disruption.

The payload, tracked by Proofpoint as ZimReaper, was designed to steal high-value mailbox data. It could collect the last 90 days of email, enumerate the organization’s global address list, steal CSRF tokens, collect browser-autofilled passwords, retrieve Zimbra version information, and access two-factor recovery or scratch codes.

This is a major concern because email remains one of the richest intelligence sources in any organization. Mailboxes contain contracts, internal discussions, invoices, travel plans, approvals, credentials, reset links, customer communication, legal material, procurement discussions, and security alerts. For espionage actors, a mailbox is not just communication. It is an archive of how the organization thinks and operates.

The theft of 2FA recovery codes is especially important. Multifactor authentication improves security, but recovery codes can become a bypass path if attackers steal them. If those codes are stored inside or accessible through the same compromised platform, the protection is weakened. Apparently, even backup security mechanisms need protection from the system they are supposed to rescue.

The campaign also abused Zimbra’s app-specific password functionality. Attackers could create or use application passwords that may allow IMAP, POP3, or SMTP access without normal interactive multifactor checks. This is dangerous because a password reset alone may not remove all attacker access if app-specific passwords or active sessions remain valid.

Organizations using Zimbra should immediately confirm whether they are running affected versions. Zimbra Collaboration 10.0 before 10.0.18 and 10.1 before 10.1.13 were affected, and organizations should move to supported, fully updated releases rather than staying on end-of-life versions.

Patching is essential, but it is not enough in this case. The patch prevents future exploitation of the vulnerability, but it does not automatically remove stolen credentials, revoke app-specific passwords, invalidate sessions, regenerate recovery codes, or prove that mailboxes were not accessed earlier.

Any organization that operated vulnerable Zimbra Classic UI during the exposure window should perform account-level investigation. Security teams should review mailboxes that received or viewed suspicious HTML emails, especially messages containing unusual CSS import behavior, fragmented markup, hidden SVG content, or encoded JavaScript.

Administrators should review Zimbra audit logs for calls to create app-specific passwords, especially credentials named or resembling ZimbraWeb. Any unexpected app-specific passwords should be removed. They should also check for unusual IMAP or POP3 enablement, unexpected mailbox settings, forwarding rules, delegated access, suspicious filters, and abnormal mailbox downloads.

Two-factor recovery codes should be regenerated for affected users. Active sessions should be invalidated. Passwords should be reset from a clean system. Browser-saved passwords that may have been exposed should be treated as compromised, especially if users stored work credentials in the browser.

Security teams should also look for DNS-based exfiltration. Reporting indicates that stolen data was exfiltrated using DNS queries to attacker-controlled infrastructure. Long, random-looking subdomains, unusual DNS request volume, or lookups to suspicious domains should be reviewed carefully.

The global address list theft is also important. Even if only one mailbox is compromised, attackers may obtain a map of the organization’s users. That data can support follow-on phishing, impersonation, password-spray attempts, vendor fraud, and targeted espionage.

Organizations should warn users that follow-up emails may come from legitimate but compromised accounts. In this campaign, attackers reportedly used both adversary-controlled accounts and previously compromised mailboxes to send malicious messages. A familiar sender name does not prove a safe message. Tragically, trust remains one of email’s worst features.

For high-risk organizations, including government, defense, research, energy, transportation, finance, and critical infrastructure, this incident should trigger a broader email-security review. Webmail systems should be hardened, patched quickly, logged centrally, and protected with strong authentication and anomaly detection.

Security teams should also review whether Zimbra Classic UI is still required. If legacy interfaces introduce higher risk, organizations should move users to safer supported interfaces or restrict exposure. Unsupported or end-of-life platforms should not remain internet-facing simply because users dislike change. Attackers, on the other hand, adore legacy comfort.

The incident also reinforces the need to protect mail servers as critical infrastructure. Email platforms should not be treated as basic communication tools. They are identity hubs, data stores, authentication recovery channels, and intelligence repositories.

The key lesson is that a webmail vulnerability can become full mailbox intelligence collection. In this case, the attack did not only target messages. It targeted directories, passwords, recovery codes, sessions, and long-term access paths.

Organizations should patch Zimbra immediately, investigate past exposure, remove suspicious app-specific passwords, regenerate 2FA recovery codes, reset affected credentials, review mailbox settings, monitor DNS exfiltration, and treat compromised email access as a serious espionage risk.

Email compromise is rarely contained to one inbox. Once attackers read mail, steal directories, and preserve access, they gain the context needed to attack people, systems, partners, and processes. That is why patching must be followed by hunting, credential cleanup, and account-level recovery.

A Russian state-supported espionage group spent months reading Western mailboxes through a then-unknown flaw in Zimbra's webmail client. The payload goes after the last 90 days of email, the organization's entire email directory, the password saved in the browser and the codes kept for two-factor recovery. Opening the message was enough to start it. The NSA, CISA and partner agencies published

Source: Russian Espionage Group Exploited Zimbra Zero-Day to Steal Mail and 2FA Codes via The Hacker News — published 23 Jul 2026.