Plugin4Shell: четыре AI-агента для программирования доверились PIN-коду, который ни разу не проверили

17 сентября 2026 года AIR Security — стартап, разрабатывающий инструменты безопасности для корпоративных ИИ-агентов, — опубликовал исследование, описывающее Plugin4Shell: уязвимость удалённого выполнения кода без действий пользователя (zero-click) в четырёх ИИ-агентах для программирования — Claude Code от Anthropic, Codex от OpenAI, GitHub Copilot и Gemini CLI от Google. Ошибка не в какой-либо модели. Она кроется в операции git checkout, которую каждый агент выполняет при установке плагина, и в том, что ни один из четырёх не проверил, что полученный им код совпадает с закреплённым. К моменту публикации исследования два из четырёх уже получили исправление. Два — нет. Этот инцидент — одна из записей в Orca AI Incident Archive, где он зафиксирован как высокоопасная уязвимость цепочки поставок, сообщений об эксплуатации которой не поступало.

Что агенты на самом деле сделали неправильно

Каждый затронутый агент устанавливает плагины из маркетплейса, и каждый маркетплейс привязывает плагин к конкретному git-коммиту — 40-символьному SHA — после того, как плагин прошёл проверку. Эта привязка и есть вся модель безопасности: проверяющий одобряет одну неизменяемую версию, и агент должен продолжать работать с этой версией, даже если репозиторий за ней позже изменится. AIR описывает эту уязвимость как обход SHA-привязки плагина. Агент переключается на ровно тот коммит, который закрепил маркетплейс, но никогда не проверяет, что рабочее дерево, которое он в итоге получает, соответствует этому коммиту. По словам исследователей, агент «переключается на ровно тот коммит, который закрепил маркетплейс, но никогда не проверяет, что оказался именно там, поэтому атакующий, контролирующий репозиторий плагина, заставляет checkout разрешиться в вредоносный код, при этом привязка по-прежнему выглядит соблюдённой».

Git создает эту брешь. Когда имя одновременно является допустимой веткой и объектом коммита, git отдает предпочтение ветке и лишь выводит предупреждение о неоднозначности. Злоумышленник, контролирующий репозиторий плагина, создает ветку, имя которой в точности совпадает с закрепленным 40-символьным шестнадцатеричным SHA, указывает ее на вредоносный код и делает ее веткой по умолчанию в репозитории. При обычном клонировании эта ветка загружается локально под именем в форме SHA, и последующий checkout разрешается в нее. Сам закрепленный коммит может оставаться нетронутым, поэтому в проверенной версии ничего не выглядит подозрительным. Согласно AIR, должны выполняться два условия: ветка с именем SHA должна быть веткой по умолчанию, поскольку ветка, не являющаяся веткой по умолчанию, загружается только как удаленная отслеживаемая ссылка, и checkout откатится к настоящему коммиту; и git-хост должен принимать 40-символьное шестнадцатеричное имя ветки. GitHub полностью отвергает такие имена. Bitbucket и самостоятельно размещенные git-серверы — нет.

Gemini CLI потерпел неудачу иным путём. Он получил закреплённый коммит, записал его в файл FETCH_HEAD репозитория, а затем выполнил проверку FETCH_HEAD — проверку, которой не требуется читать этот файл. Репозиторий, основная ветка которого сама называется FETCH_HEAD, перенаправляет проверку на подконтрольное злоумышленнику содержимое и молча отбрасывает полученный коммит. Описание механизма от Cybersecurity News совпадает с описанием AIR, включая различие между двумя вариантами.

Почему никому не пришлось ничего нажимать

Тот же checkout снова выполняется во время фонового автообновления плагинов, которое по умолчанию включено в Claude Code и Codex. Именно это делает атаку zero-click, а не просто тихой: когда маркетплейс обновляет закреплённый SHA до очередной новой версии, каждый агент, у которого плагин уже установлен, повторно выполняет checkout без запроса и без действий пользователя. Суть замечания AIR в том, что жертве не нужно небрежно что-либо устанавливать. Ей достаточно установить один плагин из маркетплейса, которому она доверяет, который был проверен и закреплён именно так, как задумано дизайном.

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

