Reading the Email Was Enough

Summary

On 22 July 2026, allied security agencies published a detailed report on a Russian state-supported campaign targeting vulnerable Zimbra webmail systems.

The recipient did not need to follow a link, open an attachment, enter a password or approve an MFA request. The message did have to be opened or previewed in Zimbra's vulnerable Classic web client. Once it was displayed, hidden JavaScript ran inside the user's already authenticated session.

From there, the attackers tried to collect 90 days of email, rebuild the organisation's address directory, steal passwords and two-factor authentication data, enable IMAP and create a new application password for later access.

The user did not make a bad security decision. The email client made the decision for them.

We have spent years teaching people one rule about suspicious email:

Do not click.

It is good advice. It stops a great deal of phishing.

But it assumes there will be a moment when the user sees something suspicious and gets to choose what happens next.

This campaign did not give them that moment.

A Russian state-supported group known as LAUNDRY BEAR sent specially crafted emails to users of vulnerable Zimbra Collaboration Suite installations. No malicious link had to be followed. No attachment had to be opened. No fake Microsoft login page appeared.

The person only had to view the message in the Classic web client.

Then the email ran.

First, one important clarification

This has often been called a zero-click attack. Unit 42 uses that term. Proofpoint calls it a "half-click" exploit. The joint government advisory calls it view-based.

View-based is probably the least dramatic and most useful description.

The exploit did not run simply because the email arrived. The message still had to be opened or shown in the preview pane of the vulnerable Zimbra Classic interface.

But after that, there was no second, obviously dangerous action. Reading the message was the trigger.

That is what made me stop when I read the advisory. The user could be careful. They could distrust links, ignore attachments and refuse unexpected login prompts. None of it would help, because the unsafe part was the email viewer itself.

What actually happened

The vulnerability is CVE-2025-66376, a stored cross-site scripting flaw affecting the Classic interface in Zimbra Collaboration Suite 10 before 10.0.18 and 10.1 before 10.1.13.

Email clients have an awkward job. They receive HTML written by people and systems they do not control, then try to make it look right without allowing that HTML to behave like a web application.

Here, that filtering failed around specially crafted CSS @import directives.

The attackers hid an obfuscated, Base64-encoded payload inside the message. When Zimbra displayed it, the payload reconstructed an SVG element with an onload handler, decoded JavaScript and ran it.

That sounds like a lot of browser plumbing. In plain English: the email found a way to turn formatting into code.

And the code did not run on an unrelated website. It ran inside the same browser context as the victim's open webmail.

The user had already logged in. The browser already had a valid session. The malicious script tried to retrieve Zimbra's CSRF token from local storage and call Zimbra's own SOAP interfaces with the authority the user already had.

It did not need to steal the key at the front door. It was already standing inside the mailbox.

One email, twelve jobs

The collection tool was called Ulej, Russian for "beehive". The name is almost understated for what it tried to do.

The payload contained twelve asynchronous stages. Together, they attempted to:

• identify the victim and the Zimbra environment
• retrieve two-factor authentication scratch codes
• create a new application-specific password
• enumerate device and OAuth information
• trick a password manager into autofilling invisible login fields
• enable IMAP access
• rebuild the organisation's Global Address List
• download the last 90 days of non-junk email
• send the collected material back to the attackers

Some of the mechanics are unusually revealing.

To reconstruct the address directory, the script did not ask for one neat export. It searched every two-character combination from a defined character set — 1,521 SearchGalRequest calls — and assembled the results.

It collected email one day at a time for the previous 90 days. After each day, it wrote a marker such as zd_comp_YYYY-MM-DD to local storage so it would not download the same period twice when the exploit ran again.

Those markers later became useful forensic evidence.

The script also tried to enable IMAP and create an application passcode named ZimbraWeb. That could give the attacker another route into the mailbox after the browser session ended, including through clients that do not use Zimbra's ordinary two-factor flow.

This was not a quick grab of whatever happened to be visible on screen. It was an attempt to turn one open email into a mailbox export, an internal directory and a way back in.

MFA had already done its job

The obvious advice after almost any account-security story is to enable MFA.

You should. MFA prevents a large number of account takeovers.

But in this case, the user had already authenticated. There was no new login for MFA to challenge. The malicious code ran inside the session that MFA had helped create.

From there, it tried to collect 2FA scratch codes, pull a password from a password manager through invisible fields, enable IMAP and generate an application password.

MFA was not useless. It had already done the job it was designed to do.

The problem came afterwards.

A secure login does not make every piece of code running inside the logged-in application safe. That is particularly important in email, where untrusted content is constantly being rendered next to sessions, contacts, files, reset links and years of organisational history.

Medium on paper

Here is another part of the story that caught my eye.

The US National Vulnerability Database currently scores CVE-2025-66376 at 6.1, Medium. One reason is UI:R: user interaction required.

MITRE's assessment on the same page scores it 7.2, High, with no user interaction required.

I do not think this is proof that one side understands the vulnerability and the other does not. It reflects a genuinely awkward question: does opening an email count as security-relevant interaction?

Technically, yes. The message had to be displayed.

In practice, opening email is what an email system asks its users to do all day.

If "user interaction" means running an unknown executable, bypassing a warning or approving a strange prompt, the user still has a chance to stop the attack.

If it means reading a message, the protection is mostly theoretical.

The number also says nothing about the value of the system behind it. A mailbox may hold password-reset links, contracts, internal decisions, customer conversations and security notifications. The address directory maps the organisation. A stolen account can become a trusted sender to the next victim.

