Критична вразливість Zimbra CVE-2026-73570: зловмисники зламують поштові сервери одним листом

Zimbra Collaboration Suite — популярна платформа корпоративної пошти, якою користуються університети, державні установи, провайдери та бізнес у всьому світі, зокрема й в Україні. Наприкінці вересня 2026 року команда Microsoft Security Research опублікувала детальний розбір кампанії, у межах якої зловмисники активно експлуатують критичну вразливість CVE-2026-73570. Її головна особливість — для зламу не потрібні ані облікові дані, ані жодна взаємодія з користувачем: достатньо надіслати на сервер один спеціально сформований лист.

За даними фонду Shadowserver Foundation, у мережі зафіксовано щонайменше 274 зламані інсталяції Zimbra, а понад 8 200 серверів досі залишалися невиправленими. Вразливість уже внесено до каталогу Known Exploited Vulnerabilities (KEV) агентства CISA, що означає підтверджену активну експлуатацію «в дикій природі». Розберімося, як працює атака, хто під загрозою і що робити адміністраторам.

Що це за вразливість

CVE-2026-73570 — це неавтентифікована інʼєкція команд операційної системи (OS command injection) у механізмі SNMP-сповіщень Zimbra. Оцінка за шкалою CVSS 3.1 становить 8.9 (High): атака виконується по мережі, без автентифікації, з низькою складністю експлуатації та високим впливом на конфіденційність, цілісність і доступність.

Важливий нюанс: уразливість спрацьовує не в кожній інсталяції, а лише тоді, коли виконано дві умови одночасно:

1. встановлено опційний пакет `zimbra-snmp`;
2. увімкнено SNMP-сповіщення (SNMP notifications).

Це нестандартна конфігурація, яку використовують для інфраструктурного моніторингу. Однак на практиці вона зустрічається набагато частіше, ніж можна було б очікувати, — саме тому експлуатація набула такого масштабу. Уразливість закрито у версії Zimbra 10.1.20.

Чому Zimbra — постійна мішень

Це далеко не перша серйозна вразливість у Zimbra, і не випадково, що саме цю платформу атакують знову і знову. Самостійно розгорнутий поштовий сервер — це концентратор найцінніших даних організації: ділова переписка, облікові записи співробітників, токени скидання паролів для інших сервісів. Злам пошти часто означає доступ до всього іншого.

Лише за останній час платформа зазнала кількох резонансних атак. Наприкінці 2025 року виправлено вразливість zero-click-класу CVE-2025-66376 (stored XSS у класичному вебінтерфейсі), яку експлуатували державні угруповання, що спеціалізуються на кібершпигунстві. Загальна картина типова: адміністратори, які тримають пошту «на своєму залізі», нерідко відкладають оновлення — і саме такі відкладені патчі стають готовими точками входу для атакуючих.

Ця історія повторюється, бо опційні модулі на кшталт `zimbra-snmp` встановлюють «на всяк випадок» для моніторингу, а потім про них забувають. У підсумку неактивна, на перший погляд, функція перетворюється на відкриті двері.

Як працює атака (технічний розбір)

Ланцюжок експлуатації виглядає так. Зловмисник надсилає на відкритий у мережу сервер Zimbra спеціально сформований SMTP-запит, у якому містяться символи оболонки (shell metacharacters). Через недостатню санітизацію вхідних даних цей небезпечний вміст потрапляє в обробник SNMP-сповіщень.

Коли на сервері змінюється стан якоїсь служби й спрацьовує моніторинг здоровʼя, процес swatchdog підставляє контрольоване зловмисником значення у виклик оболонки `snmptrap`. У підсумку команди виконуються від імені службового облікового запису zimbra — без пароля, без входу в систему і без жодних дій з боку користувача.

Тобто сам моніторинговий інструмент, який мав повідомляти про проблеми, натомість запускає код атакуючого. Це класичний приклад того, як вторинна функція (сповіщення по SNMP) стає точкою проникнення в систему, яка роками працює і не викликає підозр.

Хто під загрозою та масштаб кампанії

