Обновлено 6 октября 2026 года. Команда Zammad выпустила версию 7.2.1 как срочное обновление безопасности. Для клиентов облачного Zammad SaaS действий не требуется: поставщик сообщает, что его инстансы уже исправлены. А вот компаниям, которые держат helpdesk на собственном сервере, откладывать обновление не стоит.
Это не история о косметическом баге в интерфейсе. В системе заявок обычно лежат переписка с клиентами, телефоны и почта, вложения, история обращений и заказов, а иногда — параметры почтовых каналов и других интеграций. При успешной атаке последствия могут выйти далеко за пределы одного «странного» тикета.
Что произошло
Zammad 7.2.1 закрывает набор критических проблем, затрагивающих разграничение доступа, сессии, автоматизации и отображение данных. Среди исправленных классов уязвимостей — раскрытие и захват тикетов между организациями, обход многофакторной аутентификации через цепочку проверки email, удалённое выполнение кода через обход защиты шаблонов в настройках автоматизации, сохранённые XSS-атаки, утечки данных заявок и показ сохранённых учётных данных каналов в открытом виде.
Для бизнеса это означает вполне приземлённые риски: посторонний может увидеть обращения не своей организации, получить лишние сведения о клиентах или сотрудниках, закрепиться в учётной записи, а в некоторых сценариях — добраться до сервера. Helpdesk часто воспринимают как «внутренний ящик обращений», хотя фактически это концентратор чувствительной операционной информации.
Отдельное уведомление нидерландского центра DIVD описывает две CVE. По данным DIVD, CVE-2026-102489 позволяет захват сессии с последующим выполнением кода от имени пользователя zammad в версиях 6.3.0–6.5.4. Проблема также присутствовала в ветке 7.0.0–7.1.3, но, как подчёркивает DIVD, в этих версиях не эксплуатировалась из-за условий окружения. Это существенная оговорка: нельзя одинаково описывать риск для всех версий.
Вторая проблема, CVE-2026-102490, по информации DIVD, затрагивает все версии Zammad, включая alpha, и может позволить локальному пользователю zammad повысить права до root. В связке такие недостатки особенно опасны: внешний доступ к приложению и локальное повышение привилегий могут стать ступенями одной атаки.
Кому нужно действовать прямо сейчас
- Пользователям Zammad SaaS достаточно убедиться, что речь действительно идёт об облачном сервисе Zammad, а не о сервере подрядчика или собственной виртуальной машине. По заявлению Zammad, SaaS-инстансы уже защищены.
- Владельцам self-hosted-инсталляций нужно запланировать и выполнить обновление до актуального релиза 7.2.1 без лишней паузы. Это относится к установкам на собственных серверах, в облаке, Docker-инфраструктуре и у хостинг-провайдера, если обновления не выполняет сам поставщик сервиса.
- Командам без быстрого окна на обновление следует временно ограничить внешний доступ к helpdesk и привлечь системного администратора или специалиста по информационной безопасности. Это временная мера, а не замена патчу.
Что сделать после обновления
Обновление закрывает известные точки атаки, но не доказывает, что до него никто не получил доступ. Если сервер был доступен из интернета, проверка следов компрометации нужна наравне с установкой патча.
- Зафиксируйте текущую версию, сделайте резервную копию базы данных и конфигурации по внутреннему регламенту. Резервную копию нельзя оставлять в открытом веб-каталоге или на том же единственном сервере.
- Установите Zammad 7.2.1 штатным способом для вашей схемы развёртывания: пакетами, контейнером или средствами поддерживающего провайдера. После работ проверьте в панели администратора или средствами вашей инфраструктуры, что новая версия действительно запущена.
- Просмотрите журналы Zammad, веб-сервера и системы аутентификации: необычные входы, новые или долгоживущие сессии, массовые обращения к тикетам, ошибки авторизации, неожиданные действия под пользователем
zammad. - Проверьте настройки автоматизаций, триггеры, шаблоны, роли, группы, пользователей и MFA. Особого внимания заслуживают недавно созданные администраторы, изменённые права и правила, которые команда не может объяснить.
- Проверьте почтовые каналы, API-интеграции и подключённые сервисы. При признаках чужого доступа смените пароли, API-токены, ключи и другие секреты, связанные с каналами. Одного изменения пароля администратора здесь недостаточно.
- DIVD предлагает скрипт для поиска индикаторов компрометации в логах Zammad. Использовать такие средства лучше в рамках процедуры реагирования: сохраните исходные журналы до очистки и документируйте результаты проверки.
Почему это важно не только администраторам
Уязвимость helpdesk быстро становится проблемой всей компании. Через обращения в поддержку злоумышленник может собрать контакты, детали заказов, внутренние имена сотрудников и контекст для убедительного фишинга. После этого письмо «от службы поддержки» выглядит гораздо правдоподобнее — а значит, риски распространяются на клиентов, бухгалтерию, менеджеров и подрядчиков.
Не стоит делать вывод, что взломаны все self-hosted-серверы Zammad или что массовая эксплуатация подтверждена. Таких данных в опубликованных сообщениях нет. Однако официальный выпуск с критическими исправлениями и описание цепочки атак DIVD — достаточная причина относиться к задаче как к приоритетной.
Что пока неизвестно
Публичные материалы не позволяют определить, была ли конкретная self-hosted-инсталляция атакована, только по её версии. Неизвестно и то, какие настройки, плагины, прокси и компоненты окружения могут менять практическую эксплуатируемость отдельных сценариев. Поэтому версия системы — это отправная точка, а не полноценное расследование.
Если в логах есть подозрительная активность, не удаляйте записи и не пытайтесь «починить всё» хаотичными правками. Ограничьте доступ к сервису, сохраните артефакты, смените скомпрометированные секреты и подключите специалиста по ИБ. При необходимости оцените обязанность уведомления клиентов и регуляторов с учётом применимого законодательства и политики компании.
FAQ
- Нужно ли обновляться пользователям Zammad SaaS?
Нет, Zammad сообщает, что его SaaS-инстансы уже исправлены. Но сначала стоит убедиться, что ваша система действительно обслуживается как SaaS поставщиком. - Достаточно ли установить патч?
Патч необходим, но он не отменяет проверку журналов, сессий, автоматизаций и секретов, если сервер был доступен извне. - Что особенно опасно в CVE-2026-102489?
DIVD указывает на эксплуатируемую цепочку захвата сессии и выполнения кода в версиях 6.3.0–6.5.4. Для 7.0.0–7.1.3 проблема присутствовала, но DIVD не считает её эксплуатируемой из-за условий окружения. - Можно ли просто закрыть доступ из интернета и обновиться позже?
Ограничение доступа снижает риск как временная мера, но не заменяет обновление. Если быстро обновиться нельзя, это повод привлечь администратора и составить короткий план восстановления сервиса.