Цифры, стоящие за этими двумя путями, взяты из более ранних работ AIR, а не из Plugin4Shell. В кампании, которую компания называет The Story of Skills, говорится, что созданный ею плагин распространился более чем на 26 000 агентов, прежде чем его отозвали. В SkillJacking она сообщила, что 925 навыков, уже активно использовавшихся, были перехвачены у их первоначальных сопровождающих и охватили 134 000 агентов. В заголовке публикации AIR о Plugin4Shell утверждается, что «затронуты миллионы агентов»; в исследовании не приводится число подверженных риску установок, и ни одна третья сторона такого подсчёта не опубликовала.

Хронология и где были применены исправления

AIR сообщает, что обнаружила уязвимость в мае 2026 года, имея рабочие эксплойты proof-of-concept против всех четырёх агентов, и раскрыла её каждому вендору в следующем месяце в рамках скоординированного раскрытия. Anthropic подтвердила исправление в Claude Code 2.1.179 17 июня. Google сообщила AIR 4 августа, что исправление не будет выпущено, поскольку Gemini CLI выводится из эксплуатации. Codex 0.146.0 был проверен как исправленный 12 августа. Microsoft не выпустила исправление для GitHub Copilot.

Патч-версии — единственное публичное подтверждение того, что уязвимость была реальной в двух продуктах, которые её исправили. Опубликованная Anthropic запись в changelog для 2.1.179 перечисляет обработку обрывов соединения, прокрутку в WSL2, исправления glob-шаблонов и интерфейса песочницы и не упоминает пиннинг, проверку плагинов или какое-либо исправление безопасности. Издание The Hacker News сделало такое же наблюдение, согласно материалу The Next Web. На момент публикации исследования идентификатор CVE не был присвоен, а исследовательская заметка Cloud Security Alliance об этой уязвимости повторяет, что идентификатор отсутствовал и спустя три месяца после уведомления поставщиков.

Четыре поставщика, три разных ответа

Google пошла дальше, чем просто отказалась выпускать патч. Она объявила Gemini CLI устаревшим, а это значит, что существующие установки остаются уязвимыми до тех пор, пока люди продолжают ими пользоваться. Рекомендация компании — перейти на Antigravity, более новую агентную среду разработки, которая, по словам AIR, не подвержена этой атаке, поскольку в ней нет SHA-пиннинга плагинов маркетплейса, который можно обойти.

Позиция GitHub снова иная. Представитель GitHub сообщил The Register, что платформа не позволяет пользователям создавать имена веток или тегов, похожие на SHA коммитов, и что «эта мера защиты гарантирует, что описанную уязвимость нельзя эксплуатировать на GitHub». AIR оспаривает не существование этой меры, а её охват: маркетплейсы могут размещаться на других платформах, таких как Bitbucket, сообщили исследователи The Register, а GitHub Copilot по-прежнему поддерживает маркетплейсы с таких платформ, поэтому вариант с именем ветки остаётся достижимым для пользователей Copilot. AIR также утверждает, что в собственной документации Anthropic Bitbucket и self-hosted git указаны как допустимые бэкенды маркетплейсов; в текущей документации Anthropic по маркетплейсам описывается добавление маркетплейса по URL git-репозитория, а не только из GitHub. Microsoft не ответила на просьбу The Register о комментарии, а AIR сообщила, что не получила ответа от Microsoft с момента сообщения о проблеме в июне, ссылаясь на объём раскрытий, которые обрабатывает компания.

Речь идёт о разногласии по поводу широты подверженности, а не о том, существует ли ошибка. Средство защиты GitHub — это ограничение на уровне хоста; находка AIR заключается в том, что проверка должна выполняться внутри агента, поскольку пин разрешается на клиенте.

Что установлено, а что — нет

• Установлено: механизм. В материале AIR приведены точные git-команды, правило разрешения ref вместо объекта, два условия, необходимых для трюка с веткой, и отдельный вариант с FETCH_HEAD для Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld и The Next Web сообщают об этом одинаково.

• Установлено: две исправленные версии. Anthropic подтвердила Claude Code 2.1.179 17 июня 2026 г., а Codex 0.146.0 от OpenAI был подтверждён как исправленный 12 августа 2026 г. согласно графику раскрытия информации AIR.

• Установлено: у двух продуктов на момент раскрытия информации не было исправления. Google не будет выпускать патч для Gemini CLI и прекращает его поддержку; Microsoft ещё не выпустила исправление для Copilot.