Під загрозою будь-яка організація, яка тримає Zimbra на відкритому в інтернеті сервері у версії, старшій за 10.1.20, із встановленим `zimbra-snmp` та ввімкненими сповіщеннями. Zimbra часто обирають навчальні заклади, держустанови, медіа та середній бізнес — ті, хто хоче мати «свою пошту» замість хмарних сервісів.

Фонд Shadowserver Foundation, який сканує інтернет, зафіксував зростання кількості зламаних інсталяцій із приблизно 155 (20 серпня) до щонайменше 274 (22 серпня), і цей рівень утримувався без помітного зниження. Кількість досі невиправлених, потенційно вразливих серверів оцінювалася більш ніж у 8 200.

21 серпня 2026 року CISA внесла вразливість до каталогу KEV із дедлайном виправлення для федеральних установ США — 24 серпня. Це підтверджує, що мова йде не про теоретичну загрозу, а про реальні, тривалі атаки на поштову інфраструктуру. Першим на кампанію звернув увагу польський CERT Polska. На момент публікації розбору Microsoft конкретне угруповання, що стоїть за атаками, офіційно не атрибутовано.

Що зловмисники роблять після зламу

Отримавши виконання команд, атакуючі переходять від автоматизованої доставки пейлоадів до «ручної» роботи на сервері. Дослідники Microsoft зафіксували такий арсенал дій:

• Веб-шелли. Зловмисники розгортали JSP-веб-шелли одразу в кількох шляхах застосунку — Jetty та mailboxd — для надлишковості. Подекуди вони тимчасово відкривали запис у публічну директорію, розміщували шелл і повертали права назад, щоб базова перевірка дозволів нічого не помітила.
• Ескалація привілеїв. Через зміну `/etc/pam.d/sudo` обліковому запису zimbra надавали необмежений sudo без пароля (NOPASSWD: ALL).
• Персистентність. Створювали systemd-юніт з іменем `zimlog.service` (зовні схожий на легітимний), cron-завдання, а також виконували код у памʼяті через `memfd_create`.
• Горизонтальне переміщення. Використовували наявний SSH-ключ Zimbra за шляхом `/opt/zimbra/.ssh/zimbra_identity` та rsync, щоб поширювати інструменти на інші вузли кластера.
• Крадіжка секретів. Замість перебору паролів окремих скриньок зловмисники забирали централізовані секрети через `zmlocalconfig -s`: `zimbraPreAuthKey`, `zimbraAuthTokenKey`, `zimbraTwoFactorAuthSecret`. Це дозволяло далі автентифіковано читати пошту та обходити двофакторну автентифікацію.
• Стійкий віддалений доступ. У щонайменше одній кампанії використано завантажувач, що встановлює Go-бінарник Zimclient2 — агент віддаленого доступу з інтерактивною оболонкою, двосторонньою роботою з файлами та SOCKS5-проксі (підтримка WebSocket, TLS і «сирого» TCP).

Зібрані дані (пошта, облікові та сесійні матеріали) пакували в архів і вивантажували на зовнішню інфраструктуру. Тобто наслідком зламу є не лише втрата доступу до сервера, а й потенційний витік корпоративної переписки.

Хронологія: патч, розвідка, розкриття

Часова шкала цієї історії показова:

• 20 липня 2026 — Zimbra випускає виправлення у складі версії 10.1.20.
• 28 липня – 7 серпня — ще до публічного розкриття Microsoft фіксує два окремі інструменти сканування, які «пробують» точку інʼєкції та підтверджують виконання команд через out-of-band-дзвінки.
• 13 серпня — вразливість публічно розкрито.
• 21 серпня — CISA вносить CVE-2026-73570 до KEV.

Цей патерн — розвідка у «вікно» між виходом патча і розкриттям — ще раз нагадує: оновлення потрібно ставити одразу, не чекаючи на резонанс у новинах.

Як захиститися

Головна і безальтернативна рекомендація — оновити всі інсталяції Zimbra до версії 10.1.20 або новішої. Якщо оновлення доведеться відкласти, Microsoft радить тимчасово прибрати поверхню атаки:

1. Видалити опційний пакет `zimbra-snmp`.
2. Вимкнути SNMP-сповіщення.
3. Обмежити доступ по SNMP та SMTP лише довіреними хостами (файрвол).

