Zammad: две уязвимости попали в CISA KEV, но по их области действия есть расхождение с вендором
CISA 2 октября 2026 года внесла CVE-2026-102489 и CVE-2026-102490 в каталог известных эксплуатируемых уязвимостей. Основанием стала расследуемая компрометация инфраструктуры DIVD, где две проблемы Zammad были связаны в цепочку. При этом сам Zammad публично оспаривает часть выводов DIVD по области применимости и указывает, что не получил технических деталей второй уязвимости. Для защитников это тот случай, когда важно одновременно учитывать KEV и позицию производителя, не стирая расхождение между источниками.
Что произошло
DIVD сообщила, что 21 сентября 2026 года ее инфраструктура была скомпрометирована с использованием двух ранее неизвестных уязвимостей Zammad. Организация зарегистрировала CVE-2026-102489 и CVE-2026-102490 и начала отдельную кампанию уведомления владельцев уязвимых экземпляров.
CVE-2026-102489 описана как проблема фиксации сеанса, которая на Zammad 6.3.0–6.5.x может привести к выполнению кода с правами локального пользователя zammad. В CVE/NVD также упоминается наличие уязвимого кода в 7.0.0–7.1.3, но с оговоркой, что в этих версиях эксплуатация не реализуема из-за условий окружения.
CVE-2026-102490 описана DIVD и записью CVE как локальное повышение привилегий от пользователя zammad до root. CISA внесла обе уязвимости в KEV 2 октября и прямо указывает возможность их объединения в цепочку.
Кого касается
В первую очередь — организаций, которые продолжают использовать Zammad 6.5 и более ранние неподдерживаемые ветки, особенно при доступности системы из Интернета. Zammad рекомендует переход на текущую стабильную ветку и указывает, что выпуск 7.2.0 содержит дополнительное усиление кода, связанного с CVE-2026-102489.
По CVE-2026-102490 ситуация сложнее. В записи CVE и материалах DIVD указана широкая область действия старых версий, однако Zammad 1 октября заявил, что не получил от DIVD технических деталей этой проблемы и поэтому не может подтвердить ее точный механизм и охват. Это расхождение должно быть сохранено в оценке риска, а не замаскировано одной из сторон.
Почему это важно
Уязвимости систем обработки обращений особенно опасны из-за внешней доступности, большого количества пользовательского содержимого и связи с внутренними процессами поддержки. Если удаленная проблема позволяет получить исполнение кода с правами сервисной учетной записи, локальное повышение привилегий может превратить первоначальную компрометацию в полный контроль над узлом.
CISA считает обе CVE известными как эксплуатируемые и требует для своих федеральных ведомств судебно-технической проверки по правилам BOD 26-04. Одновременно позиция Zammad показывает, что техническая картина второй CVE еще не полностью согласована между исследователем и производителем.
Что важно проверить
- Определить точную версию Zammad и прекратить использование неподдерживаемых веток 6.x, если они еще присутствуют.
- Проверить, доступен ли Zammad из Интернета и какие административные интерфейсы открыты внешним пользователям.
- Сопоставить собственную версию с текущими рекомендациями Zammad и материалами DIVD, а не только с автоматическим сканером CVE.
- Проверить журналы аутентификации, новые и измененные учетные записи, процессы от пользователя zammad, изменения системных файлов и признаки выполнения команд с повышенными правами.
- Если система могла быть атакована, сохранить журналы и образ системы до переустановки или очистки.
Что делать
Zammad рекомендует обновиться до текущей стабильной версии 7.2.0. Для CVE-2026-102489 производитель прямо указывает, что версии 7.0 и новее практически не эксплуатируются указанным способом, а в 7.2.0 код дополнительно усилен.
По CVE-2026-102490 не следует делать вид, что спор между DIVD и Zammad уже разрешен. До появления согласованного технического описания необходимо применять консервативный подход: обновиться до текущей версии, минимизировать локальные права сервисной учетной записи, ограничить внешнюю поверхность и провести проверку ранее доступных систем.
Если обнаружены признаки компрометации, считать обновление только одним из этапов восстановления: сменить связанные секреты, проверить целостность операционной системы и зависимых сервисов и восстановить узел из доверенного состояния при необходимости.