Zimbra Collaboration SNMP Notification OS Command Injection

The repository contains a README and a standalone Python 3 proof-of-concept, poc_cve_2026_73570.py, for CVE-2026-73570. It is not tied to an exploit framework and uses only Python standard-library modules (argparse, smtplib, socket, ssl, sys, and time). The script first retrieves an SMTP banner, then submits raw SMTP MAIL FROM and crafted RCPT TO commands. The RCPT local part is designed to resemble a Zimbra 'Service status change' log event while embedding shell injection syntax. If Postfix records the recipient value in /var/log/zimbra.log, the claimed vulnerable zimbra-snmp swatchdog notification workflow matches that text and evaluates it through a shell command. The tool cycles through command-substitution, backtick, semicolon, and IFS-wrapped variants; it supports plaintext SMTP or STARTTLS, configurable target port/hostname, OOB DNS or HTTP callbacks, arbitrary commands, timing delays, transcript debugging, and a non-exploiting SMTP-banner check-only mode. Execution is claimed to occur asynchronously after swatchdog log polling and under the zimbra account rather than root.

The repository contains a single Python 3 executable (`CVE-2026-73570.py`) and a README describing a Zimbra SMTP command-injection PoC for CVE-2026-73570. The visible PoC performs a TCP scan of ports 25, 465, and 587, connects to a chosen SMTP service, issues EHLO and MAIL FROM, and submits a malformed quoted RCPT TO address containing `$(command)` within text designed to match Zimbra swatchdog service-status log patterns. The intended target-side effect is shell command execution if the recipient value reaches an unsafe shell-based swatchdog processing path. The README identifies zimbra-snmp, enabled SNMP notifications, and a running swatchdog process as prerequisites; it says SNMP itself need not be externally exposed. The script is not merely a scanner because it transmits the injection payload, although it has no execution-verification mechanism. Critically, before processing command-line arguments, `main()` invokes an obfuscated `x()` routine. That routine downloads an external script from one of two hardcoded raw.githubusercontent.com URLs, disables certificate validation for the request, writes the data to a temporary file, and executes it silently and detached. This local downloader behavior is unrelated to SMTP testing and makes the repository unsafe to run, as its remote payload can change at any time.

The repository contains a README and one Perl executable, zimbra-poc.pl. It is a standalone operational proof-of-concept rather than a Metasploit, Nuclei, or other framework module. The script accepts either a single hostname/IP or a line-oriented target file, supports configurable SMTP port, timeout, direct TLS, verbose session output, and optional local logging. It builds a single payload using the attacker-supplied callback address and reuses it against each selected target. The payload is a base64-obfuscated Bash reverse shell, injected in command substitution within a quoted SMTP RCPT TO local-part. The stated exploit chain is unauthenticated SMTP input reaching /var/log/zimbra.log, swatchdog recognizing a forged `Service status change` pattern, and an unsafe SNMP-notification handler executing attacker-controlled shell content as the zimbra user. The code and documentation indicate exploitation capability, not merely vulnerability detection. No fixed victim hostname, IP address, or callback endpoint is embedded; all network destinations are operator supplied.

Repository contains a single Python exploit script and a README. The main file, CVE-2026-73570.py, is a standalone low-level SMTP client implemented with raw sockets and optional implicit TLS for port 465. Its purpose is to bypass higher-level SMTP library validation and deliver a malformed RCPT TO address containing shell-style command substitution. The exploit flow is: scan common SMTP ports (25/465/587), connect to the selected SMTP service, send EHLO, send a benign MAIL FROM, then send a crafted RCPT TO payload of the form '"x: Service status change: localhost $(command) changed from stopped to running"@cve.invalid'. This is intended to poison server logs with text matching backend monitoring regexes so that a vulnerable downstream component executes the embedded shell command. The code itself does not implement a reverse shell or persistence; it is a command-injection delivery PoC with customizable attacker-supplied shell payloads via --command. The README explains the intended target as vulnerable Zimbra environments and describes the backend conditions required for exploitation: zimbra-snmp installed, snmp_notify enabled, and swatchdog running. It also documents OOB verification using HTTP callbacks (for example, curl to requestrepo.com) and mentions possible post-exploitation access to Zimbra data. Overall, this is a real exploit PoC, not merely a detector: it actively sends exploit traffic over SMTP and supports arbitrary command injection payloads, though payload handling is basic and user-supplied rather than framework-driven.

Repository is a small standalone Python proof-of-concept for CVE-2026-73570 affecting Zimbra Collaboration Suite. Structure is minimal: one executable Python script, a README, license, and .gitignore. The main file, CVE-2026-73570.py, implements an unauthenticated web-based command injection attempt against the Zimbra backup extension SNMP trap endpoint. It builds a payload by concatenating the configured SNMP IP with shell metacharacters and an attacker-supplied command, then sends it as the snmp_notify parameter in an HTTPS GET request to /service/extension/backup/snmptrap. The script includes a lightweight pre-check that requests the endpoint and treats any non-404 response as potentially reachable. It disables TLS verification and suppresses certificate warnings, indicating expected use against self-signed admin/web deployments. Success checking is basic: it looks for 'uid=' or HTTP 500 text in the response and otherwise instructs the operator to inspect /var/log/zimbra.log for traces. Capabilities are limited to single-command execution with a hardcoded payload format and default command ('id'), so this is best classified as OPERATIONAL rather than weaponized. README content is mostly generic boilerplate and donation material; it does not add exploit functionality.