Чистый репозиторий GitHub может заставить ИИ-агента выполнить вредоносный код

Современные ИИ-помощники для разработки программного обеспечения значительно ускоряют написание кода, автоматизируют настройку проектов и помогают разработчикам выполнять рутинные задачи. Однако вместе с удобством появляются и новые угрозы информационной безопасности.

Специалисты по кибербезопасности продемонстрировали новую технику атаки, позволяющую злоумышленникам использовать на первый взгляд абсолютно безопасный GitHub-репозиторий для выполнения вредоносного кода на компьютере разработчика. Особенность метода заключается в том, что сам репозиторий не содержит вредоносных файлов, благодаря чему успешно проходит большинство автоматических проверок безопасности и не вызывает подозрений даже у опытных специалистов. Исследование было опубликовано экспертами платформы Mozilla Zero Day Investigative Network (0DIN).

Почему эта атака представляет особую опасность

В течение последних нескольких лет инструменты вроде Claude Code, GitHub Copilot, Cursor и аналогичные ИИ-агенты получили возможность не только писать программный код, но и самостоятельно выполнять команды терминала, устанавливать зависимости, запускать тесты и исправлять возникающие ошибки.

Именно автоматизация подобных процессов стала основой новой схемы атаки. Вместо эксплуатации классической уязвимости злоумышленники используют доверие ИИ к стандартным инструкциям установки проекта.

Фактически агент действует так же, как опытный разработчик:

• клонирует репозиторий;
• устанавливает необходимые зависимости;
• пытается запустить проект;
• при возникновении ошибки автоматически ищет способ её исправить;
• выполняет рекомендуемые команды.

На каждом из этих этапов действия выглядят абсолютно легитимными. Именно поэтому атака практически не оставляет очевидных признаков компрометации.

Как устроена новая схема

Исследователи показали пример атаки с использованием Python-проекта.

Сценарий состоит сразу из нескольких безопасных на первый взгляд компонентов.

1. На GitHub размещается обычный репозиторий без вредоносного кода.
2. В инструкции по установке содержатся привычные команды установки зависимостей и первоначальной настройки проекта.
3. После запуска программа специально завершает работу с сообщением об ошибке и предлагает выполнить дополнительную команду инициализации.
4. ИИ воспринимает подобную ошибку как штатную ситуацию и автоматически запускает указанную команду.
5. Во время выполнения этой команды происходит обращение к удаленному DNS TXT-записи, содержащей дополнительную команду оболочки.
6. Полученная команда выполняется уже на компьютере разработчика.

Наиболее необычной частью атаки является использование DNS TXT-записей. Обычно они применяются для хранения служебной информации о домене, подтверждения владения сайтом, настройки электронной почты SPF, DKIM и других механизмов. В данном случае TXT-запись превращается в канал доставки команд.

Поскольку вредоносная инструкция отсутствует внутри самого репозитория, традиционные статические анализаторы не находят ничего подозрительного. Они проверяют только содержимое файлов проекта, тогда как реальная полезная нагрузка загружается уже после начала работы программы.

Почему ИИ самостоятельно выполняет опасные команды

Современные агентные системы проектируются таким образом, чтобы максимально автономно доводить поставленную задачу до успешного завершения.

Если программа сообщает об ошибке, ИИ анализирует текст сообщения и пытается устранить проблему без участия человека. Именно этим пользуются злоумышленники.

Например, приложение может вывести сообщение примерно следующего содержания:

python3 -m axiom init

Для человека подобная команда выглядит вполне привычно. Многие библиотеки действительно требуют первоначальной инициализации перед использованием.

Claude Code рассматривает подобную рекомендацию как обычный этап настройки проекта и автоматически выполняет её, не подозревая, что цепочка команд в дальнейшем приведет к загрузке инструкции из внешнего DNS-сервера.

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

Получение удалённого доступа к системе

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

В демонстрационном примере исследователи показали, что подобная схема позволяет незаметно сформировать цепочку команд, результатом которой становится выполнение произвольного кода на машине разработчика.

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

• создание обратного соединения (Reverse Shell);
• загрузка дополнительного вредоносного ПО;
• кража SSH-ключей;
• получение токенов GitHub;
• поиск секретов в файлах конфигурации;
• компрометация облачной инфраструктуры;
• кража API-ключей различных сервисов;
• закрепление в системе для последующих атак.

Особенно опасно то, что подобные данные часто присутствуют на компьютерах разработчиков. Например, в домашних каталогах могут храниться SSH-ключи, файлы .env, токены доступа к Docker Registry, AWS, Google Cloud, Azure, GitHub, GitLab и другим сервисам.

Почему стандартные проверки практически бесполезны

Большинство современных средств анализа безопасности ориентированы на поиск вредоносного содержимого непосредственно внутри репозитория. Они анализируют исходный код, проверяют зависимости, выявляют известные сигнатуры вредоносного ПО и подозрительные конструкции.

Однако в данном случае вредоносная логика отсутствует.

Сам репозиторий может содержать:

• аккуратный исходный код;
• правильную структуру проекта;
• лицензию;
• README с инструкциями;
• отсутствие подозрительных зависимостей;
• полностью проходить проверки статического анализа.

Опасная часть появляется только после обращения к внешнему DNS-серверу. Поэтому сканер просто не видит будущую полезную нагрузку.

Это делает подобную технику похожей на современные «бесфайловые» (fileless) атаки, когда вредоносный код не хранится на диске постоянно, а загружается непосредственно во время выполнения.

