Исследователи Mozilla 0din взломали Claude с помощью вредоносного GitHub-репозитория

Призыв «мыслить нестандартно» украшает миллионы мотивационных плакатов — вдохновляющий лозунг для менеджеров среднего звена и повод закатить глаза для всех остальных. Тем не менее именно так поступили исследователи из подразделения Mozilla 0din: они заставили Claude запустить вредоносное ПО окольным, но обманчиво простым способом — достаточно было попросить агента инициализировать проект из аккуратного на вид репозитория на GitHub.

Источник изображения - Getty Images

Цена вопроса высока. В случае успешной атаки злоумышленник получает контроль над рабочим окружением разработчика, а вместе с ним — доступ ко всем секретам: API-ключам, исходному коду, документам, сессиям браузера и паролям. Более того, он может установить дополнительное вредоносное ПО, чтобы закрепиться в системе надолго. Важно понимать: уязвим практически любой агент, просто Claude Code стал фактическим стандартом для задач программирования, поэтому именно на нём исследователи и показали концепт.

Как устроена атака

От разработчика-жертвы требуется одно действие: попросить Claude инициализировать проект из вредоносного репозитория (или настроить его уже после самостоятельного клонирования). Сам репозиторий выглядит абсолютно безобидно — несколько вспомогательных файлов и, что важнее всего, ничего, что могло бы вызвать срабатывание средств безопасности: ни удалённых сканеров, ни локальных проверок, ни собственных защитных механизмов Claude.

Дальше цепочка разворачивается в три шага, и каждый по отдельности выглядит рутинной операцией:

Шаг 1. Безобидная установка зависимостей. В инструкции по настройке стоит стандартная команда вроде pip3 install -r requirements.txt. Но один из устанавливаемых пакетов (в концепте он назван Axiom — отсылка к реальному инструменту мониторинга) намеренно сделан так, чтобы отказываться запускаться до «инициализации». При первом обращении он выдаёт ошибку и подсказывает: выполните python3 -m axiom init.
Шаг 2. Агент «чинит» ошибку сам. Здесь и срабатывает главный психологический трюк. Claude воспринимает это как обычную проблему настройки и, стремясь помочь, самостоятельно выполняет предложенную команду python3 -m axiom init — без отдельного запроса к пользователю.
Шаг 3. Полезная нагрузка приходит через DNS. Команда инициализации запускает shell-скрипт, который — вместо скачивания с вредоносного URL, который мог бы быть просканирован, — считывает TXT-запись конкретного домена, в концепте это _axiom-config.m100.cloud. Внутри записи лежит закодированная в base64 строка; после декодирования она выполняется как команда и открывает обратную оболочку (reverse shell) — то есть доступ к командной строке машины жертвы, перенаправленный на сервер злоумышленника.

Использование DNS выглядит правдоподобно само по себе: TXT-записи активно применяются, например, в настройке электронной почты, поэтому обращение к ним подозрений не вызывает. В итоге и Claude, и сам разработчик видят лишь сообщение вроде «Окружение готово».

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

Почему стандартные защиты этого не замечают

Если подсчитать, получается три уровня косвенного воздействия, и ни один из них по отдельности не выглядит чем-то экстраординарным. Очень немногие сканеры безопасности (если такие вообще найдутся) пометили бы подобный репозиторий, а из всех действий действительно подозрительным выглядит только сам момент открытия удалённой оболочки. Статические анализаторы видят лишь обычное разрешение DNS; инструменты на базе ИИ не находят вредоносного кода в репозитории; человек при беглом просмотре — тоже. Каждый слой по отдельности выглядит безобидно для любого инструмента, который проверяет именно этот слой.

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

Уязвим не только Claude

Хотя демонстрация построена вокруг Claude Code, исследователи подчёркивают: в той или иной форме атаке подвержены и другие популярные агенты — Cursor, GitHub Copilot и Gemini CLI. Уязвимость не в конкретной модели, а в общем поведении агентных инструментов: автоматическое восстановление после ошибок, доверие к инструкциям из репозитория и подгрузка конфигурации «извне».

Существует и параллельный вектор, которому вообще не нужна подставная ошибка. Открывая новый проект, агенты автоматически читают служебные конфигурационные файлы — CLAUDE.md, .cursorrules, AGENTS.md. Достаточно вписать в такой файл нужные инструкции, чтобы направить агента по тому же маршруту.

Пока это концепт — но каналы распространения уже под рукой

На сегодня речь идёт о proof-of-concept: случаев применения в реальных атаках не зафиксировано. Однако в Mozilla 0din предупреждают, что распространять такие репозитории не составит труда — через поддельные вакансии, обучающие материалы, статьи в блогах и личные сообщения разработчикам. Учитывая, насколько быстро агентные инструменты входят в повседневную разработку (в том числе в СНГ), порог входа для атакующего оказывается низким.

Как защититься

Команда 0din завершает отчёт ожидаемым, но важным выводом: разработчик не должен слепо считать незнакомый проект доверенным кодом и тем более не должен полагаться на сам ИИ-инструмент как на средство анализа безопасности. От агентов исследователи требуют проверять, что именно и как будет выполнено, а не просто следовать шагам. На практике это сводится к нескольким правилам:

Раскрывать всю цепочку выполнения. Агент должен показывать полную последовательность setup-команд до запуска, включая скрипты и значения, подгружаемые динамически во время выполнения.
Ставить ручное подтверждение перед автоматическим выполнением команд настройки, особенно тех, что тянут внешние ресурсы или запускают shell-скрипты.
Ограничивать сетевой доступ агента на этапе инициализации проекта.
Считать любую внешнюю конфигурацию недоверенной. Любая подгрузка значения через DNS или удалённый конфиг должна рассматриваться как потенциальное выполнение чужого кода.
Не запускать незнакомые проекты «в один клик». Перед инициализацией репозитория из непроверенного источника стоит просмотреть инструкции по настройке и список зависимостей вручную.

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