Також обовʼязково замінити (ротувати) секрети автентифікації Zimbra — передусім `zimbraPreAuthKey`, `zimbraAuthTokenKey` і `zimbraTwoFactorAuthSecret`, оскільки вони могли бути скомпрометовані ще до оновлення. Варто окремо перевірити, що сервер актуальний і щодо іншої нещодавньої вразливості Zimbra (CVE-2025-66376), яку закрито в 10.1.13/10.0.18, — адміністратори часто патчать одну діру й забувають про іншу.

Якщо поштові облікові дані могли постраждати, користувачам варто перевірити, чи не опинилися їхні адреси та паролі у відомих витоках — це можна зробити через безкоштовну перевірку на cyberpeople.tech.

Окрім точкового патча, варто переглянути саму архітектуру поштової інфраструктури за принципом defense in depth. По-перше, поштовий сервер не повинен бути безпосередньо відкритий в інтернет, якщо цього можна уникнути: розумним рішенням є розміщення його за проксі або шлюзом з фільтрацією пошти. По-друге, мережевий доступ до служб управління (SSH, адмін-панель, SNMP-порт) слід обмежити лише внутрішньою мережею або VPN. По-третє, корисно регулярно перевіряти список встановлених пакетів і вимикати те, що реально не використовується, — це скорочує поверхню атаки на майбутнє.

Як перевірити, чи сервер уже зламано

Патч закриває діру, але не прибирає те, що зловмисники могли залишити: веб-шелли, sudoers-записи чи systemd-юніти. Будь-який сервер, що був відкритий у мережу й працював на версії нижче 10.1.20, слід вважати потенційно скомпрометованим і перевірити за чеклістом:

• Переглянути `/var/log/zimbra.log` на предмет підозрілих рестартів служб Zimbra.
• Пошукати несподівані JSP-файли в директоріях застосунків (Jetty webapps, mailboxd), у `/tmp`, а також згенеровані `*_jsp.java` або скомпільовані сервлети.
• Перевірити `/etc/sudoers` та вкладені файли на наявність NOPASSWD-запису для zimbra.
• Перевірити `/etc/pam.d/sudo` на сторонні хуки (`pam_exec`).
• Переглянути systemd-юніти на незнайомі служби, особливо з іменами, схожими на Zimbra або «логінг» (приклад — `zimlog.service`).

Памʼятайте: знайти й видалити один шелл недостатньо — як правило, їх кілька, і вони дублюються на різних вузлах кластера.

Що це означає для звичайних користувачів

Навіть якщо ви не адмініструєте поштовий сервер, ця вразливість стосується і вас. Якщо ваш роботодавець, університет чи поштовий провайдер тримає пошту на Zimbra, злам сервера означає, що зловмисники могли отримати доступ до чужої — зокрема й вашої — переписки та облікових даних. І оскільки атака не вимагає жодних дій з боку користувача, жодна обережність не захистить від неї: рішення лежить цілком на боці адміністратора.

Що можете зробити ви: увімкнути двофакторну автентифікацію на поштовому акаунті (вона ускладнює використання вкрадених секретів), стежити за підозрілими повідомленнями про вхід в акаунт, а також використовувати унікальні паролі для робочої пошти, щоб скомпрометований акаунт не потягнув за собою інші сервіси. Це базова гігієна, яка спрацьовує навіть тоді, коли інфраструктура навколо вас виявляється вразливою.

Висновок

CVE-2026-73570 — ще один нагадливий урок про те, що «непотрібний» опційний компонент може стати найслабшою ланкою. Поштовий сервер, який тримає корпоративну переписку та облікові дані, не має бути відкритий назовні без крайньої потреби, а кожен додатковий модуль (як-от `zimbra-snmp`) — це додаткова поверхня атаки.

Для адміністраторів діє простий алгоритм: оновитися до 10.1.20+, прибрати або ізолювати SNMP, замінити секрети автентифікації та провести перевірку на наявність веб-шелів і персистентних механізмів. Бо головне в такій атаці — не сам злам, а те, що залишається в системі після того, як діру залатали.