Every email platform has vulnerabilities. Open source, open core, proprietary: none are exempt, and none ever will be.
So asking how many CVEs a platform has tells you remarkably little about how secure your environment actually is. The more useful question is what happens after a vulnerability is found.
How quickly does the vendor assess it and make a fix available? And once that fix exists, how quickly can your organisation get it into production?
Those are two different responsibilities. Together, they determine something far more meaningful than a CVE count: how long your organisation remains exposed.
A vulnerability starts two clocks
The first clock belongs largely to the vendor: assess the issue, determine what is affected, develop and test a fix, and publish enough information for customers to act.
The second belongs to the organisation: know the fix exists, determine whether it applies, prioritise it, deploy it and verify that the exposure has been closed.
A fast vendor response cannot protect an organisation that doesn’t deploy the fix. And the fastest security team cannot install a fix that isn’t available for the version it is running.
That makes vulnerability response a shared responsibility. A vendor should publish actionable advisories, assess vulnerabilities in the context of how its product is actually deployed, and make fixes available quickly. The organisation needs to stay current and maintain the operational capability to act.
The CVE isn’t the interesting part. The interval is.
CVE counts are easy to compare. That doesn’t make them a good measure of security. A large published record often reflects scrutiny and transparent disclosure, and the number says very little about what happened in your environment.
The questions that matter are more practical. Was the affected component deployed? Was it reachable? Was a fix available? And how long did you remain exposed before applying it?
Take our own record. Vulnerability Monitoring and Patch Readiness whitepaper examines all 19 Zimbra Collaboration vulnerabilities in the exploited-vulnerability catalogue. In every case, a fixing release had been published before exploitation was catalogued. Seven were catalogued at least a year after the fix, and two more than six years after.
The lesson isn’t that vulnerabilities existed. Every serious platform will have them. The lesson is that fixing the software and fixing the deployment are two different events.
Same software, different security posture
Two organisations can run the same software and carry very different levels of exposure.
One may have removed unnecessary components, restricted administrative access, monitored its environment and maintained a tested upgrade path. Another may run the same version with old configuration, unused components still installed, and no defined path for an emergency change.
Our companion whitepaper, Securing a Zimbra Environment, explains why posture can’t be inferred from a version number alone: configuration persists through upgrades, so two systems on the same release can carry materially different security postures.
So there are two shortcuts worth abandoning:
A version number doesn’t tell you your security posture.
A CVE count doesn’t tell you your security posture either.
What matters is what’s exposed and how long it stays exposed when a vulnerability is found.
What readiness actually looks like
Closing the second clock is rarely just a technical problem.
Fast remediation depends on decisions made beforehand. Who can authorise an out-of-cycle change? Has the rollback path been tested? Is there an environment to test in? Can maintenance windows move? Is the organisation entitled to install the fix the day it becomes available?
None of these can be arranged in the middle of an incident. All of them can be settled now.
The most recent case in our record shows why this matters. A fix was published on 20 July 2026. Active exploitation was first reported on 17 August. An organisation monitoring the release in July had roughly four weeks to assess, test and deploy before then. One that learned about it from the news had none.
Measure your own interval
You can’t control when the next vulnerability will be discovered. But you can control much of what happens next.
So instead of asking, “How many CVEs does this platform have?”, ask:
“When the next vulnerability is found, how quickly can we determine whether we’re exposed, get the fix into production and verify that the risk is closed?”
If you can’t put a name and a timeframe against that process today, that may tell you more about your security posture than any CVE count ever will.
How ready are you for the next vulnerability?
Security posture isn’t defined by a version number or a CVE count. It’s shaped by two things: how much of your environment is exposed, and how quickly you can respond when that exposure becomes vulnerable.
If you’re looking to improve vulnerability readiness, Vulnerability Monitoring and Patch Readiness outlines a practical five-stage approach to baseline, monitor, triage, remediate and verify, along with a 16-question assessment you can use to evaluate your own processes.
If you’re focused on reducing exposure before a vulnerability appears, Securing a Zimbra Environment provides guidance on hardening configuration, reducing attack surface and reviewing security-critical settings across a deployment.
Download the whitepapers:
No comments yet.