The email you only had to view

What happened

The NCSC and international partners have disclosed a Russian state-supported campaign targeting organisations that use Zimbra Collaboration Suite. The operation used a view-based technique: on vulnerable systems, simply viewing a malicious email could trigger the attack without the recipient opening an attachment or following a link.

The campaign has reportedly been active since July 2025 and focused on stealing sensitive mailbox information from government, defence, energy, education, media, technology and other organisations. That makes this more than a clever phishing trick; it is an example of a public-facing web application turning ordinary content into code inside a trusted session.

Why this matters beyond Zimbra

Webmail, support desks, document portals and admin consoles all render content supplied by someone else. When sanitisation fails, the attacker may inherit the victim's authenticated browser context: mailbox data, session information or account settings can become reachable without a conventional login attempt.

This is also a perimeter problem. Collaboration software is often internet-facing, operationally important and awkward to take down. Those qualities make slow patching tempting and exploitation valuable.

What defenders should do now

Organisations running Zimbra should confirm the exact deployed version and whether the Classic Web Client is enabled. Zimbra says version 10.1.19 addresses a critical issue in the Classic Web Client where a crafted email could execute malicious code when opened, and recommends upgrading as soon as possible.

Patching is the first move, not the final one. Teams should also review unusual mailbox access and session activity, investigate unexpected changes to account settings, invalidate suspicious sessions, and use the indicators and monitoring guidance in the joint advisory.

• Inventory every internet-facing Zimbra instance and its version.
• Upgrade affected supported deployments to the latest vendor-approved release.
• Review proxy, webmail and authentication logs for anomalous access.
• Restrict administrative interfaces and remove unnecessary public exposure.
• Treat unexplained mailbox rules, settings changes or session reuse as investigation triggers.

The Beekeeper view

A clean TLS certificate and sensible security headers are valuable, but they cannot compensate for a vulnerable application release. External assurance should answer two separate questions: what is visible from the internet, and whether the visible software is being maintained quickly enough for the risk it carries.

The practical lesson is pleasingly unglamorous: know what you expose, know who owns it, and make patching public-facing systems an operational deadline rather than a hopeful calendar entry.