654 репозитория в одном сканировании оказались потенциально уязвимы к новой схеме атак, а более 300 из них исследователи назвали полностью эксплуатируемыми. Для разработчиков и DevOps-команд это неприятный сигнал: вредоносные pull request теперь бьют не только по коду, но и по самому конвейеру сборки, где лежат токены, ключи подписи и доступ к облаку.
О новой слабости под названием Cordyceps сообщает Dark Reading. Речь не о баге в одном продукте и не о классической дыре с готовым CVE, а о типовом изъяне в CI/CD-логике: внешнее действие вроде pull request или даже комментария может запускать цепочку, которая в итоге дает атакующему выполнение кода, кражу учетных данных, обход merge-gate и, в худшем случае, компрометацию цепочки поставок.
Сценарий особенно неприятен тем, что выглядит почти буднично. Pull request в open source по определению должен быть открыт для внешних участников, а значит, автоматизация вокруг него часто строится с расчетом на удобство, а не на жесткое разделение доверенных и недоверенных входов. Исследователь Elad Meged из компании Novee утверждает, что именно в этой зоне и прячется проблема: workflow в CI/CD нередко получает больше прав, чем должен, а дальше злоумышленник использует эти права через seemingly harmless событие в репозитории. Формально каждый отдельный шаг может быть «на своем месте», но в связке получается вполне рабочая атака.
В статье перечислены конкретные проекты, где этот паттерн был обнаружен. В Microsoft Azure Sentinel, по данным Novee, комментарий в pull request позволял выполнить код на CI-инфраструктуре Microsoft и украсть неистекающий ключ GitHub App. В репозитории Google AI Agent Development Kit один pull request мог запустить код в CI и получить аутентифицированный контроль над связанным проектом Google Cloud. У Apache Doris исследователи описали сразу две zero-click-атаки через pull request, а среди затронутых проектов также названы Workers SDK от Cloudflare и форматтер Black под эгидой Python Software Foundation. Набор, мягко говоря, показательный: здесь и облако, и AI-инструменты, и популярная open source-база, и де-факто стандарт из Python-инструментария.
Цифры в этой истории выглядят хуже, чем привычные рассуждения про «единичный исследовательский кейс». Novee заявляет, что в рамках одного сканирования отметила 654 репозитория как потенциально эксплуатируемые по этой схеме, а 300 назвала подтвержденно уязвимыми для выполнения атакующего кода, кражи credentials или компрометации supply chain. Среди дополнительных последствий компания перечисляет публикацию вредоносных пакетов, подделку CI-проверок, обход merge-ограничений, impersonation ботов и социальную инженерию. То есть проблема не сводится к тому, что кто-то «поигрался» с YAML. Если в пайплайне есть токен публикации пакета, доступ к облаку или привилегированный GitHub App, цена ошибки быстро становится очень прикладной.
При этом в материале есть важная оговорка, без которой новость легко превратить в киберпаникерский пересказ. Microsoft и Google подтвердили влияние проблемы на указанные сценарии, Apache и Cloudflare сообщили о hardening и исправлениях, а сам Meged отдельно сказал Dark Reading, что признаков широкомасштабной эксплуатации «в поле» на момент публикации не было. Это не история про уже идущую массовую эпидемию, а история про очень неприятный класс слабостей, который давно существовал в инфраструктуре разработки и оказался куда масштабнее, чем многим хотелось бы думать.
Почему это важно именно сейчас, тоже довольно прозрачно. Во-первых, CI/CD давно перестал быть вспомогательной прослойкой: там живут секреты, процессы релиза, подпись артефактов, публикация пакетов и доступы в облако. Во-вторых, такие конфигурации часто воспринимают как «техническую обвязку», которую можно быстро собрать и не слишком глубоко ревьюить. В-третьих, сам Meged прямо связывает рост проблемы с AI coding agents: они быстро генерируют конфигурации CI/CD и столь же быстро размножают небезопасные шаблоны по множеству репозиториев. Если раньше плохой workflow был локальной ошибкой конкретной команды, то теперь он рискует стать тиражируемым паттерном.
Для русскоязычной IT-аудитории вывод здесь довольно прямой. Разработчикам придется относиться к GitHub Actions, YAML-файлам и любым PR-triggered workflow так же серьезно, как к приложенческому коду. DevOps и AppSec-командам стоит пересматривать, какие workflow запускаются на недоверенном вводе, где используются повышенные права, как передаются артефакты и переменные между джобами, и не может ли внешнее событие пересечь границу доверия. CISO и техдиректорам полезно, наконец, признать неприятный факт: «workflow code is code» не звучит как откровение, но в реальности именно эти файлы во многих компаниях выпали из полноценной модели угроз и регулярного security review.
История с Cordyceps показывает не столько новую технику атаки, сколько старую привычку индустрии недооценивать служебный код вокруг продукта. Пока команды меряют качество репозитория тестовым покрытием и скоростью релиза, злоумышленник смотрит на ту же систему как на набор доверительных переходов, где один неосторожный workflow может открыть дорогу от pull request к релизу. И это, похоже, уже не частный эксцесс, а новый обязательный пункт в чек-листе любой зрелой разработки.
The post Вредоносные pull request стали новой проблемой CI/CD appeared first on iTech News.