This is why I am wary of reading CVSS scores without looking at what the affected system can reach. I wrote about the same problem in The Control Plane Is the New Perimeter: a medium-severity flaw in a trusted system can cause more damage than a critical flaw in something isolated.

CISA added CVE-2025-66376 to its Known Exploited Vulnerabilities catalogue on 18 March 2026.

The score said "Medium".

The attackers were already using it.

The patch was already there

The timeline is worth looking at:

Before 6 November, operators had no patch. That was the true zero-day period.

After 6 November, the story became much more ordinary: the fix existed, but not every exposed system had received it.

That gap is where a great many incidents happen. A vendor patch is not the same thing as a patched service.

Zimbra's security advisory lists 10.0.18 and 10.1.13 as the fixed versions. Yet Unit 42 was still reporting successful targeting of unpatched installations in July 2026.

Eight months after the fix, the same email could still work.

The backend looked completely ordinary

The infrastructure behind the campaign was not especially exotic.

The attackers used short-lived virtual private servers, often for between seven and 60 days. An automated process deployed a Python project called Flowerbed in four Docker containers: a receiver, Certbot, Nginx and a health-check service.

Let's Encrypt handled certificates. Nginx handled encrypted traffic. Data could leave through HTTPS or DNS.

These are the same building blocks used by legitimate companies every day. Their presence proves nothing on its own, and there is no suggestion that the providers involved knowingly helped the attackers.

But ordinary infrastructure is useful camouflage.

I wrote about the same effect in Your Connected Devices May Already Be Part of the Next Cyberattack. There, malicious traffic disappeared into ordinary residential broadband. Here, the attackers used familiar cloud components and previously compromised email accounts.

The advisory also found signs that AI may have helped produce parts of the fairly simple Flowerbed codebase. The agencies do not present that as proven, and neither should we.

Even if they are right, the interesting part is not that AI built some cinematic cyberweapon. It may simply have helped a capable operator assemble ordinary code more quickly.

The valuable part of the operation was the access. Once the email was running inside an authenticated mailbox, the backend did not have to be brilliant.

There was nothing useful for the user to notice

Security teams often call employees the last line of defence.

That can become an unfair place to put them.

There was no strange URL here for the recipient to inspect. No attachment type to recognise. No fake sign-in page. The malicious emails were also sent from previously compromised accounts, so some arrived with the identity and reputation of a real sender.

A careful employee cannot fix an HTML sanitiser.

They cannot change browser-origin rules.

They cannot revoke an application password they do not know was created.

Keep teaching people how phishing works. Most attacks still need deception, urgency or a mistake.

But when the user has no meaningful decision to make, the answer has to come from patching, safe rendering, logging and detection — not another training slide.

Why I care about this

I run email infrastructure. So this is not an abstract argument for me.

Email is one of the worst places to blur the line between content and code. It receives untrusted material from the entire internet, displays it inside an authenticated application and sits next to some of the most sensitive information an organisation has.

It is also easy, after an incident, to say that the user should have been more careful. Sometimes that is fair. Here it is not.

The user used the product as intended.

The software failed to keep the message in its place.

I also still believe strongly in open source, self-hosting and European control over infrastructure. This is not an argument against any of those things. Zimbra published a fix months before the detailed public report.

But control comes with work.

If you operate the service yourself, you must know what is exposed, apply updates, keep the logs needed to look backwards and understand what credentials or sessions need to be revoked when something goes wrong.

The country where the server stands will not save an unpatched session.

Owning the infrastructure means owning the response too.

What Zimbra operators should do now

First, check whether you run an affected version. The minimum releases containing the fix were ZCS 10.0.18 and 10.1.13. Update to a current, supported release. If that cannot happen immediately, the joint advisory recommends avoiding the Classic web client and using another mail client until the server is updated.

Then look backwards. Patching today does not tell you whether someone viewed a malicious email yesterday.

The advisory lists several useful traces:

• bursts of SearchGalRequest activity from one user
• CreateAppSpecificPasswordRequest creating a passcode named ZimbraWeb
• use of GetScratchCodesRequest
• local-storage keys matching zd_comp_YYYY-MM-DD
• large outbound transfers to unfamiliar VPS infrastructure
• frequent DNS queries with apparently random subdomains
• connections to newly registered domains linked to the campaign

If you find signs of compromise, a password reset is not enough. Revoke application passcodes and 2FA scratch codes, change credentials, identify the likely compromise dates, work out which email periods may have been taken and search for similar malicious messages elsewhere in the organisation.

The full government report contains indicators and more detailed detection guidance. Because the attackers rotated servers and domains regularly, treat those indicators as evidence to investigate, not as a permanent block list.

Keep the advice. Fix the software.

"Do not click" is still good advice.

It is just not a security architecture.

In this case, a person could avoid the link, the attachment, the fake login and the unexpected MFA request. They could do exactly what the system was built for — read an email — and start a twelve-stage espionage operation.

That is what makes this campaign worth remembering.

Not because every email is now dangerous.

But because sometimes the user is not the part that needs more training.

Sometimes it is the software that reads the email with them.

Sources

• Joint Cybersecurity Advisory: Russian State-Supported Cyber Actors Conduct Phishing Campaign Targeting Users of Zimbra Collaboration Suite
• Zimbra Security Advisories
• NVD: CVE-2025-66376
• CISA Adds One Known Exploited Vulnerability to Catalog, 18 March 2026
• Palo Alto Networks Unit 42: Russian Global Webmail Espionage
• Proofpoint: TA488 Targets Zimbra Mailservers with Half-Click Exploits
• Microsoft: New Russia-affiliated actor Void Blizzard targets critical sectors for espionage
• Radar: the original advisory as indexed on knutmichael.com