If you have wired an AI agent into your company email, your agent’s security is now exactly as good as your mail server’s patch schedule, and that is a scarier sentence than it sounds.
Here is what happened. CERT Polska, Poland’s national computer emergency response team, reported that attackers have started exploiting a critical flaw in Zimbra Collaboration Suite, tracked as CVE-2026-73570. The bug lives in the SNMP monitoring component. When SNMP notifications are enabled, an attacker who has not logged in at all can trigger a command injection weakness and run their own code on the server remotely. No password. No account. No clicking a bad link. Zimbra’s security team shipped version 10.1.20 on July 20 to fix it, and attacks are now live in the wild. The goal in these attacks is stealing login credentials.
Zimbra is email, calendar, and contacts software used by businesses and organizations around the world. So we are talking about the place where the actual messages live, not a browser plugin or a desktop app.
Why an email server bug is an AI agent problem
I write about agents for people who do not write code, so let me translate the architecture in plain terms.
An AI agent that handles your email does not have magical access to your messages. It connects the same way any email client does, using credentials or tokens that let it read, search, and often send. Those credentials sit somewhere, and the mailbox they unlock sits on a server. An agent is a very capable tenant in a building it does not own.
So when the building’s front door turns out to have a hole in it, three things follow:
- Stolen credentials are stolen agent access. Credential theft is the stated goal of this campaign. The same login details that let your assistant triage your inbox will let someone else read it.
- Your agent’s reading material becomes untrustworthy. Agents act on what they read. If an attacker can place or alter content inside a mailbox, they are feeding instructions to something designed to follow instructions.
- Agent logs become a map. Assistants summarize, label, and prioritize. That activity creates a convenient index of what matters most in an organization.
To be clear about what is confirmed and what is my analysis: the vulnerability, the active exploitation, the credential-theft goal, and the patch are reported facts. The agent implications are my reasoning about how these systems connect. There is no reporting that says agents were the target here.
The unsatisfying part
There is no public count of how many Zimbra instances have actually been compromised. We also do not know how many exposed systems are real production servers versus honeypots set up by researchers, or how many were already patched before the attacks began. That ambiguity is normal in the early days of an exploited flaw, and it is worth sitting with rather than filling in with guesses.
What it means practically: nobody can tell you whether you were hit by reading a news article. You have to go look.
What to actually do
If someone in your organization runs Zimbra, this is a short list and none of it requires you to be technical. It requires you to ask the right person the right questions.
- Ask what version you are on. The fix is 10.1.20, released July 20. Anything older than the patch needs attention.
- Ask whether SNMP notifications are enabled. That is the condition that makes this exploitable. If the monitoring feature is not needed, it does not need to be on.
- Rotate credentials, including the ones your agents use. Patching closes the door. It does not take back keys that were already copied. App passwords, API tokens, and service accounts for your assistant tools all count.
- Ask what your agent is allowed to do. Read-only access to specific folders is a smaller problem than send-on-your-behalf access to everything.
- Ask who reviews agent activity. If your assistant forwarded forty messages overnight, somebody should notice.
The boring lesson worth repeating
Most writing about agent security focuses on the model: how it is prompted, how it reasons, whether it can be tricked. That matters. But this incident is a reminder that agents sit on top of ordinary infrastructure, and ordinary infrastructure fails in ordinary ways. A command injection bug in a monitoring component is about as unglamorous as security gets. It also undoes every careful guardrail you put around your assistant, because it operates at a level underneath all of them.
Smart agent strategy includes patch management, credential rotation, and least privilege. Not because those things are exciting, but because an assistant with access to your inbox is one more reason the inbox has to hold.
🕒 Published: