Laundry Bear и CVE-2026-73570: под ударом ли ваша Zimbra

Учебный центр в Балашихе, 18 рабочих мест, свой почтовый сервер за стенкой. В пятницу 21 августа 2026 директор прочитал новость про массовые взломы Zimbra и написал мне: «мы же маленькие и в Балашихе, нас это вообще касается?». Приехал в субботу, проверил. Ответ вышел неудобным: дыра из заголовков их не касалась вовсе — а вот другая, о которой давно не пишут, касалась уже двадцать два месяца.

Начну с того, что вообще произошло. В пересказах две истории склеились в одну, и от этого у людей каша в голове — а лечатся они по-разному.

23 июля 2026 года CISA выпустила предупреждение по кампании группировки Laundry Bear, она же Void Blizzard. Публично её атрибутировали нидерландские спецслужбы ещё в мае 2025-го, после взлома нидерландской полиции годом раньше. Против Zimbra она работает в две руки: AiTM-фишинг с копиями страницы входа плюс эксплуатация CVE-2025-66376 — той самой XSS в классическом веб-интерфейсе, которую Zimbra закрыла 6 ноября 2025 года в версиях 10.0.18 и 10.1.13. Новых дыр в июльском тексте нет. Он про то, кто вас атакует и чем.

Отрасли пострадавших там перечислены прямым списком: оборонная промышленность, федеральные и местные органы власти, образование, энергетика, правоохранительные органы, СМИ, некоммерческие организации, ИТ-компании. Обратите внимание на «образование». Мой учебный центр попадает туда буквально.

Вторая история началась в августе и она чисто техническая. 20 июля вышла Zimbra 10.1.20 с исправлением CVE-2026-73570. Запись об уязвимости опубликовали 13 августа. В понедельник 17-го CERT Polska сообщил, что её уже эксплуатируют вживую. В пятницу 21-го CISA внесла её в каталог KEV и приказала федеральным агентствам США закрыться за трое суток, до 24 августа. К 22 августа Shadowserver насчитал 274 скомпрометированных сервера.

Отсюда простой, но важный вывод. Июльское предупреждение — не про CVE-2026-73570. Оно физически не могло быть про неё: записи тогда ещё не существовало. Это две волны одной большой темы «Zimbra смотрит наружу», и мешать их в кучу вредно.

А вот здесь новости врут чаще всего, и я сам чуть на этом не обжёгся.

Формулировка из бюллетеня дословно: из-за некорректной санитизации недоверенного ввода при обработке SNMP-уведомлений неаутентифицированный атакующий может отправить специально сформированные SMTP-запросы, что приводит к выполнению произвольных команд операционной системы от имени пользователя zimbra.

Читайте внимательно. Там действительно написано SMTP, а не SNMP, и это не опечатка пересказчика. Вход — через почтовый протокол, а выстреливает в обработчике SNMP-уведомлений: данные из письма доезжают до кода, который формирует уведомление, и там их не экранируют.

Пакета нет — вектора нет

Эксплуатация требует двух условий одновременно: установленного пакета zimbra-snmp и включённых SNMP-уведомлений. Пакет опциональный. Его ставят отдельно, обычно когда сервер заводят в систему мониторинга по SNMP — в Zabbix, в PRTG, в самописный опросник. В типовой установке компании на 20 человек его нет.

Это подтверждает и Shadowserver. Публикуя цифру про 274 взломанных инстанса, они отдельно оговорились: непропатченных видно порядка 8200, но это не значит, что все они эксплуатируемы, потому что уязвимость живёт в недефолтной конфигурации.

Скажу прямо, потому что честный ответ работает лучше нагнетания: скорее всего, конкретно эта дыра вас не касается. Проверить всё равно надо. Это одна команда и минута времени.

Исправление приехало в 10.1.20 от 20 июля, и затронутыми в записи числятся все версии ниже неё. Для тех, кто сидит на 9.0.0, формулировка означает не «дождаться патча в своей ветке», а планировать переход на 10.1. Разница огромная, и до неё я ещё дойду.

Отдельно про фразу, которая многих успокаивает зря.

Команды выполняются не от суперпользователя, а от учётной записи zimbra. Звучит мягко. Легче становится ровно настолько, насколько вам не жалко почту.

Потому что именно этому пользователю принадлежит всё существенное: /opt/zimbra/store с телами писем, индексы, каталог LDAP, конфигурация и утилиты zmprov, zmmailbox, zmlocalconfig. Атакующий с правами zimbra читает переписку любого сотрудника, выгружает глобальную адресную книгу, заводит себе ящик, ставит пересылку на внешний адрес, правит подписи. Ни одна из этих операций root не требует.

Разница между zimbra и root в другом — в том, что будет дальше. Повышение привилегий это отдельный шаг, и его делают почти всегда, потому что root даёт устойчивость: закладку в systemd, автозапуск, невидимость для обычного администратора. Дороги стандартные — локальный эксплойт под старое ядро, кривая строчка в sudoers, чужой каталог с правом записи, куда стреляет какой-нибудь сервисный юнит.

Я разбирал взлом, где путь до root лежал через безобидное на вид разрешение перезапускать nginx через sudo. От «читаю чужую почту» до «владею машиной» там прошли сутки. Так что «не root» — это про то, сколько у вас времени, а не про то, что можно расслабиться.

Паника лечится фактами о своей машине, а не чтением новостей. Четыре вещи, которые надо узнать прямо сейчас. Команды только читают, ничего не меняют.

# 1. установлен ли опциональный пакет
rpm -qa | grep zimbra-snmp          # RHEL/CentOS/Rocky
dpkg -l | grep zimbra-snmp          # Debian/Ubuntu

# 2. если пакет есть — включены ли уведомления
su - zimbra -c "zmprov gs $(zmhostname) | grep -i snmp"

# 3. версия и патч-уровень
su - zimbra -c "zmcontrol -v"

# 4. что реально торчит наружу
ss -tlnp | grep -E ':(25|80|443|7071|7025|10027) '

Первая строка ответит на девять из десяти вопросов, с которыми ко мне пишут после таких новостей. Обычно она пустая. И это хорошая новость, которую почему-то никто не сообщает.

Приехал в субботу 22 августа к десяти утра. Сервер стоит в комнате с кондиционером и штабелями методичек. Zimbra подняли в 2019 году на 8.8.15, в 2021-м подрядчик перевёл её на 9.0.0 и с тех пор трогал дважды — оба раза ради сертификата.

По дороге я уже набрал директору сообщение: «сейчас выключим SNMP-уведомления, и вопрос закрыт». Не отправил только потому, что въезжал в шлагбаум и отвлёкся. Повезло. Через двадцать минут выяснилось, что выключать было нечего.

[root@mail ~]# rpm -qa | grep zimbra-snmp
[root@mail ~]# echo $?
1

[zimbra@mail ~]$ zmcontrol -v
Release 9.0.0_GA_3924.RHEL7_64_20211118033954 RHEL7_64 FOSS edition, Patch 9.0.0_P23

Пакета нет. Значит, вектор CVE-2026-73570 на этой машине физически отсутствует — не потому что кто-то молодец, а потому что мониторинг по SNMP тут никогда не настраивали. Я позвонил и сказал прямо: та уязвимость, про которую вы прочитали, вас не касается.

Вторая проверка дала такой же ответ. CVE-2025-66376, которой пользуется июльская кампания, вендор закрыл в 10.0.18 и 10.1.13 — она живёт в десятых ветках, девятки в списке затронутых нет. Две громкие истории подряд, и обе мимо.

Так и оказалось. Patch 9.0.0_P23 — это осень 2022 года. А postjournal-RCE CVE-2024-45519 закрывается на девятой ветке патчем P41.

[zimbra@mail ~]$ zmlocalconfig | grep -i postjournal
postjournal_enabled = true

[zimbra@mail ~]$ ss -lntp | grep 10027
LISTEN 0 100 127.0.0.1:10027 0.0.0.0:*  users:(("postjournal",pid=2118,fd=6))

