Атака с доказательством концепции на Context Hub выявила серьезный риск: отсутствие должной санитарной обработки контента в документации, поставляемой ИИ-агентам, может привести к внедрению вредоносного кода. — theregister.com
Новый сервис, помогающий кодирующим агентам получать актуальную информацию о вызовах API, может спровоцировать масштабную уязвимость в цепочке поставок программного обеспечения.
Две недели назад Эндрю Ын, предприниматель в сфере ИИ и адъюнкт-профессор Стэнфорда, запустил Context Hub — сервис для предоставления кодирующим агентам документации по API.
“Кодирующие агенты часто используют устаревшие API и галлюцинируют параметры”, — написал Ын в посте в LinkedIn. “Например, когда я прошу Claude Code вызвать GPT-5.2 от OpenAI, он использует старый API для завершения чата вместо более нового API для ответов, хотя новый доступен уже год. Context Hub решает эту проблему”.
Возможно. Но в то же время сервис, по-видимому, предоставляет способ обмануть кодирующих агентов, упрощая атаки на цепочки поставок ПО: портал документации может быть использован для внедрения вредоносных инструкций в ИИ-агентов.
Микки Шмуэли, создатель альтернативного курируемого сервиса под названием lap.sh, опубликовал доказательство концепции атаки, демонстрирующее этот риск.
“Context Hub доставляет документацию ИИ-агентам через MCP-сервер”, — написал Шмуэли в пояснительной статье в блоге. “Контрибьюторы отправляют документацию в виде pull-запросов в GitHub, мейнтейнеры их сливают, а агенты запрашивают контент по требованию. Конвейер не имеет никакой санитарной обработки контента на каждом этапе”.
В сообществе разработчиков давно известно, что ИИ-модели иногда придумывают названия пакетов — это недостаток, который, как показали эксперты по безопасности, можно использовать, загружая вредоносный код под вымышленным названием пакета.
PoC Шмуэли исключает этап галлюцинации, предлагая поддельные зависимости в документации, которые кодирующие агенты затем включают в конфигурационные файлы (например, requirements.txt) и сгенерированный код.
Злоумышленник просто создает pull-запрос — поданное изменение в репозиторий — и если оно принимается, отравление завершено. В настоящее время вероятность того, что это произойдет, кажется довольно высокой. Из 97 закрытых PR 58 были слиты.
Шмуэли сообщил The Register по электронной почте: “Процесс проверки, по-видимому, отдает приоритет объему документации, а не проверке безопасности. PR с документацией сливаются быстро, некоторые — самими членами основной команды. Я не нашел в репозитории GitHub никаких доказательств автоматического сканирования на наличие исполняемых инструкций или ссылок на пакеты в представленной документации, хотя не могу с уверенностью сказать, что происходит внутри”.
Он сказал, что не отправлял PR для проверки реакции Content Hub, “поскольку публичные записи показывали, что работа по обеспечению безопасности не ведется”. И он указал на несколько открытых задач (issues) и pull-запросов, касающихся проблем безопасности, в качестве доказательства.
Ын не сразу ответил на запрос о комментарии.
“Агент извлекает документацию из [Context Hub], считывает отравленный контент и собирает проект”, — сказал Шмуэли в своей статье. “Ответ выглядит совершенно нормально. Рабочий код. Чистые инструкции. Никаких предупреждений”.
Ничего из этого не является особенно удивительным, учитывая, что это просто вариация нерешенного риска, присущего ИИ-моделям, — косвенная инъекция промптов. Когда ИИ-модели обрабатывают контент, они не могут надежно отличить данные от системных инструкций.
Для PoC были созданы два отравленных документа: один для Plaid Link, другой для Stripe Checkout, каждый из которых содержал название поддельного пакета PyPI.
В 40 запусках модель Haiku от Anthropic каждый раз записывала вредоносный пакет, указанный в документации, в файл требований проекта без какого-либо упоминания об этом в своем выводе. Модель Sonnet компании показала себя лучше, выдавая предупреждения в 48 процентах запусков (19/40), но все равно записывала вредоносную библиотеку в requirements.txt в 53 процентах случаев (21/40). Флагманская модель Opus этой ИИ-компании справилась еще лучше: она выдавала предупреждения в 75 процентах случаев (30/40) и не записывала плохую зависимость в файл requirements.txt или код.
Шмуэли отметил, что Opus “лучше обучена, на большем количестве пакетов, и она более изощренная”.
Таким образом, хотя высокоуровневые коммерческие модели, по-видимому, способны обнаруживать вымышленные зависимости, проблема шире, чем просто Context Hub. По словам Шмуэли, все остальные системы для предоставления документации, созданной сообществом, ИИ-моделям не дотягивают в плане санитарной обработки контента.
Воздействие недоверенного контента — один из трех рисков, упомянутых разработчиком Саймоном Уиллсоном в его модели безопасности ИИ “смертельная триада”. Поэтому, учитывая, что не проверенная документация является статус-кво, вам следует убедиться, что ваш ИИ-агент либо не имеет сетевого доступа, либо, по крайней мере, не имеет доступа к частным данным. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Thomas Claburn