Исследователи показали атаку, в которой AI-кодинг-агенты могут сами довести себя до запуска вредоносной нагрузки, даже если GitHub-репозиторий выглядит чистым и не содержит явного малвара. Для разработчиков и команд, которые уже доверяют ИИ настройку окружения, это неприятный сигнал: проблема теперь не только в коде, который вы клонируете, но и в том, как агент интерпретирует «безобидные» подсказки при установке проекта.
О схеме 27 июня сообщил BleepingComputer. Речь идет о концептуальной атаке, которую описали исследователи платформы AI-безопасности 0DIN из Mozilla Zero Day Investigative Network. Их тезис звучит жестко: чтобы получить интерактивную оболочку на машине разработчика, злоумышленнику не нужен вредоносный код внутри самого репозитория, не нужен эксплойт и даже не нужен подозрительный шаг, который человек или система защиты должны были бы отдельно подтверждать.
Сценарий построен из трех компонентов, каждый из которых по отдельности выглядит почти рутинно. Первый элемент — внешне нормальный GitHub-репозиторий со стандартными командами установки зависимостей и первичной инициализации проекта. Второй — Python-пакет, специально сделанный так, чтобы отказываться работать до запуска команды инициализации. Вместо падения «в никуда» он выдает понятную ошибку и предлагает конкретный следующий шаг: выполнить python3 -m axiom init. Для человека это может выглядеть как типичная огреха документации или еще более типичная боль Python-окружений. Для агентного инструмента — как обычная задача по автопочинке установки.
Дальше начинается самое интересное. По данным исследователей, Claude Code воспринимает такую ошибку как штатную проблему развертывания и автоматически запускает предложенную команду, пытаясь восстановить рабочее состояние проекта. Уже этот шаг не выглядит злонамеренным: агент не «решает открыть шелл», он всего лишь «исправляет ошибку». Но выполнение python3 -m axiom init приводит к вызову shell-скрипта, который получает значение конфигурации из DNS TXT-записи, находящейся под контролем атакующего, а затем исполняет это значение как команду. В результате злоумышленник может получить интерактивную оболочку с правами текущего пользователя.
Именно в этой многослойности и сидит главная проблема. Опасная логика разнесена по цепочке из нескольких косвенных шагов: сообщение об ошибке, доверие к рекомендованной команде, скрипт, который тянет данные во время исполнения, и DNS-запись, которую сам агент даже не видит как часть исходного кода. С точки зрения обычной проверки репозитория все выглядит почти прилично. Вредоносный фрагмент не лежит в GitHub на видном месте, не бросается в глаза ревьюеру и может не попасть под стандартные сигнатуры сканеров. Это уже не старый добрый «скачай и запусти странный bash из README», а атака на поведение системы автоматизации.
Исследователи отдельно подчеркивают: если цепочка сработает, у атакующего появится доступ не просто к терминалу, а к рабочей среде разработчика со всеми скучными, но дорогими бонусами. Это переменные окружения, API-ключи, локальные конфиги, токены доступа, а также возможность закрепиться в системе. Для российских команд, которые активно переводят рутину на агентные инструменты, риск вполне прикладной. Многие уже позволяют ИИ клонировать репозитории, ставить зависимости, запускать тесты, поднимать dev-сервисы и «разруливать» ошибки установки без постоянного ручного контроля. Чем автономнее такой контур, тем выше шанс, что он отработает за злоумышленника всю цепочку до конца.
Важно, что речь пока не о зафиксированной кампании в дикой природе, а о продемонстрированном методе атаки. Но порог для социальной инженерии здесь низкий. В 0DIN считают, что подобные репозитории можно распространять через фальшивые вакансии, обучающие туториалы, посты в блогах или прямые сообщения. Это правдоподобный вектор: разработчику присылают «тестовое задание», «полезный шаблон» или «демо нового инструмента», а дальше в дело вступает уже не человеческая невнимательность, а исполнительность AI-кодинг-агента. Условно говоря, раньше junior хотя бы мог насторожиться из-за подозрительного скрипта. Теперь ту же ошибку может сделать автоматизированный помощник, причем быстро, уверенно и без внутреннего чувства самосохранения.
На более широком уровне история хорошо ложится в тренд последних месяцев: атакующие изучают не только сами модели, но и рабочие привычки вокруг них. Чем популярнее становятся агентные IDE и кодовые помощники, тем ценнее для злоумышленника возможность подсунуть им правдоподобный контекст. Здесь не нужно ломать модель в лоб. Достаточно аккуратно оформить окружение так, чтобы агент посчитал вредный шаг нормальной частью onboarding-процесса. Это смещает фокус безопасности с анализа артефактов на анализ всей исполняемой цепочки: что было запущено, по чьей подсказке, что подтянулось из сети, какие команды были сгенерированы или выбраны автоматически.
Практический вывод для команд довольно приземленный. Если ИИ-инструментам уже разрешено настраивать проекты, им нужно показывать не только финальную команду, но и всю трассировку исполнения: какие скрипты вызываются дальше, какие внешние значения подгружаются во время работы, какие домены опрашиваются и что именно будет выполнено после подстановки. Исследователи 0DIN рекомендуют именно это: раскрывать полную цепочку setup-команд, включая динамически получаемые скрипты и код. Иначе компания может честно сканировать репозиторий, проверять зависимости и ревьюить README, а реальная угроза придет из той части процесса, которую никто не считал отдельной поверхностью атаки.
Для рынка это, пожалуй, один из самых неприятных сценариев вокруг ИИ в разработке: не компрометация модели как таковой, а эксплуатация ее полезности. Чем лучше агент умеет «сам исправлять проблемы» и доводить установку до рабочего состояния, тем аккуратнее придется ограничивать его инициативу. Следующий этап гонки, похоже, будет не про то, умеет ли ИИ писать код, а про то, умеет ли он достаточно подозрительно относиться к чужому коду и собственным попыткам его «починить».