Zimbra SNMP-notification SMTP command-injection authority validation¶

CISA added CVE-2026-73570 to the Known Exploited Vulnerabilities catalog on August 21, 2026 (due 2026-08-24). The public record describes an OS command injection in Zimbra Collaboration Suite (ZCS) in the SNMP monitoring component when SNMP notifications are enabled: an unauthenticated attacker can send specially crafted SMTP requests that may execute arbitrary operating system commands as the Zimbra user. Fixed in ZCS 10.1.20. The durable operator pattern here is an optional-package feature gate crossed by an unauthenticated mail-protocol route: determine whether a live SMTP endpoint can reach a privileged monitoring-notification pipeline that was never intended to be internet-facing.

Primary records:

• Zimbra Security Advisories (vendor wiki)
• Zimbra 10.1.20 patch release announcement
• CVE-2026-73570 in NVD
• CISA KEV catalog

1. Establish scope and product identity¶

Record every approved ZCS authority before probing:

Do not infer ZCS from a generic mail banner alone. Preserve at least two product signals: an administrator-confirmed asset plus ZCS-specific SMTP/HTTP behavior, headers, package metadata, or admin-panel artifacts.

The two preconditions matter as much as the version. A deployment that is on an affected version but without the zimbra-snmp package or with notifications disabled does not match the published boundary. Record both states explicitly; "affected version, optional package unconfirmed" is a different claim than "affected version, package present, notifications enabled."

2. Discover the notification pipeline without guessing exploit routes¶

The public record identifies the SNMP monitoring component with notifications enabled, not a request path or wire payload. Derive the actual pipeline from approved sources:

1. owner-supplied admin configuration showing the SNMP notification target and trigger conditions, with secrets redacted;
2. authorized package inventory confirming the zimbra-snmp component and its service state;
3. server access or mail-gateway logs for a synthetic lab mail client; or
4. source/patch review for the exact deployed branch.

Record which mail event drives notification generation, which SMTP route a remote peer actually reaches, and whether any relay, proxy, or anti-milter sits in front. Redact credentials, SNMP community strings, mail content, and account names. Do not replay captured production mail or credentials.

This discovery step should produce a pipeline map, not a payload:

external SMTP authority
  -> relay / anti-milter / proxy (if any)
  -> ZCS SMTP endpoint (unauthenticated surface)
  -> mail event -> SNMP notification trigger
  -> notification component builds outbound SNMP/monitoring payload
  -> command execution sink (Zimbra user)

3. Build a route-reachability matrix¶

Use a protocol-valid, inert SMTP control (EHLO, NOOP, and an empty or minimally formatted RCPT/DATA sequence with a disposable lab address) against each approved authority. Compare:

Capture status codes, response banners, queue behavior, and any owner-confirmed notification-side artifacts (with content redacted). One control per approved authority is enough to establish reachability; avoid high-rate scanning of mail servers.

4. Instrument a denied notification sink in a disposable lab¶

Only when the assessment authorizes exploit-path validation, clone the affected architecture into an isolated lab with no production mailboxes, accounts, credentials, or network access. Patch or hook immediately before the notification component constructs its outbound payload and replace the real sink with a recorder that logs:

• the triggering mail event and its source route;
• the constructed command or payload string (hash it in evidence; do not store secrets);
• the intended SNMP/monitoring destination (sanitized);
• the user context the construction runs as; and
• a random inert marker.

The fixture must deny process execution, filesystem writes, and egress. Generate the marker locally; do not use a public RCE payload or public exploit sample.

Run affected and fixed builds (10.1.20) with the same recorder and controls. A bounded positive is:

unauthenticated synthetic SMTP event
  -> accepted on exposed SMTP route
  -> notification trigger reached with optional package installed
  -> patched recorder receives constructed payload
  -> fixed build rejects before that recorder

That proves the exposed command-construction boundary without execution. If the affected build rejects before the recorder, do not report RCE based only on version or the KEV entry.

5. Separate route exposure from application impact¶

Report the strongest observed boundary and no more:

Do not claim command execution, mailbox access, mail exfiltration, or local compromise unless separately proven under explicit lab authorization.

August 21 release context¶

The same 10.1.20 release also fixes, per the vendor wiki: a mail forwarding restriction bypass that could allow authenticated users to exfiltrate mail despite forwarding restrictions being enabled (CVE-2026-50055), a security issue in the EWS extension related to access controls (CVE-2026-10631), a mailbox delegation authorization issue (CVE-2026-50054), a server-side request forgery in the Nextcloud integration, and several stored XSS items in the Classic Web Client. These are recorded here only as release context; none of them is promoted to a separate operator workflow at this time.

Evidence bundle¶

Preserve:

ZCS authority and deployment class:
Version source and branch comparison (vs 10.1.20):
zimbra-snmp package state and source of confirmation:
SNMP notification state and configured target (redacted):
Reverse-relay-to-origin mapping:
Unauthenticated SMTP control response hash:
Lab-recipient control response hash:
Affected-build notification-sink recorder result:
Fixed-build notification-sink recorder result:
Denied sink list:
Observed claim:
Excluded stronger claims:

Keep credentials, SNMP community strings, and mail content out of screenshots and reports. Hash constructed payloads where full content is unnecessary, and include the exact lab build/image digest so the sink result can be replayed.

October 8 follow-up: Zimbra authorization-model legs promoted from release context (GHSA wave 2026-10-08T18:32Z)¶

The three legs this page previously carried only as release context now have full advisories, and each is a durable mail-platform authorization axis worth testing on any Zimbra (or delegation-capable mail) target in scope:

• GrantRightsRequest lets any authenticated account grant another account loginAs — persistent mailbox access that survives password changes and session expiry (GHSA-6c75-c59q-9624 / CVE-2026-50054, high). Durable rules: (1) grant/ delegate APIs are first-class privilege-escalation surfaces — test whether the grant call validates only the grantor's session rather than whether the grantor holds the right being granted; (2) capability-grant persistence is the report's headline, not read access — loginAs outlives credential rotation and session kill, so a phished lowest-tier mailbox becomes a standing backdoor into a chosen target account. Probe: on two lab accounts, attempt grant from an account that demonstrably lacks admin rights and diff success/error against a real-admin control.
• Disabled mail forwarding bypassed via Sieve notify action (GHSA-p88h-r6ph-r7j6 / CVE-2026-50055, medium) — users can still exfiltrate mail content and headers to arbitrary addresses. Generalizes to every platform where a policy disables one egress feature while a sibling feature with the same egress semantics stays enabled: enumerate all user-scriptable outbound mechanisms (Sieve notify/fileinto+fetcher, rules, webhooks, vacation-with-copy) and diff the policy's coverage per mechanism. Policy-name-vs-dataflow audit, not feature-name audit.
• EWS FindItem authorization bypass — any EWS-enabled user reads complete mailbox items (raw MIME + attachments) from arbitrary local accounts with no share or delegation (GHSA-7jfc-2g3q-h5mf / CVE-2026-10631, medium, 10.1.0–10.1.19). The recurring multi-protocol drift: the REST/webmail path enforces delegation checks the EWS handler never implements. Sweep rule for any mail product exposing EWS/ActiveSync/IMAP/REST families: run the same cross-mailbox read against each protocol entry point — one protocol's authorization is not the product's authorization. Version band is a passive fingerprint (EWS enabled + 10.1.x).
• Validation boundaries: two disposable lab accounts, synthetic marker mail only; prove cross-account read with your own canary mailbox content; never read real tenant mail; grant-leg proofs on lab tenants, revoke after.