Воспроизводимые уязвимые и исправленные фикстуры GitHub Actions для инъекций в агентные рабочие процессы (CVE-2026-44246) с измеренным покрытием детекторов и рекомендациями по устранению.

Это не инъекция шаблона. Ничего не вычисляется как shell; полезная нагрузка — это проза, а интерпретатор — модель. Именно поэтому обычный совет — заключайте переменные в кавычки, не используйте eval — не применим, и поэтому исправление ниже касается того, чего агент может достичь, а не экранирования ввода.

Часть, которую стоит знать: коммит исправления — это не исправление

nnU-Net усилил этот рабочий процесс в двух коммитах, и детектор, который рассматривает «до» и «после» как бинарные состояния, ошибается на среднем.

Коммит, который все назвали бы исправлением — его сообщение «hardened issue and PR agents» — удалил gh issue edit и направил метки через .github/scripts/safe-label.sh, но оставил Bash(gh issue comment:*) у агента. Агента всё ещё можно было склонить к комментированию, а шаблон разрешённого списка gh issue comment:* не ограничен триггерным issue, поэтому цель выбирала модель. Только третий коммит закрыл это: теперь агент пишет /tmp/issue-comment.md, а более поздний, не-агентный шаг публикует его с ISSUE: ${{ github.event.issue.number }}, взятым из события.

Отсюда следуют две вещи, и именно поэтому этот репозиторий — не просто два файла:

«Исправлено» — это утверждение о ревизии, а не о версии. v2.4.1 упоминается как исправленный релиз, но его .github/workflows/ содержит только codespell.yml — агентных рабочих процессов в этом теге вообще нет. Вы не можете проверить исправление по тегу; нужно закрепить коммит.

Блок permissions никогда не меняется. issues: write присутствует и корректен во всех трёх ревизиях, включая последнюю, потому что он нужен более позднему шагу. Детектор, который опирается только на permissions, не может отделить ревизию 1 от ревизии 3. Их разделяет то, что может вызвать агент.

Измеренное покрытие

Три детектора, запущенные на обеих фикстурах и всех трёх реальных ревизиях. Полный сырой вывод и версии инструментов в results.md.

Ни один детектор здесь не является просто «неправильным» — они отвечают на разные вопросы:

• zizmor — это универсальный аудитор Actions. Он сообщает о гигиене закрепления действий и сохранения учётных данных одинаково на всех трёх ревизиях. Вне области для этого класса по замыслу, и включён потому, что «известный линтер был чист на уязвимом файле» легко принять за чистое заключение о здоровье.
• sisakulint имеет специально созданные правила для ИИ и является единственным инструментом здесь, который называет собственный механизм CVE: ai-action-prompt-injection срабатывает на уязвимой ревизии, где тело issue интерполируется в prompt:, и перестаёт срабатывать, как только интерполяция исчезает. Верно. Его находки на поздней ревизии стоит прочитать, прежде чем действовать по ним — ai-action-excessive-tools отмечает Write, который этот рабочий процесс использует намеренно, чтобы записать файл, который публикует более поздний шаг; а ai-action-execution-order хочет, чтобы агент был последним, чего этот дизайн как раз избегает, поскольку привилегированные шаги идут после завершения хода модели.
• agentbound — единственный инструмент, который отделяет ревизию 2 от ревизии 3, читая разрешённый список инструментов агента, а не permissions задания. Его находка ci-agent-missing-author-association сообщается как critical на поздней ревизии, и его собственный README описывает это как чрезмерно строгое, а не ложное: auto-triage предназначен быть достижимым для кого угодно.

У каждого инструмента здесь есть находка, которую он сообщает на ревизии, автор которой уже рассуждал об этом самом условии. Это нормальное состояние эвристики, и причина, по которой таблица покрытия полезнее столбца pass/fail.

Использование

benchmark.sh сообщает об отсутствующем детекторе как об отсутствующем, а не пропускает его молча, потому что таблица покрытия, которая тихо опускает инструмент, ничего о нём не доказывает.

Фикстуры — это сокращённая форма, написанная для этого репозитория и лицензированная под MIT, как и всё остальное. Они механизм-точные, а не копии: fixtures/vulnerable.yml содержит четыре условия и ничего больше, а fixtures/fixed.yml — тот же файл с шестью изменениями, которые имеют значение, каждое аннотировано. Если вы добавляете правило, эти два файла — минимальные входные данные, которые оно должно обработать правильно.

Две особенности интерфейса, обрабатываемые в скрипте, но о которых стоит знать:

• sisakulint не анализирует файл вне git-репозитория. При передаче такого файла он печатает not found и завершается с кодом 3. Без присмотра это выглядит идентично чистому сканированию.
• JSON path у agentbound — это basename, поэтому сканирование каталога по файлам с одинаковым именем неоднозначно.

Исправление

Обнаружение — это лёгкая половина. docs/mitigations.md охватывает другую половину: как ограничить полномочия агента, со слоями, ранжированными по одному вопросу — зависит ли этот контроль от того, что модель решит подчиниться?

Это ранжирование — весь смысл. Инструкция в промпте — это ввод, а не защитное условие; шаблон инструмента, который называет свою цель, или токен, которого у агента никогда нет, — это ограничение. Руководство идёт сверху вниз от «модель не может сделать неправильное» до «модель попросили не делать», с контрольным списком и эволюцией nnU-Net в качестве разобранного примера.

fixtures/fixed.yml помечает каждое из своих шести изменений слоем, который оно реализует, и тем, является ли оно несущим — два из них не являются, и помечены так, чтобы читатель не переоценил файл.

Происхождение

Получено во время выполнения по SHA коммита, никогда не вендорится:

Никакая копия конфигурации nnU-Net здесь не распространяется; повторно запустите получение и сравните байты сами с блобами выше.

Область применения

Это артефакт инженерии обнаружения. Он не содержит эксплойта, и ничто здесь не тестировалось на живом рабочем процессе — уязвимые ревизии являются статическими файлами, уже публичными в истории nnU-Net и упомянутыми в опубликованном рекомендательном бюллетене. Фикстуры помечены do not deploy, потому что они существуют, чтобы быть обнаруженными, а не скопированными.

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

MIT.