Jenkins разкри критична уязвимост в сигурността, която може да позволи на атакуващите да изпълняват злонамерен код в Jenkins контролер чрез заобикаляне на филтъра за сигурност, използван при комуникацията между агент и контролер.

Проследявана като CVE-2026-70426, уязвимостта засяга инсталации на Jenkins, използващи уязвими версии на библиотеката Remoting. Проблемът е получил критична оценка за сериозност по скалата CVSS.

Засегнати са Jenkins 2.575 и по-ранни версии, както и Jenkins LTS 2.568.1 и по-ранни версии. Уязвимостта съществува в Remoting версии 3384.v60d89463d9e0 и по-ранни, с изключение на версия 3355.3357.v931d3c992987.

Jenkins използва своята библиотека Remoting, обикновено разпространявана като agent.jar или remoting.jar, за да осигури комуникация между централния контролер и свързаните агенти за изграждане (build agents).

Тези комуникации се основават на сериализирани Java обекти. Тъй като грешките при десериализация в Java могат да доведат до произволно изпълнение на код, Jenkins прилага филтъра за класове JEP-200 при обработката на обекти, изпратени по канал на Remoting.

Уязвимост за изпълнение на код в Jenkins

Филтърът JEP-200 е проектиран да ограничава потенциално опасни класове от десериализация от страна на Jenkins контролера. Изследователите обаче установиха, че филтърът не се прилага, когато класовете се разрешават чрез алтернативен път (fallback path) в процеса на десериализация на Remoting.

Този пропуск създава възможност за заобикаляне на филтъра. Атакуващ, който контролира агентски процес, получи възможност за изпълнение на код върху съществуващ агент или притежава разрешението „Jenkins Agent/Connect“, може да експлоатира уязвимостта, за да десериализира определени Java класове, които е трябвало да бъдат блокирани.

Успешното експлоатиране може да позволи изпълнението на злонамерен код в Jenkins контролера, който обикновено е най-чувствителната система в една Jenkins среда.

Въздействието е ограничено до класове, които вече са налични в classpath на ядрото на Jenkins. Това включва класове, пакетирани със самия Jenkins, и класове, включени в платформата Java.

Зависимостите, пакетирани в плъгини, не се десериализират през засегнатия алтернативен път, което намалява общата повърхност на атаката.

Въпреки това, изпълнението на код на ниво контролер остава сериозен риск, тъй като компрометиран контролер може да разкрие изходен код, тайни, идентификационни данни за изграждане, ключове за внедряване и тръбопроводи (pipelines) за доставка на софтуер.

Jenkins отстранява уязвимостта в бюлетина за сигурност SECURITY-3911 с версиите Jenkins 2.576 и Jenkins LTS 2.568.2. Тези релизи обновяват библиотеката Remoting, за да гарантират, че филтърът за класове JEP-200 се прилага дори когато се използва алтернативният път за десериализация.

Организациите трябва да обновят Jenkins контролерите и агентите до коригираните версии възможно най-скоро. Екипите по сигурността трябва също така да преразгледат кои потребители, сервизни акаунти и системи притежават разрешението „Agent/Connect“, тъй като този достъп може да бъде използван като част от пътя за експлоатация.

Недоверените агенти за изграждане трябва да бъдат изолирани, наблюдавани и да им бъде спрян достъпът до чувствителни вътрешни ресурси. Пропускът е докладван чрез програмата за откриване на уязвимости срещу заплащане (Bug Bounty) за Jenkins на Европейската комисия.

За среди, в които незабавното обновяване не е възможно, Jenkins публикува временно решение в своя GitHub клипборд SECURITY-3911-3930.

Администраторите трябва да приложат смекчаващите мерки внимателно и да ги третират като временно решение, докато не бъдат внедрени версии на Jenkins с инсталирани корекции за сигурност.