> Кратко - вот повтор действий взлома

Да. Речь идёт о критической command injection уязвимости в SNMP-мониторинге Zimbra, исправленной в Zimbra Collaboration Suite 10.1.20, выпущенной 20 июля 2026 года.

Что именно происходит

Уязвимость находится в цепочке:

Zimbra → zmswatch / Swatchdog → обработка строк zimbra.log → SNMP notification/trap

Swatchdog (zmswatch) следит за zimbra.log и при определённых событиях, например изменении состояния сервиса, запускает действие для отправки SNMP trap. В штатной конфигурации соответствующие настройки находятся, в частности, в /opt/zimbra/conf/swatchrc.in, а рабочая конфигурация генерируется через zmsnmpinit.

Проблема заключается в том, что данные, попадающие в обрабатываемую Swatchdog строку, могли быть использованы для внедрения произвольной команды. Поэтому злоумышленнику потенциально достаточно добиться попадания специально сформированных данных в обрабатываемый Zimbra log — после чего уязвимый обработчик выполняет их в контексте процесса Swatchdog.

По опубликованным данным, эксплуатация возможна без аутентификации, если одновременно:

включены SNMP notifications;
работает интегрированный Swatchdog/zmswatch;
используется уязвимая версия Zimbra.

В таком случае последствия — выполнение произвольных команд ОС на сервере Zimbra, то есть фактически потенциальный полный компромисс почтового сервера.

Важный нюанс

Это не классическая уязвимость самого SNMP-протокола и не обязательно означает, что злоумышленник должен иметь доступ к UDP/161.

SNMP здесь является частью цепочки обработки событий. Сам Zimbra использует Swatchdog для наблюдения за логом и формирования SNMP-уведомлений; уязвимое место находится в обработке события/параметров перед вызовом команды. В старой документации Zimbra прямо описана схема, где zmswatch ищет в zimbra.log события вроде Service status change и при совпадении вызывает /opt/zimbra/snmp/bin/snmptrap.

Насколько всё серьёзно

Очень серьёзно. SecurityWeek характеризует её как critical и указывает, что неаутентифицированный атакующий может сформировать вредоносные данные для выполнения произвольных OS-команд в фоне.

При успешной эксплуатации атакующий потенциально получает возможность:

читать/изменять почтовые данные;
получить конфигурацию и секреты Zimbra;
закрепиться на сервере;
использовать сервер как точку дальнейшего проникновения;
компрометировать другие системы, доступные с Zimbra.

При этом официальный Zimbra пока не опубликовал CVE и CVSS для этой конкретной SNMP-уязвимости — на странице advisory они всё ещё обозначены как TBD.

Что делать

Основное решение — обновиться до Zimbra 10.1.20 или более новой версии. Именно в 10.1.20 Zimbra указывает permanent fix для этой проблемы.

Если обновление немедленно невозможно, разумная временная мера — отключить SNMP notifications/Swatchdog, если они не нужны. Например, в community advisory для производных Zimbra рекомендуются остановка zmswatch и отключение SNMP-сервиса; при этом обычная почтовая функциональность Zimbra не должна зависеть от SNMP.

Отдельно важно проверить логи, если сервер был доступен потенциальному атакующему до установки патча. На данный момент публичных подтверждений эксплуатации именно этой уязвимости in the wild не обнаружено, но Zimbra раскрыла технические детали намеренно ограниченно.