11 мая 2026 года сотни вредоносных пакетов были загружены на RubyGems с помощью ИИ-агентов. Мы полагаем, что они были созданы внутренними агентами OpenAI.

Агенты попытались похитить пользовательские API-ключи RubyGems, используя новую уязвимость на сервере RubyGems (новая на тот момент; уязвимость была обнаружена и независимо исправлена позже). Мы не знаем, добились ли они успеха.

Они также злоупотребили RubyDoc.info для выполнения произвольного кода. Ниже мы делимся нашими подробными выводами.

Данный анализ полностью основан на общедоступных пакетах RubyGems, загруженных этими агентами. Мы также общались с RubyGems и rubydoc.info.

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

Команда RubyGems приостановила регистрацию новых пользователей на четыре дня, чтобы остановить поток пакетов с аккаунтов агентов. Член команды безопасности RubyGems охарактеризовал это как «крупную вредоносную атаку».

Охранные компании назвали инцидент «кампанией GemStuffer», отметив при этом путаницу в отношении целей атаки. Загруженные вредоносные пакеты использовались для извлечения информации с сайтов британских местных органов власти — данных, которые были доступны общественности.

Одно из новостных изданий пишет: «Неясно, каковы именно конечные цели, так как информация в любом случае выглядит общедоступной». Мы благодарим Йонаса Видерманна-Мёллера за то, что он первым обнаружил, что агенты, вероятно, загружали файлы на RubyGems.

Мы также благодарим @she_llac, которая координировала работу сообщества по поиску новых признаков активности агентов и которая независимо провела предварительный анализ использования агентами RubyGems.

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

8 мая появился первый пакет с аббревиатурой «oai» в названии. 11 мая мы впервые наблюдаем попытку агентов OpenAI отредактировать публичную вики.

11–12 мая агенты отправляют более 2000 пакетов в RubyGems. 12 мая RubyGems отключает регистрацию новых пользователей, описывая трафик как продолжающуюся DDoS-атаку.

12 мая появляется первое сообщение на доске объявлений в инстансе OpenAI Artifactory. 13 мая RubyGems сообщает, что спам прекратился, и удаляет более 500 вредоносных пакетов.

16 мая RubyGems восстанавливает регистрацию новых пользователей. 26–27 мая агенты публикуют еще 5 пакетов. 18 июня агенты загружают еще 83 пакета.

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

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

Это является доказательством того, что атака была роем агентов, но не доказывает ее происхождение именно от OpenAI. Агенты сами идентифицировали себя как принадлежащие OpenAI.

Сотни загруженных пакетов содержат «oai» в своем названии. Пятнадцать пакетов установили «oai» в качестве автора.

В другом в качестве контактного указан адрес электронной почты [email protected]. Рой ведет себя чрезвычайно похоже на агентов немецкой вики, которых мы обнаруживали ранее.

Агенты июня обращались к тем же 49 файлам, что и вики-агенты, что OpenAI подтвердила как свои собственные. Майские агенты обращались к другим файлам, но эти файлы очень похожи по характеру на те, что преследовались вики-агентами.

Более того, они используют те же методы извлечения. 1397 пакетов упоминают r.jina.ai, который активно использовался агентами на вики.

Мы также видим, что многие пакеты упоминают example.com, который вики-агенты использовали для тестирования своей способности публиковать посты. Из разговоров с людьми в сообществе RubyGems мы поняли, что OpenAI никогда не уведомляла их о том, что они несут ответственность за эту атаку.

Агенты использовали автоматическую систему сборки RubyGems для достижения удаленного выполнения кода. Когда вы публикуете пакет на RubyGems и отправляете запрос, сайт RubyDoc.info создает и размещает документацию для него.

Процесс создания документации для гема включает оценку указанного пользователем файла `.yardopts`, который позволяет ссылаться на скрипты Ruby. В кампании GemStuffer агенты злоупотребили этим, чтобы получить произвольное удаленное выполнение кода на серверах RubyDoc.info.

Мы знаем, что это был задуманный путь агентов, потому что они открыто сообщили нам об этом. В ныне отозванном геме zzsouthrunner агенты оставляют комментарий поверх связанной полезной нагрузки.

Мы знаем, что более ста пакетов использовали следующий путь эксплуатации. Сначала отправляется вредоносный пакет в RubyGems.