Почему именно ИИ становится главной целью

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

ИИ-агенты работают иначе. Их задача — максимально быстро привести проект в рабочее состояние. Поэтому они:

• самостоятельно читают README;
• анализируют сообщения об ошибках;
• ищут способы исправления;
• запускают дополнительные команды;
• устанавливают зависимости;
• повторяют выполнение до получения успешного результата.

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

Чем новая атака отличается от классических Supply Chain-атак

Традиционные атаки на цепочку поставок программного обеспечения обычно связаны с компрометацией библиотек, зависимостей или официальных репозиториев. Например, злоумышленники могут внедрить вредоносный код в новую версию популярного пакета, после чего тысячи разработчиков автоматически установят заражённое обновление.

В новой схеме всё иначе.

Злоумышленнику не требуется:

• взламывать GitHub;
• компрометировать пакетный менеджер;
• подменять библиотеки;
• использовать эксплойты;
• искать уязвимости операционной системы.

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

Какие данные находятся под угрозой

Рабочая станция разработчика нередко содержит значительно больше конфиденциальной информации, чем кажется на первый взгляд. После выполнения произвольной команды злоумышленник может получить доступ не только к исходному коду проекта.

Под угрозой могут оказаться:

• репозитории Git;
• SSH-ключи;
• GPG-ключи;
• API-ключи;
• облачные учётные данные;
• файлы конфигурации CI/CD;
• секреты Kubernetes;
• Docker-образы;
• VPN-конфигурации;
• локальные базы данных;
• корпоративные документы.

При успешной компрометации одного компьютера злоумышленники могут использовать полученные данные для дальнейшего проникновения во внутреннюю инфраструктуру компании, что делает подобные атаки особенно опасными для организаций, активно использующих ИИ-помощников при разработке программного обеспечения.

Как защититься от подобных атак

Появление агентных ИИ-систем в разработке требует пересмотра привычных моделей безопасности. Теперь важно защищать не только код и зависимости, но и поведение автоматизированных инструментов.

Эксперты по кибербезопасности предлагают несколько практических подходов:

• ограничивать права ИИ-агентов на выполнение системных команд;
• использовать режим «только предложение команд», без автоматического исполнения;
• изолировать среду выполнения (sandbox / контейнеры);
• блокировать доступ к внешним сетевым источникам при установке зависимостей;
• проверять команды, предлагаемые ИИ, перед их запуском;
• использовать политики allowlist для CLI-команд;
• контролировать обращения к DNS и внешним API во время сборки;
• отслеживать аномальные цепочки выполнения установочных скриптов.

Особенно важным считается принцип минимальных привилегий: ИИ-агент должен иметь ровно те права, которые необходимы для анализа и предложения решений, но не для полного контроля над системой.

Как могут развиваться подобные атаки в будущем

Исследователи отмечают, что описанный метод — это только ранний пример более широкой категории атак на агентные ИИ-системы.

В будущем злоумышленники могут использовать более сложные техники:

• многоступенчатые цепочки через несколько репозиториев;
• скрытые инструкции в документации или комментариях;
• обфускацию команд через легитимные сервисы;
• использование популярных библиотек как «триггеров»;
• социальную инженерию через автоматические подсказки ИИ;
• манипуляцию контекстом модели через специально подготовленные данные.

Фактически формируется новый класс угроз — атаки на когнитивное поведение ИИ, где целью становится не уязвимость кода, а логика принятия решений моделью.

Выводы

Новая техника атак показывает, что даже полностью «чистый» репозиторий GitHub может представлять серьёзную угрозу, если он взаимодействует с автономными ИИ-агентами.

Главная проблема заключается в доверии: ИИ-агенты автоматически воспринимают инструкции установки как безопасные и стремятся довести задачу до конца любой ценой.

Это делает традиционные модели защиты недостаточными. Необходим переход к новой архитектуре безопасности, где:

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

Иными словами, безопасность ИИ должна строиться не только вокруг кода, но и вокруг поведения самого агента.

Часто задаваемые вопросы

Что за атака с «чистым GitHub-репозиторием»?

Это метод, при котором репозиторий не содержит вредоносного кода напрямую, но через процесс установки и внешние запросы заставляет ИИ-агента выполнить вредоносные команды.

Почему антивирусы не обнаруживают угрозу?

Потому что вредоносный код не находится внутри файлов репозитория. Он загружается динамически из внешнего источника (например, DNS TXT-записей) уже во время выполнения.

Какие ИИ-инструменты могут быть уязвимы?

Любые агентные системы, которые могут выполнять команды в терминале и автоматически исправлять ошибки, включая инструменты уровня GitHub Copilot, Claude Code и аналогичные среды разработки.

Чем это отличается от обычного вируса?

Обычные вирусы уже содержат вредоносный код. Здесь же используется логика доверия и автоматизации ИИ, который сам загружает и выполняет внешние инструкции.

Как разработчикам защититься?

Рекомендуется ограничить права ИИ-агентов, использовать изолированные среды выполнения, отключить автоматическое выполнение команд и контролировать внешние сетевые запросы.

Насколько это реальная угроза?

Исследователи считают, что это не теоретическая проблема, а практический вектор атак, который будет активно развиваться по мере роста популярности ИИ-агентов в разработке.

Может ли такая атака быть массовой?

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

Редактор: AndreyEx