Служба включена, хотя журналированием почты здесь никто никогда не пользовался. Слушает она на петлевом интерфейсе, и это никого не спасает: команда приезжает обычным письмом через MTA, снаружи ничего открывать не требуется. Двадцать два месяца сервер простоял под уязвимостью, которую массово эксплуатируют с октября 2024 года — и про которую давно перестали писать заголовки.

Моя первая версия была неверной целиком. Я ехал закрывать SNMP, а закрывать надо было другое. Отправь я то сообщение из машины и уедь — клиент остался бы с ощущением, что всё в порядке. Это худший исход: не «уязвимы», а «уязвимы и уверены, что нет».

Порт 7071 при этом слушал на 0.0.0.0 и открывался из интернета без VPN. Подарок от подрядчика, который настроил и ушёл.

Дальше про то, что обновлением не лечится вообще. У июльской кампании две руки, и вторая — фишинг. AiTM-киты копируют страницу входа в Zimbra и снимают пароль вместе с сессионной кукой прямо в момент ввода. Вашей версии сервера этот сценарий безразличен: он работает против человека, а не против кода.

Инфраструктура кампании работала под доменами mailnalysis.com, emailanalytics.com.ua, zimbrastat.com, zimbra-metadata.com, istc-cloud.com и zmailanalytics.com. Все шесть мимикрируют под почтовую аналитику: расчёт на то, что глаз администратора по такому имени скользнёт.

# обращения к инфраструктуре кампании
grep -aiE 'mailnalysis|zimbrastat|zimbra-metadata|zmailanalytics|istc-cloud' \
  /opt/zimbra/log/mailbox.log* /var/log/messages* 2>/dev/null

# рекомендация CERT Polska: свежие файлы от пользователя zimbra за 30 дней
find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp \
  -user zimbra -mtime -30 -type f -ls

Второй индикатор от польского CERT — служба Zimbra перезапускается сама, без вашего участия. В /opt/zimbra/log/zmmailboxd.out такие рестарты видно. Списывать их на «ну она иногда падает» — плохая привычка, я так однажды потерял неделю.

Ловушка с паролями приложений

А это то, чего почти никто не проверяет. Эксплойт июльской кампании не просто уносит письма. Он создаёт и отправляет наружу новый пароль приложения — тот, которым пользуются старые клиенты вроде IMAP и ActiveSync, не умеющие в TOTP. Такой пароль работает мимо двухфакторки.

Дальше предсказуемо. Вы меняете пароль, включаете 2FA, отчитываетесь директору. А доступ у атакующего остался: вы поменяли не то.

# выданные пароли приложений у ящика
su - zimbra -c "zmprov ga user@example.ru zimbraAppSpecificPassword"
# в предупреждении отдельно просят отзывать passcode с именем ZimbraWeb

Что утекает при удачной эксплуатации, тоже расписано: последние 90 дней переписки, адрес ящика, пароль, глобальная адресная книга и токены 2FA. Каналов выгрузки два — мелочь кодируется в DNS-запросы A-записей, крупное уходит архивами по HTTPS на сборщик под именем Flowerbed. DNS-канал важнее, чем кажется: он проходит там, где исходящий HTTPS уже фильтруют.

Теперь главный аргумент, который я слышу от каждого второго директора: взламывают банки и министерства, кому нужен наш учебный центр.

Массовая эксплуатация устроена не так. Никто не составляет список жертв. Запускается сканер по всему интернету, он отвечает на единственный вопрос — уязвимая версия или нет, — и дальше эксплойт отрабатывает автоматически по каждому совпадению. Сканеру безразлично, вы госкорпорация или восемнадцать человек в Балашихе.

Августовские цифры показывают это буквально. Shadowserver видит снаружи больше 12 100 доступных серверов Zimbra: 4382 в Европе, 4492 в Азии. Непропатченных из них порядка 8200. Скомпрометированных на 22 августа — 274. Это не 274 выбранные цели, это 274 машины, по которым сканер прошёл раньше, чем администратор дошёл до обновления.

