В Jenkins обнаружен критический пакет уязвимостей: ошибки обработки архивов и веб-сокетов угрожают удалённым выполнением кода

Jenkins

В сфере DevOps и непрерывной интеграции поставок (CI/CD) наступил момент повышенной бдительности. Сообщество разработчиков и администраторов столкнулось с серьёзной угрозой безопасности в одном из ключевых инструментов автоматизации. В популярной платформе Jenkins выявлен пакет из нескольких критических уязвимостей, которые в совокупности создают опасный сценарий для корпоративных систем сборки и развёртывания. Проблемы затрагивают как еженедельные релизы, так и версии долгосрочной поддержки (LTS), что делает инцидент масштабным и требующим немедленного внимания со стороны тысяч организаций по всему миру.

Что обнаружено?

Проект Jenkins официально подтвердил наличие уязвимостей и присвоил им идентификаторы CVE-2026-33001 и CVE-2026-33002. Первая проблема, CVE-2026-33001, кроется в механизме распаковки архивов форматов .tar и .tar.gz. Система некорректно обрабатывает символические ссылки внутри таких архивов. Это позволяет злоумышленнику, способному загрузить специально сформированный архив, записывать файлы в произвольные места файловой системы контроллера Jenkins. Единственным ограничением являются права доступа самой учётной записи, под которой работает Jenkins-сервер. На практике это означает, что злоумышленник с минимальными правами доступа к настройкам проектов (Item/Configure) или контролем над процессами агентов может развернуть на сервере вредоносные скрипты или плагины, что является прямым путём к полному компрометированию системы.

Вторая уязвимость, CVE-2026-33002, связана с недостатками проверки источника запросов в эндпоинте (конечной точке) CLI WebSocket. Jenkins для этой проверки использует заголовки HTTP-запроса Host или X-Forwarded-Host, чтобы вычислить ожидаемый источник. Однако такой подход уязвим для атак типа DNS rebinding (переназначение DNS). В ходе такой атаки злоумышленник может обмануть механизм проверки и заставить сервер принять запрос от неавторизованного источника, что открывает возможности для обхода ограничений безопасности. Обе проблемы затрагивают широкий спектр версий: CVE-2026-33001 присутствует в Jenkins weekly до версии 2.554 включительно и в LTS до версии 2.541.2 включительно. CVE-2026-33002 затрагивает версии с 2.442 по 2.554 и LTS с 2.426.3 по 2.541.2.

Почему это опасно?

С точки зрения тактик злоумышленников, обнаруженные уязвимости представляют собой идеальный шторм для атакующего. Первая уязвимость (CVE-2026-33001) классифицируется как проблема типа «путь обхода» (Path Traversal) с критическим потенциалом. Её эксплуатация напрямую ведёт к возможности удалённого выполнения кода (RCE, Remote Code Execution) на контроллере Jenkins. Контроллер в архитектуре Jenkins является мозговым центром, который управляет всеми задачами сборки, агентами и конвейерами. Получив контроль над ним, злоумышленник получает доступ ко всей экосистеме CI/CD: он может модифицировать артефакты сборки, подменить этапы развёртывания, похитить ключи и секреты, хранящиеся в Jenkins, или использовать сервер как плацдарм для атаки на внутренние сети организации.

Вторая уязвимость (CVE-2026-33002), связанная с обходом проверки происхождения через WebSocket, сама по себе может не дать прямого контроля над системой. Однако она выступает мощным инструментом для повышения привилегий и обхода других механизмов защиты. В связке с первой или другими, пока не обнаруженными проблемами, она позволяет злоумышленнику легитимизировать свои вредоносные действия в глазах системы. DNS rebinding - это классическая техника, при которой доменное имя в очень короткий промежуток времени связывается сначала с IP-адресом, контролируемым жертвой (для прохождения первичной проверки), а затем переназначается на адрес атакующего. Это обманывает механизмы контроля, полагающиеся на доменные имена.

Последствия и риски для бизнеса

Последствия успешной эксплуатации этих уязвимостей для бизнеса могут быть катастрофическими. Платформа Jenkins часто является критически важным компонентом цепочки поставки программного обеспечения. Её компрометация ставит под угрозу сам процесс разработки. Атакующий может внедрить бэкдоры в компилируемое программное обеспечение, что приведёт к заражению конечных продуктов компании. Утечка credentials (учётных данных) и секретов, таких как токены доступа к облачным хранилищам, репозиториям кода или системам оркестрации, может обернуться многомиллионными убытками и потерей репутации. Кроме того, остановка работы Jenkins из-за атаки парализует процессы сборки и развёртывания, что напрямую влияет на скорость вывода продуктов на рынок и может сорвать дедлайны.

Особую опасность представляет тот факт, что для начала атаки зачастую достаточно прав на создание или конфигурацию элемента (Item/Configure). Такие права могут быть выданы относительно широкому кругу разработчиков в большой команде, что увеличивает поверхность атаки. Атаки могут исходить как от внешних злоумышленников, нашедших способ получить доступ к интерфейсу, так и от инсайдеров с уже имеющимися привилегиями.

Рекомендации и выводы

Проект Jenkins оперативно отреагировал на угрозу и выпустил исправленные версии. Для устранения уязвимостей необходимо немедленно обновить Jenkins до версий, не затронутых проблемами. Для еженедельных релизов это версия 2.555 и новее. Для ветки долгосрочной поддержки (LTS) требуется обновление до версии 2.541.3 или выше. Процедура обновления должна быть проведена в соответствии с официальной документацией, предпочтительно после тестирования на стенде, имитирующем рабочую среду.

Кроме немедленного обновления, специалистам по информационной безопасности и администраторам DevOps рекомендуется пересмотреть матрицу прав доступа в своих экземплярах Jenkins. Следует придерживаться принципа минимальных привилегий, выдавая права на конфигурацию элементов только тем пользователям и службам, которым это абсолютно необходимо для работы. Также важно обеспечить строгую сетевую сегментацию, ограничив доступ к интерфейсу управления Jenkins только доверенным сетям, и настроить мониторинг подозрительной активности, такой как загрузка нестандартных архивов или необычные вызовы через CLI WebSocket. Данный инцидент в очередной раз подчёркивает, что инфраструктура CI/CD, будучи двигателем цифровой трансформации, сама становится лакомой целью для киберпреступников и требует не менее пристального внимания к безопасности, чем производственные системы.

Ссылки

Комментарии: 0