Исследователи проверили около 30 тысяч популярных репозиториев и нашли 654 подозрительных CI/CD-цепочки, из которых более 300 подтвердились как реально эксплуатируемые. Для команд, которые привыкли мерить безопасность GitHub Actions зелеными галочками в пайплайне, это плохая новость: «прошел сканирование» не значит «пайплайн под контролем».
Об этом пишет BleepingComputer со ссылкой на материал ActiveState и июньское исследование Novee Security о классе слабостей, получившем название Cordyceps. Речь не о банальном секрете в репозитории и не о криво настроенном одном YAML-файле. Проблема в связке нескольких workflow: по отдельности они выглядят нормально, а вместе позволяют атакующему выполнить код, украсть токены или получить постоянный доступ к инфраструктуре. Причем для старта, как утверждается, достаточно бесплатного аккаунта GitHub без членства в организации и без повышенных прав.
Суть атаки упирается в механику GitHub Actions. Обычный workflow на событии pull_request запускается в недоверенном контексте форка: без секретов репозитория и с токеном только на чтение. Но многие команды используют pull_request_target и workflow_run, которые исполняются уже в контексте базового репозитория, то есть могут иметь доступ к секретам и к более привилегированному GITHUB_TOKEN. Если такой workflow каким-то образом начинает работать с данными из внешнего pull request как с доверенными, получается классическая ловушка: машина считает, что все по правилам, а атакующий получает возможность подсунуть в пайплайн собственный ввод.
Авторы описывают три типовых примитива. Первый: инъекция команд, когда имя ветки, заголовок PR или комментарий попадает прямо в run-шаг и исполняется в shell без нормального экранирования. Второй: инъекция кода через actions/github-script, если пользовательский ввод интерпретируется как JavaScript во время выполнения. Третий и самый неприятный для аудита сценарий: межпроцессная эскалация между workflow. Один, низкопривилегированный, workflow складывает недоверенные данные в artifact или output, а другой, уже привилегированный, эти данные читает и действует от имени мейнтейнера. По отдельности оба файла могут выглядеть безобидно. Уязвимость появляется только в их композиции. Именно поэтому классические SAST- и DAST-инструменты могут спокойно отрапортовать, что все в порядке: каждый YAML валиден, синтаксис чистый, сигнатур вредоноса нет.
На практике это не академическая страшилка. В материале приводятся три показательных кейса. В репозитории Azure Sentinel исследователи Novee показали, что комментарий в pull request мог привести к исполнению анонимного кода в CI Microsoft и краже бессрочного ключа GitHub App; этот сценарий, по данным ActiveState, подтвердил Microsoft Security Response Center. Для проекта такого класса ставка высокая: Sentinel поставляет правила детектирования и автоматические playbook'и в рабочие среды клиентов, так что компрометация ключа открывает путь к тихому изменению доверенного security-контента. Второй пример касается sample-репозитория Google для AI Agent Development Kit: один pull request, как утверждается, позволял выполнить код в CI Google и повысить права до roles/owner в связанном проекте Google Cloud, и этот путь был подтвержден самой компанией. Третий кейс нашли в Apache Doris: там также был подтвержден сценарий кражи учетных данных, после чего проблему исправила Apache Security Team.
Для рынка это важный сигнал по двум причинам. Первая: ломается привычная метрика зрелости CI/CD. Зеленый пайплайн и даже набор security checks больше нельзя воспринимать как доказательство того, что доверительные границы в процессе сборки расставлены правильно. Вторая: подобные конфигурации теперь все чаще генерируются ИИ-инструментами. ActiveState прямо называет агентный кодинг мультипликатором риска: модель быстро штампует workflow, копирует удачные паттерны вместе с неудачными и оставляет после себя много решений без понятного происхождения и без явного момента ручной верификации. Если раньше команда хотя бы теоретически могла успеть глазами проверить десяток изменений в CI, то при нынешнем темпе этот фильтр превращается в формальность.
Здесь показателен и более широкий контекст. Cordyceps не оформлен как CVE, а значит, не попадает в привычную систему учета уязвимостей, на которую опираются многие процессы комплаенса и приоритизации. Параллельно NIST в апреле 2026 года признал, что уже не успевает обогащать все CVE: число поступающих записей с 2020 года выросло на 263%. Иными словами, у индустрии проблемы не только с защитой, но и с измерением. Когда риск не укладывается в знакомую карточку уязвимости и не всплывает в сканере, у него появляется неприятное свойство жить в инфраструктуре долго и незаметно.
Что с этим делать разработчикам и техлидам прямо сейчас, тоже более-менее понятно. Авторы советуют по возможности выбирать pull_request вместо pull_request_target для недоверенных вкладов, не checkout'ить код из PR внутри привилегированных workflow, передавать event-данные через корректно заключенные в кавычки переменные окружения, по умолчанию урезать разрешения до read-only, фиксировать сторонние actions на конкретный commit SHA, а для привилегированных сценариев включать ручное одобрение хотя бы для первых вкладов от новых контрибьюторов. Это не серебряная пуля, но хороший способ закрыть самые очевидные дыры. Для бизнеса вывод еще приземленнее: аудит CI/CD должен смотреть не только на отдельные файлы, но и на то, как workflow связаны между собой, кто производит артефакты, кто их потребляет и в каком контексте исполняется каждая стадия.
Главный вопрос теперь не в том, найдется ли еще один похожий паттерн, а в том, успеют ли процессы управления за скоростью, с которой команды и ИИ-инструменты наращивают сложность пайплайнов. Безопасность GitHub Actions все меньше похожа на задачу «поставить сканер и успокоиться» и все больше на задачу управления доверием внутри CI/CD. Пока индустрия продолжает путать зеленый статус сборки с реальным контролем, такие цепочки будут появляться быстрее, чем их успеют заметить. Для многих команд это уже не проблема будущего, а вопрос ближайшего ревью их собственных workflow.