Zimbra CVE-2026-73570 does not affect every Zimbra server in the same way. The documented vulnerable state applies to Zimbra Collaboration Suite versions before 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. Zimbra lists version 10.1.20 as the fix for this vulnerability.
Because CVE-2026-73570 has been actively exploited, administrators should answer two separate questions: is this server in the affected configuration? and, if it was exposed before remediation, is there evidence that it may already have been compromised? Installing a fixed version addresses the known vulnerable state going forward, but it does not by itself prove that no earlier exploitation occurred.
Zimbra CVE-2026-73570: the direct answer
A server is in the documented affected state when it is running Zimbra Collaboration Suite before 10.1.20, the optional zimbra-snmp package is installed and SNMP notifications are enabled. If all of those conditions apply, move to a vendor-fixed release and treat previous exposure as a separate incident-response question rather than assuming the patch proves the server was never compromised.
Which Zimbra servers are affected?
The version number is only one part of the exposure check. The vulnerability record describes a configuration-dependent command-injection path involving Zimbra’s optional SNMP package.
1. Is the server running a version before 10.1.20?
If no, the deployment is outside the documented pre-10.1.20 affected version boundary for CVE-2026-73570. Continue to verify the current vendor-supported security state rather than relying on this article alone.
2. Is the optional zimbra-snmp package installed?
If no, the documented SNMP-based command-injection condition is not present as described for this CVE. If yes, continue to the notification check.
3. Are SNMP notifications enabled?
If yes, and the server is also running a version before 10.1.20 with zimbra-snmp installed, the deployment meets the documented affected configuration.
4. Was the server exposed before remediation?
If the vulnerable state existed while active exploitation was occurring, patching should be followed by evidence review. Do not treat the new version number as proof that earlier compromise did not happen.
What fixes CVE-2026-73570?
Zimbra lists 10.1.20 as the release containing the fix for CVE-2026-73570. Administrators should compare their currently deployed release with the vendor’s current security guidance and upgrade through the supported Zimbra update path.
The current Zimbra Security Advisories page should control version and remediation decisions if the vendor later revises the affected or fixed-release information.
Why the SNMP configuration matters
A common mistake is to treat every server with an older Zimbra version as equally exposed to this specific vulnerability. The documented condition is narrower: the optional zimbra-snmp package must be present and SNMP notifications must be enabled.
This distinction matters operationally. An administrator should verify the actual package and configuration state rather than making an exposure decision from the product name or version alone.
Is CVE-2026-73570 being actively exploited?
Yes. Active exploitation was publicly reported before the September CERT-In advisory. CERT Polska warned about active exploitation in August, CISA later added the vulnerability to its Known Exploited Vulnerabilities catalog, and CERT-In subsequently stated that CVE-2026-73570 was being exploited in the wild.
The September CERT-In notice therefore strengthens the India-facing warning but should not be interpreted as the first global disclosure of exploitation.
Does patching prove the Zimbra server is clean?
No. Patching and compromise verification answer different questions.
- Patching: removes the known vulnerable state when the deployment is moved to the vendor-fixed release.
- Compromise verification: asks whether exploitation may already have occurred while the server was vulnerable.
If the server met the affected conditions before remediation, preserve relevant evidence before making unnecessary changes that could destroy useful incident-response information.
What evidence should be reviewed after possible exposure?
CERT Polska’s defensive guidance recommends reviewing relevant Zimbra logging, including /var/log/zimbra.log, for suspicious service-state activity and reviewing recently created files associated with the Zimbra account in relevant application or temporary locations.
These checks are investigation clues, not a universal clean-or-compromised test. The absence of one known indicator does not establish that exploitation did not occur.
No indicator does not mean clean. Known logs, files or behavioural indicators can help identify suspicious activity, but an attacker may leave different evidence or remove traces. Escalate unexplained findings through your organisation’s incident-response process.
What should administrators do now?
- Confirm the deployed Zimbra Collaboration Suite version.
- Check whether the optional
zimbra-snmppackage is installed. - Confirm whether SNMP notifications are enabled.
- If the documented affected conditions apply, move to a vendor-fixed release using current Zimbra guidance.
- If the server was exposed before remediation, preserve and review relevant logs and recent-file evidence.
- Escalate suspicious findings through the organisation’s incident-response process or the appropriate national CERT route.
Does the CISA KEV deadline apply to every organisation?
No. A CISA Known Exploited Vulnerabilities listing is important evidence that exploitation has occurred, but binding remediation requirements under the relevant U.S. federal directive apply to covered U.S. federal civilian agencies. TPS does not treat a CISA federal deadline as an automatic deadline for Indian private organisations or other non-covered entities.
Indian organisations should separately consider CERT-In guidance, their own regulatory obligations, contractual requirements and internal incident-response policy.
What CVE-2026-73570 can allow
The vulnerability can permit arbitrary operating-system command execution in the context described by the vulnerability record. That makes the issue materially more serious than a simple information-disclosure bug and is why configuration verification, patching and post-exposure review should be treated as separate steps.
This article does not provide exploit payloads, reproduction steps or offensive scanning instructions. The reader task is limited to defensive exposure assessment, remediation and evidence preservation.
What remains unresolved?
- The number of compromised organisations worldwide is not established by the reviewed primary sources.
- The number of affected or compromised organisations in India is unknown.
- A vulnerable configuration does not prove that a specific server was exploited.
- A patched configuration does not prove that earlier exploitation did not occur.
- The absence of currently documented indicators does not prove the server is clean.
- Campaign attribution and the complete scope of exploitation remain unresolved.
Verification method
ThePulseSignal reviewed Zimbra’s security release information, the CVE/NVD affected-state record, CERT Polska’s active-exploitation and defensive-investigation guidance, and CERT-In’s India-facing vulnerability note. The sources were reconciled to separate the original vulnerability and exploitation timeline from the later CERT-In advisory.
Frequently asked questions
Is every Zimbra server affected by CVE-2026-73570?
No. The documented vulnerable condition requires a Zimbra Collaboration Suite version before 10.1.20 together with the optional zimbra-snmp package and enabled SNMP notifications.
Which Zimbra version fixes CVE-2026-73570?
Zimbra lists version 10.1.20 as the release containing the fix for this vulnerability.
Is CVE-2026-73570 actively exploited?
Yes. Active exploitation was publicly reported in August 2026 and was later reflected in CISA KEV and CERT-In guidance.
If I upgrade to 10.1.20, is the server definitely clean?
No. Upgrading fixes the known vulnerable state, but a server that was exposed before the update may still require compromise assessment and incident-response review.
Does not finding a known indicator prove there was no attack?
No. Known indicators are useful evidence, but their absence is not proof that exploitation did not happen.
