# Remediation — CVE-2026-73570

> Xpectra Security Research · 2026-08-24
> Applies to: Zimbra Collaboration Suite < 10.1.20

## 1. Primary fix (do this)

**Upgrade to ZCS 10.1.20** (released 2026-07-20, the vendor's "permanent fix").

- Upgrade per the Zimbra upgrade guide for your current version line.
- The fix (commit `c4837c66` in `Zimbra/zm-build`) rewrites the `doSNMP()`
  notification path so the interpolated field is passed as **argv to system()**
  instead of being embedded in a **perl backtick** string — i.e. the text is no
  longer parsed by a shell.
- Unsupported older versions are not listed in the vendor advisory table but
  "often have the same vulnerabilities" (vendor note) — treat them as affected.

**Verification after upgrade** (authorized, 2 minutes):

```bash
# passive: version + sink
python3 detection/detect_snmp_sink.py --audit
# expect: NOT VULNERABLE per version (>= 10.1.20)

# active canary (only if the box is in authorized scope; one message, no shell)
python3 detection/detect_snmp_sink.py --active <mail-host> --local-canary
# expect: SINK DID NOT FIRE
```

## 2. Interim mitigation (if you cannot patch immediately)

In order of preference:

1. **Disable SNMP notifications** — removes the sink's trigger:
   ```bash
   su - zimbra -s /bin/bash
   /opt/zimbra/bin/zmlocalconfig -e snmp_notify=0
   /opt/zimbra/bin/zmcontrol restart zimbra-snmp   # or: zmcontrol restart
   ```
   Verify: `zmlocalconfig -s snmp_notify` → `0`; the watchfor no longer receives events.

2. **Stop the zimbra-snmp / swatchdog service** if SNMP monitoring is not used at all:
   ```bash
   su - zimbra -s /bin/bash
   /opt/zimbra/bin/zmcontrol stop zimbra-snmp
   ```
   (Document the change; restore after patching if SNMP monitoring is required.)

3. **Remove the vulnerable watchfor** from `/opt/zimbra/conf/swatchrc` (the
   `watchfor ... donotify SERVICE=$1...` block that feeds recipient text into the
   sink), then restart swatchdog. Keep a copy of the file. This is the surgical
   equivalent of the vendor patch for the lab S-B condition.

4. **Restrict the SMTP attack path** (reduces but does not eliminate exposure):
   - Trim `mynetworks` to localhost-only if remote SMTP submission is not required
     (affects relay; test with your mail flow first).
   - Require authenticated submission (587) and disable open relay — an
     unauthenticated path to the MTA is the AC:H precondition of the CVSS.

> None of 1-4 is a substitute for the upgrade; they reduce the window.

## 3. Detection (deploy now, independent of patching)

- **Sigma** (`rules/sigma/`): 5 rules — sink execution, /dev/tcp reverse shell
  as zimbra, logo tampering, RCPT attempt in mail logs, generic zimbra child
  anomaly. Import into your SIEM (Sentinel, QRadar, Splunk, Elastic, …).
- **YARA** (`rules/yara/`): mail-queue scan for `$(` in envelope recipients;
  zmswatch.out sink artifacts; PoC defacement banner.
- **Suricata** (`rules/suricata/`): SMTP `$(` attempt on the wire; high-port
  egress from mail servers.
- **Active self-test** (`detection/detect_snmp_sink.py`): quarterly canary
  validation that your detections + patching still hold.

## 4. If you suspect you are already compromised

1. Run `rules/` triage first (process tree, zmswatch.out, mail logs, banner hashes).
2. Follow `playbook-ir.md` (triage → containment → eradication → recovery).
3. Assume the `zimbra` user is compromised: full mailbox access, mail-injection
   capability (phishing from your domain), and a possible pivot to the host.
4. Report per your incident process; KEV listing means expect the same attack
   from the wild (CERT Polska 145/2026 documents active exploitation).

## 5. Monitoring after recovery

- Keep the Sigma/YARA rules deployed permanently (the attempt indicator N1/H-log
  fires even on patched hosts).
- Re-baseline the two `LoginBanner.png` hashes after the upgrade.
- Re-run the canary probe 30 days post-patch to close the loop.