История повторяется с расписанием пригородной электрички. В октябре 2022-го на одной zero-day в Zimbra набралось около 900 взломанных серверов по миру. Другой год, другая уязвимость, механизм тот же.

Есть и вторая причина, о которой малый бизнес не думает вовсе. Взломанный сервер небольшой компании ценен не сам по себе, а как плацдарм. С него рассылают фишинг вашим же контрагентам от вашего имени — и такое письмо проходит все фильтры, потому что домен настоящий, подпись настоящая, история переписки настоящая. Для учебного центра это значит рассылку своим же слушателям. По репутации бьёт сильнее любого простоя.

Когда директор понял масштаб, первый порыв был знакомый: обновите срочно всё. Понятный порыв и неправильный — наскоком на боевой почте ломают больше, чем чинят. Порядок такой.

1. Выяснить, есть ли у вас вообще SNMP-вектор. Первая команда из блока выше. Пакета нет — пункт закрыт навсегда, дальше про него не думаем.
2. Сузить периметр сегодня. Админ-консоль 7071 — за VPN или в белый список. Сорок минут работы, без перезапуска почты и без согласований.
3. Прикрыть то, что реально открыто. Для девятки ниже P41 это postjournal: журналирование почты почти никому не нужно, а служба включена.
4. Проверить, не поздно ли. Индикаторы из предыдущего раздела, отзыв лишних паролей приложений, просмотр правил пересылки у всех ящиков. Патч на уже взломанный сервер закрывает дверь, но не выгоняет того, кто внутри.
5. Снять бэкап и проверить восстановимость. Не «бэкап есть», а «я развернул его на отдельной машине, и почта поднялась». Это два разных утверждения, и второе почти никогда не проверено.
6. Только потом обновляться.

# затычка на postjournal, если апгрейд не сегодня
su - zimbra -c "zmlocalconfig -e postjournal_enabled=false"
su - zimbra -c "zmmtactl restart"

# если пакет zimbra-snmp всё-таки стоит, а мониторинг по SNMP не используется
su - zimbra -c "zmprov ms $(zmhostname) -zimbraServiceEnabled snmp"
su - zimbra -c "zmcontrol restart"

И вот здесь популярный совет из интернета вредит сильнее всего. «Просто обновись до последней версии» — так пишут люди, никогда не обновлявшие боевую Zimbra. Под сервером учебного центра стоит CentOS 7.9, снятый с поддержки в июне 2024 года. Zimbra 10.1 на него не встаёт: у десятой ветки другая матрица поддерживаемых операционных систем.

То есть «поставить патч» на практике означает поднять новую машину на поддерживаемой ОС, перенести туда почту, домены, LDAP, сертификаты и фильтры, а потом переключить MX. Это не патч. Это переезд, и планировать его надо как переезд.

Считаю в часах, без страшилок. Субботнее утро ушло на периметр и проверку: закрыли 7071, выключили postjournal, прошли по индикаторам, отозвали два старых пароля приложений и разобрали правила пересылки во всех восемнадцати ящиках. Четыре часа. Следов кампании не нашлось, и это единственная по-настоящему хорошая новость того дня.

Переезд на 10.1.20 на новой операционной системе поставили в план на сентябрь: 18 ящиков, 142 ГБ в store, по опыту это 25–30 часов работ и одно ночное окно на переключение MX. Стоимость такого проекта у нас сопоставима с двумя месяцами обслуживания их парка.

Другая сторона арифметики. У другого клиента разбор заражения Zimbra и переезд на заведомо чистый контур занял 28 часов только технической работы — плюс неделю переписки с контрагентами, которым с их адреса ушёл фишинг, и объяснений, почему письмам от компании теперь надо не доверять сходу. Второе оказалось дороже первого, и заметно.

Что из этого следует вам. Не бросайтесь выполнять советы из новостей: половина из них про конфигурацию, которой у вас нет, а убивает обычно не свежая дыра из заголовков, а позапрошлогодняя, о которой все забыли. Начните с четырёх фактов про свой сервер — есть ли пакет, включены ли уведомления, какой патч-уровень, что слушает наружу.

