Исследователи Mozilla 0din показали атаку в три шага, при которой AI-агенты для кода сами доводят машину разработчика до запуска вредоносного сценария. Для этого хватает почти пустого GitHub-репозитория и обычной просьбы «инициализировать проект»: дальше помощник послушно делает все сам. Для русскоязычных команд это плохая новость не только про Claude, но и про сам подход, где AI-агенты для кода получают право выполнять команды, скачивать зависимости и исправлять окружение без второго взгляда человека.
О схеме сообщает Tom's Hardware. В центре разбора оказался Claude Code, хотя исследователи прямо указывают: проблема не в одной конкретной модели, а в логике агентных инструментов, которые пытаются быть полезными любой ценой. Если дать такому агенту репозиторий с безобидным на вид README и попросить поднять проект, он начинает действовать как старательный джун с root-доступом: читает инструкции, запускает команды, пытается чинить ошибки и не очень понимает, где именно его вежливо ведут к компрометации.
Сценарий выглядит неприятно именно потому, что в нем нет ничего демонстративно злонамеренного на первом шаге. Репозиторий содержит всего несколько файлов-заготовок и не светится в базовых проверках безопасности. Агент клонирует его и первым делом читает Markdown-файл с инструкцией развернуть Python-окружение с пакетом Axiom, который описан как обычный инструмент мониторинга. На этом этапе все выглядит скучно и даже профессионально. Дальше включается первая ловушка: фальшивый стартовый скрипт Axiom при первом запуске просто падает с ошибкой. Для человека это повод насторожиться. Для агента, настроенного «помогать», это приглашение найти обходной путь и починить установку самостоятельно.
Именно здесь срабатывает вторая часть цепочки. Пытаясь исправить сбой, Claude запускает команду python3 -m axiom init. С виду она тоже безобидна: обычная инициализация пакета через Python-модуль. Но эта команда активирует shell-скрипт, который скачивает и запускает следующий кусок кода. И здесь авторы атаки делают ход, ради которого этот кейс и обсуждают: вместо загрузки с подозрительного URL, который могли бы заметить фильтры или сам агент, скрипт идет не на файловый сервер, а в DNS TXT-записи домена _axiom-config.m100.cloud. Для инфраструктуры это не выглядит экзотикой. TXT-записи давно используются для почты, конфигурации и разных служебных задач, так что сама по себе такая операция не кричит о взломе.
В TXT-записи лежит base64-строка, которая после декодирования открывает reverse shell, то есть удаленную оболочку с машины жертвы на сервер атакующего. В этот момент проблема выходит далеко за рамки одного проекта. Если агент запускался от имени разработчика, злоумышленник получает доступ ко всему, к чему есть доступ у этого пользователя: секретам, API-ключам, коду, документам, браузерным сессиям, паролям и другим данным. Дальше можно закрепиться в системе уже дополнительным ПО. Самое неприятное, что для разработчика и для агента финал может выглядеть почти невинно: условное сообщение вроде «окружение готово», после которого кажется, что инициализация просто завершилась как надо. В этом и сила схемы: каждое действие по отдельности похоже на рутину, а опасность возникает из связки нескольких «нормальных» шагов.
Mozilla 0din отдельно подчеркивает, что это не баг в одном репозитории и не экзотический трюк под конкретную демку. Скорее это показательная модель атаки на AI-агенты для кода как класс инструментов. Если агент умеет клонировать репозиторий, читать инструкции, запускать shell-команды, подтягивать зависимости и самостоятельно решать проблемы окружения, то его можно толкнуть в опасную цепочку через несколько уровней косвенности. По сути, агенту не обязательно подсунуть заведомо вредоносный файл. Достаточно создать ситуацию, в которой он сам выберет «полезное» действие, а потом еще одно, и еще одно. Так и появляется компрометация, которую трудно поймать простым сканированием исходников.
Для рынка это еще один холодный душ после череды новостей о том, что AI-инструменты уверенно берутся за задачи, где цена ошибки слишком высока. В программировании соблазн особенно велик: экономия времени видна сразу, а последствия небезопасной автоматизации обычно проявляются позже, когда ключи уже утекли, CI скомпрометирован или внутренняя инфраструктура неожиданно «заговорила» с чужим сервером. История с Claude Code бьет по самому популярному сценарию использования таких продуктов: «возьми новый репозиторий и приведи его в рабочее состояние». Именно этот сценарий многие команды готовы делегировать без присмотра, потому что считают его технической рутиной.
Практический вывод для разработчиков и руководителей довольно приземленный. Не считать неизвестный репозиторий доверенным только потому, что он маленький и чисто выглядит. Не воспринимать AI-агента как инструмент security-анализа только потому, что он умеет комментировать команды и объяснять, что делает. И, главное, не давать таким помощникам слишком широкую свободу в окружениях, где лежат рабочие токены, доступы к облакам, SSH-ключи и активные сессии. Там, где агентам уже выдали право выполнять команды, нужен хотя бы базовый режим недоверия: раздельные изолированные среды, минимальные привилегии и контроль над сетевой активностью. Иначе «инициализировать проект» легко превращается в «инициализировать инцидент».
Главный вопрос теперь не в том, уязвим ли еще один конкретный агент, а в том, успеют ли сами платформы пересобрать модель доверия. Пока AI-агенты для кода оценивают безопасность по внешней правдоподобности шагов, а не по полной цепочке того, что реально будет исполнено на машине, такие атаки будут повторяться в новых вариантах.