• Не установлено: независимое воспроизведение. Все опубликованные сообщения восходят к собственной записи в блоге AIR, а исследовательская заметка Cloud Security Alliance явно не описывает стороннюю техническую проверку или независимое воспроизведение эксплойта. По этой причине архив оценивает достоверность этой записи как B.

• Не установлено:сколько установок на самом деле было затронуто. «Миллионы» — это формулировка AIR в его заголовке, а не измеренная цифра.

• Не установлено: удаляет ли обновление затронутого агента уже заменённый плагин или лишь предотвращает следующую замену. Ни один опубликованный источник не разрешает этот вопрос.

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

Одна сторонняя проверка всё же сужает практическую картину. The Next Web, обобщая проверки The Hacker News, сообщает, что плагины в общественном каталоге Anthropic и в стандартных каталогах Claude Code и Copilot указывают на репозитории GitHub, и что автообновление по умолчанию включено главным образом для этих встроенных маркетплейсов. Поскольку GitHub отклоняет имена веток в форме SHA, вариант с именем ветки труднее достичь для пользователей, которые остаются на стандартных каталогах. Это рассуждение не охватывает вариант с FETCH_HEAD в Gemini CLI, который не зависит от того, как хост именует ветки.

Как должно выглядеть исправление

Рекомендуемое AIR исправление — это одна проверка: после checkout определить коммит, фактически присутствующий в рабочем дереве, и прервать выполнение, если он не совпадает с закреплённым SHA. Исследователи подчёркивают, что проверять нужно вычисленный HEAD, а не запрошенный ref, поскольку именно это различие позволяет проскочить варианту с Gemini CLI, и что проверка должна выполняться внутри агента, поскольку пин разрешается на клиенте и ни один маркетплейс не может обеспечить гарантию, которую он заявляет.

Практические рекомендации для команд, запускающих этих агентов, почерпнутые из AIR, Cybersecurity News и комментариев аналитиков в InfoWorld:

• Обновите Claude Code до версии 2.1.179 или выше, а Codex — до 0.146.0 или выше. Обновление — единственная полная мера защиты там, где имеется патч.

• Отключите автоматическое обновление плагинов на любом агенте, для которого нет патча. Это превращает уязвимость из эксплуатируемой без действий пользователя (zero-click) в требующую ручной переустановки — то есть снижает подверженность риску, но не является исправлением.

Перейдите с Gemini CLI, вместо того чтобы ждать патч, который, по словам Google, так и не выйдет.

• Проведите аудит перечня плагинов и по возможности ограничьте источники маркетплейсов. AIR отмечает, что маркетплейс способен ослабить вариант с именем ветки, разрешив только те хосты, которые отклоняют имена в формате SHA, фактически оставив только GitHub, однако это запрещает хосты, официально поддерживаемые агентами, и ничего не даёт для варианта с Gemini.

• Считайте рабочую станцию границей экспозиции. Плагины наследуют разрешения агента, поэтому успешная эксплуатация достигает исходного кода, SSH-ключей, облачных учетных данных, токенов CI/CD и внутренних репозиториев с полномочиями самого разработчика. Парих Джайн, главный аналитик Pareekh Consulting, сообщил InfoWorld, что командам безопасности следует изучать журналы EDR, git, CI/CD, облачных IAM и аутентификации на предмет необычных процессов, неожиданных файлов плагинов, измененных репозиториев и подозрительной активности git — и добавил, что эти меры снижают риск, но не устраняют основную уязвимость, которую он относит на счет кода поставщика. «Предприятия могут установить контроль над использованием плагинов, — сказал он InfoWorld, — но они не могут исправить изъян в том, как агент программирования проверяет код, который он извлекает».

Почему ошибка с закреплением — та, что имела значение

Закрепление SHA было ответом отрасли именно на тот тип захвата, который AIR уже продемонстрировал: если публичный репозиторий скомпрометирован, агент продолжает запускать проверенный хеш вместо того, чтобы загружать всё, что отправил злоумышленник. Plugin4Shell не ломает хеш. Он показывает, что агенты интерпретировали закреплённую ссылку как имя ветки, которое лишь выглядело как хеш, и вообще не сравнивали результат. Всё, что зависит от этого допущения — процессы проверки, внутренние списки разрешённых элементов, уверенность разработчиков в закреплённой версии — наследует этот сбой.

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