Пришлите мне вывод этих четырёх команд: rpm -qa | grep zimbra-snmp, zmprov gs $(zmhostname) | grep -i snmp, zmcontrol -v и ss -tlnp. За день отвечу конкретно: касается ли вас августовская история, касается ли июльская, что закрывать сегодня, а что можно спокойно поставить в план на осень.

У нас нет пакета zimbra-snmp. Значит, можно ничего не делать?

По CVE-2026-73570 — да, этот вектор у вас закрыт, и я не буду делать вид, что это не так. Но проверьте остальное, и не по новостям, а по своему патч-уровню. Июльская кампания Laundry Bear эксплуатирует другую уязвимость — CVE-2025-66376 в классическом веб-интерфейсе, закрытую в 10.0.18 и 10.1.13. Если вы на девятке или на 8.8.15, эта конкретная дыра тоже мимо, зато у вас с высокой вероятностью открыт postjournal: CVE-2024-45519 закрывается патчами 9.0.0 P41 и 8.8.15 P46, а эксплуатируют её с октября 2024 года. И отдельно посмотрите, что торчит наружу: админ-консоль на 7071, открытая в интернет, страшнее любого свежего CVE, потому что не требует эксплойта вообще.

Что вообще такое SNMP-уведомления в Zimbra и откуда они берутся?

SNMP — старый протокол мониторинга, а уведомления по нему шлют оповещения о событиях сервера в систему сбора. В Zimbra это отдельный опциональный пакет zimbra-snmp: его выбирают руками во время установки или доставляют потом, когда сервер заводят в мониторинг. Сам по себе он не зло. В типовой установке небольшой компании его просто нет — поэтому уязвимость и живёт, как выразился Shadowserver, в недефолтной конфигурации. Если пакет стоит, а SNMP вам не нужен, снимите сервис с хоста через zmprov ms и перезапустите Zimbra: вектор уйдёт до апгрейда.

Написано, что команды выполняются от пользователя zimbra, а не от root. Это ведь не так страшно?

Страшно ровно настолько, насколько вам дорога почта. Пользователю zimbra принадлежат /opt/zimbra/store с телами писем, индексы, LDAP и утилиты zmprov и zmmailbox. С такими правами читают переписку любого сотрудника, выгружают адресную книгу, ставят пересылку на внешний ящик. Root для этого не нужен. Root нужен для устойчивости — чтобы закрепиться в systemd и пережить перезагрузку, и это отдельный шаг, который делают следом. Я видел взлом, где от «читаю почту» до полного контроля над машиной прошли сутки, а мостиком послужила одна строчка в sudoers.

Насколько срочно надо шевелиться?

Зависит от того, что показали четыре команды, и разделять эти ситуации важнее, чем бежать во все стороны сразу. Если пакет zimbra-snmp стоит, уведомления включены и версия ниже 10.1.20 — это работа на сегодня, без обсуждений: CISA дала своим агентствам трое суток, а Shadowserver на 22 августа насчитал 274 скомпрометированных сервера. Если пакета нет, но ветка 10.0 ниже 10.0.18, 10.1 ниже 10.1.13 или девятка ниже P41 — это работа на ближайшую неделю. Если и с этим порядок, остаётся плановое обновление, и его нормально поставить на месяц вперёд.

У нас нет своего админа. С чего начать?

С четырёх команд из раздела «проверьте у себя за 2 минуты». Их запустит любой, у кого есть доступ к серверу: одна показывает пакет, вторая — состояние SNMP, третья версию и патч-уровень, четвёртая слушающие порты. Ничего не меняется, сломать нечем. Пришлите мне вывод — за день скажу, какая из двух историй вас касается и в каком порядке закрывать. Отдельно предупрежу про грабли, на которые тут наступают чаще всего: если под Zimbra стоит CentOS 7, обновление до 10.1 будет не патчем, а переездом на новую машину, и об этом лучше узнать заранее, а не в ночь работ.