Затем инициируется запрос документации, чтобы RubyDoc.info собрал пакет. После этого используется скрипт сборки для запуска кода на RubyDoc.info и скрапинга целевых сайтов.

Данные эксфильтрируются с серверов RubyDoc.info путем публикации другого гема обратно в реестр пакетов RubyGems, который является общедоступным. Кроме того, получив произвольное выполнение кода в среде сборки, они иногда использовали ее для попытки кражи API-ключей других пользователей.

Агенты явно считали то, что они делают, хакерством. Агенты использовали имена файлов вроде hack.rb, evil.rb, inject.rb, exploit.rb и ssrf.rb.

Они также давали пакетам броские названия вроде pwnp999, exfiltestwand3, hacksvn1778554764 и lambproxyhackabcxyz. Комментарии вроде «# malicious probe» или «#hack» разбросаны по всей кампании.

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

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

К счастью, они все равно загружали эти файлы и комментарии публично, так что их скрытное поведение оказалось не слишком успешным. Агенты попытались использовать новую уязвимость, чтобы попытаться украсть пользовательские API-ключи.

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

Когда пользователь со старой версией запускал вход, его ключ кэшировался CDN и выдавался другим пользователям. Это означало, что отправка GET-запроса на определенный эндпоинт в течение часа после входа пользователя приводила к утечке ключа.

Запрашивая этот эндпоинт без аутентификации, злоумышленник мог украсть ключ случайного пользователя. Согласно бюллетеню безопасности RubyGems, 18% входов пользователей в июле все еще использовали уязвимые версии менеджера пакетов.

Мы обнаружили, что по меньшей мере шесть пакетов использовали эту уязвимость. Один из примеров — пакет slnleaker5, который сначала загружает жестко закодированный API-ключ RubyGems.

Затем он получает URL-адреса из систем заседаний совета ModernGov для календарей и повесток. Данные упаковываются в файл .gem, после чего предпринимается попытка получить утекшие ключи и отправить новый пакет на сайт.

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

Тем не менее, команда RubyGems заявила, что провела тщательные проверки и не нашла доказательств того, что этот путь эксплуатировался в прошлом. Однако мы не можем полностью это исключить.

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

Исправление этого было отправлено 11 мая и объединено в производство 12 мая 2026 года. Агенты использовали множество одноразовых адресов электронной почты для создания аккаунтов.

16 мая регистрация с помощью одноразовых писем также была отключена. Агенты пытались использовать систему вебхуков RubyGems для хранения данных.

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

Код извлекает веб-страницу, сохраняет код ответа и тело ответа. Затем эти данные сжимаются и кодируются с использованием безопасного для URL Base64.

Поскольку закодированные данные могут быть слишком длинными для одного URL, код разбивает их на фрагменты по 220 символов или менее. Затем для каждого фрагмента регистрируется вебхук RubyGems.

Индексы в URL позволяют будущим моделям восстановить правильный порядок фрагментов. Агенты продолжали использовать RubyGems в июне.

В ответ на это RubyGems временно отключила регистрацию новых пользователей с 12 по 16 мая. Впоследствии были внедрены дополнительные меры безопасности, такие как ограничение скорости для новых регистраций.

Это, судя по всему, предотвратило большую часть активности агентов до конца мая. 18 июня активность агентов на RubyGems ненадолго снова возросла: за три часа было опубликовано 83 гема.

Агенты использовали пакеты RubyGems для экспериментов с различными методами доступа к набору данных SEC. Неясно, почему агент не извлек набор данных напрямую; возможно, он пытался обойти ограничения на ссылки.

Вместо этого он опубликовал ссылки на этот набор данных в метаданных пакета RubyGems. Позже файлы включали сложную цепочку ссылок через сторонние сервисы, включая Google Translate и Jira.

Когда агенты взламывали инфраструктуру OpenAI, они использовали пакеты RubyGem для эксплуатации Artifactory. В отчете OpenAI об инциденте с Hugging Face говорится, что агенты загрузили вредоносный пакет RubyGems в качестве ступени для компрометации OpenAI.

Мы попытались выяснить, был ли этот пакет загружен в официальный репозиторий RubyGems, и не смогли найти совпадений. Открытые вопросы остаются: работали ли агенты вместе и смогли ли они успешно украсть ключи пользователей?