Двадцать четвёртого сентября 2026 года опубликован бюллетень Zabbix ZBX-28059 о множественных уязвимостях в Zabbix Agent 2. Эта программа работает на наблюдаемых хостах и передаёт метрики на сервер мониторинга. Проблемы затрагивают сборки Agent 2 старше версии 7.0.31. Код самой платформы здесь ни при чём: слабые места пришли из сторонних библиотек на языке Go, включённых в исполняемый файл агента. Всего в бюллетене перечислены двенадцать идентификаторов серии GO-2026.
Детали уязвимостей
Распределение по библиотекам неравномерное. Десять из двенадцати замечаний касаются golang.org/x/net - набора модулей для работы с сетевыми протоколами. Ещё по одному приходится на golang.org/x/text, который отвечает за кодировки и обработку текста, и на golang.org/x/sys, связывающий программу с системными вызовами операционной системы. Все три пакета развивает сообщество Go, а не компания Zabbix. Уязвимости попали в агент вместе с чужим кодом, который обновлялся слишком редко.
Находку оформили через систему отслеживания Zabbix. Сначала появился разбор зависимостей исполняемого файла агента, где рядом сведены установленные версии модулей и минимально допустимые. Затем представитель проекта подтвердил, что старые версии действительно попали в официальную сборку для Windows, а в 7.0.30 они сохраняются. Такой способ поиска слабых мест, то есть проверка состава готового файла, давно стал обычной практикой. Внешне исполняемый файл не выдаёт, какие библиотеки лежат внутри, поэтому список зависимостей приходится строить отдельно.
Полезно понимать, за что отвечают эти модули. x/net закрывает работу с HTTP, DNS, веб-сокетами и разбором сетевых пакетов. x/text занимается кодировками, нормализацией строк и языковыми настройками. x/sys даёт доступ к системным вызовам и управлению процессами. Ошибки в подобных местах чаще всего приводят к отказу в обслуживании либо к неверной обработке входящих данных. Конкретики по каждому из двенадцати случаев в бюллетене нет, поэтому судить приходится по составу затронутых модулей.
Что именно позволяют сделать эти уязвимости, разработчик не раскрывает. В описании дефекта риск обозначен как не указанный, а приоритет выставлен минимальный. Такая формулировка обычна, когда производитель подтягивает зависимости целиком, не разбирая каждый случай по отдельности. Для администратора вывод простой: готового сценария атаки нет, однако известные слабости в разборе сетевых данных остаются в рабочем исполняемом файле.
Агенты мониторинга редко оказываются в центре внимания при планировании защиты. При этом они работают на десятках и сотнях хостов, обычно с правами системной службы. С такой учётной записи видны запущенные процессы, сетевые соединения, каталоги и данные о самом сервере Zabbix. Слабое место в сетевом стеке агента даёт злоумышленнику ещё одну точку опоры внутри периметра. Особенно если наблюдаемый узел связан с остальной инфраструктурой доверенными маршрутами.
Отдельно стоит сказать о том, какой именно агент затронут. Agent 2 - второй вариант программы, написанный на Go. Первый агент собран на другом языке, и нынешние уязвимости его не касаются. Разница важна при инвентаризации: на одном хосте могут стоять обе программы, а обновлять нужно только затронутую. Ошибка при замене пакета приведёт к тому, что служба не поднимется и узел молча выпадет из мониторинга.
Исправление появилось в версии 7.0.31. Сборка 7.0.30 всё ещё несёт старые версии модулей, поэтому переход на неё ничего не даёт. Разработчик подтвердил, что все двенадцать находок закрыты именно в 7.0.31 и более новых выпусках. Правка затрагивает сборку для Windows на архитектуре amd64, где проблему и воспроизвели. При этом бюллетень говорит об Agent 2 до 7.0.31 без привязки к конкретной платформе. Значит, обновление имеет смысл провести во всех средах, где стоит этот агент.
Порядок действий для администратора несложный. Сначала нужно собрать список хостов с установленным Agent 2 и сверить версии. Затем - плановое обновление по обычному регламенту управления исправлениями. Если в парке есть изолированные сегменты, их лучше не оставлять на потом: такие узлы живут без обновлений дольше всего. Хотя отдельного признака, что найденные уязвимости уже используют в реальных атаках, в бюллетене нет.
Риск, унаследованный от библиотек, встречается постоянно. Производитель отвечает за свой код, а чужие модули подтягивает по мере выхода новых версий. К тому же статически собранные программы на Go не позволяют заменить отдельную библиотеку одним файлом. Приходится пересобирать и переустанавливать весь агент. Поэтому между публикацией чужого предупреждения и новым релизом продукта появляется окно, когда в инфраструктуре работает устаревшая версия. Отслеживать состав зависимостей нужно не реже, чем следить за версиями самих продуктов.
Ссылки
