В Jenkins обнаружены опасные уязвимости, угрожающие конвейерам разработки ПО

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

Детали уязвимостей

Наиболее серьёзная проблема, получившая идентификатор CVE-2026-27099 и высокий балл CVSS, представляет собой хранимую межсайтовую сценаризацию (Stored XSS). Её источник кроется в механизме обработки причин отключения узлов (агентов). Когда администратор переводит агент, например, сборщик, в автономный режим, система запрашивает текстовое описание причины. В уязвимых версиях Jenkins это поле ввода не экранируется должным образом и обрабатывается как HTML-код. В результате пользователь, имеющий разрешения Agent/Configure или Agent/Disconnect, может внедрить в описание вредоносный JavaScript-сценарий.

Этот сценарий будет храниться на сервере и автоматически выполняться в браузере любого пользователя, который просматривает статус узлов, - чаще всего это администраторы или инженеры. Последствия такого внедрения могут быть катастрофическими: от кражи учетных данных и перехвата сессий до компрометации всей цепочки сборки на общих фермах. Фактически, уязвимость превращает стандартную функцию администрирования в инструмент для атаки на ключевых сотрудников и инфраструктуру.

Вторая уязвимость, CVE-2026-27100, с более низким рейтингом опасности, тем не менее представляет значительный риск для конфиденциальности. Она связана с утечкой информации через параметры запуска сборки (Run Parameters). Пользователь, обладающий правами на запуск и конфигурацию задачи, может в параметрах указать ссылку на другую сборку, доступ к которой у него формально отсутствует. Система некорректно проверяет такие ссылки и, обрабатывая их, раскрывает информацию о существовании скрытой задачи, деталях сборки и её отображаемом имени.

Хотя напрямую эта утечка не позволяет модифицировать данные, она становится ценным источником информации для целевой атаки. Злоумышленник может провести разведку, выяснив структуру проектов, названия конфиденциальных заданий и частоту их выполнения, что значительно облегчит планирование дальнейших, более разрушительных операций.

Под угрозой находятся как еженедельные релизы Jenkins вплоть до версии 2.550, так и долгосрочные поддерживаемые версии (LTS) до 2.541.1 включительно. Разработчики уже выпустили исправления в версиях 2.551 (для еженедечного канала) и 2.541.2 (для LTS). Немедленное обновление является первоочередной и самой эффективной мерой защиты. Для организаций, где быстрое обновление невозможно, существует временное решение: в версиях Jenkins 2.539 и выше политика безопасности контента (Content Security Policy, CSP) частично смягчает последствия XSS-атаки, ограничивая выполнение неподписанных сценариев.

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

Данный инцидент ярко демонстрирует, что даже в доверенных и широко распространённых инструментах автоматизации скрываются риски, связанные со злоупотреблением внутренними функциями и правами доступа. Для компаний, чья деятельность напрямую зависит от бесперебойной и безопасной работы конвейеров сборки, особенно в облачных и гибридных средах, оперативное применение исправлений - это не просто рекомендация, а необходимое условие для защиты интеллектуальной собственности, исходного кода и критически важных артефактов сборки. Хотя публичных сообщений об активных атаках с использованием этих уязвимостей пока нет, их высокая потенциальная опасность требует незамедлительных действий от всех команд разработки, использующих Jenkins.

Детали уязвимостей

Ссылки