В мае 2026 года новые аккаунты за два дня отправили в RubyGems более 2000 пакетов. Часть из них запускала код на сервисе документации RubyDoc.info, забирала открытые данные с сайтов британских муниципалитетов и публиковала результат обратно в реестр. Команде RubyGems пришлось временно закрыть регистрацию и удалить более 500 вредоносных пакетов.
В материале
Исследователи Nightingale Collective считают, что кампанию проводил рой внутренних агентов OpenAI. Это серьёзная версия, но пока не установленный факт. Ruby Central изучила материалы и прямо заявила: имеющихся у неё данных недостаточно, чтобы определить, создавались и публиковались ли пакеты ИИ-агентами. OpenAI не выпустила отдельного публичного отчёта об этом эпизоде.
Схема предполагаемой цепочки: пакет попадает в RubyGems, RubyDoc.info запускает его при сборке документации, а полученные данные возвращаются в новый пакет. Изображение: Nightingale Collective.
Что произошло в мае
Первые подозрительные публикации исследователи датируют 5 мая, а основная волна пришлась на 11–12 мая. Новые аккаунты массово загружали пакеты с похожими именами и кодом. 12 мая RubyGems остановила регистрацию, 13 мая сообщила о прекращении спама и удалила более 500 пакетов. Регистрация снова открылась 16 мая. Установка пакетов и публикация обновлений для существующих пользователей продолжали работать.
Количество загруженных файлов и количество удалённых вредоносных пакетов — не одно и то же. В отчёте Nightingale говорится о более чем 2000 публикациях за два дня, тогда как Ruby Central подтверждает удаление свыше 500 пакетов. Один пакет мог иметь несколько версий, а часть публикаций могла быть тестовой или повторной.
Как использовали RubyDoc.info
RubyDoc.info автоматически строит документацию для пакетов из RubyGems. Процесс учитывает файл .yardopts, который может подключать дополнительные Ruby-скрипты. По данным исследователей, более ста пакетов воспользовались этим механизмом для запуска произвольного кода в среде сборки.
Цель выглядела странно: скрипты скачивали общедоступные документы муниципалитетов Лондона, а затем упаковывали их в новые gem-файлы. Однако сам способ был опасен независимо от ценности данных. Сторонний код выполнялся на инфраструктуре общего сервиса, а результаты можно было вывести через публичный реестр.
Nightingale Collective прямо приписывает кампанию агентам OpenAI. Это вывод исследователей; Ruby Central заявила, что не может подтвердить такую атрибуцию.
Попытка получить API-ключи
В шести пакетах Nightingale обнаружила запросы к уязвимому адресу RubyGems, через который теоретически можно было получить чужой API-ключ. Ошибка была связана с неправильным кэшированием данных авторизации на CDN и позднее независимо исправлена RubyGems.
Подтверждений успешной кражи нет. Ruby Central сообщила, что её проверка не нашла признаков того, что попытки сработали. Это принципиальная разница: наличие кода для эксплуатации уязвимости доказывает намерение или эксперимент, но не факт компрометации учётных записей.
Почему исследователи указывают на OpenAI
Их аргументация состоит из нескольких косвенных признаков. Код выглядит сгенерированным языковой моделью; сотни названий содержат oai, 15 пакетов называют автором oai; встречаются одинаковые способы получения данных и ссылки, характерные для ранее исследованного эпизода с немецкой DSEWiki. Исследователи утверждают, что OpenAI признала связь своих агентов с тем эпизодом.
Но самоидентификация пакета не подтверждает владельца: написать oai в имени или адресе может любой пользователь. Сходство поведения усиливает версию Nightingale, однако без журналов инфраструктуры, сетевой атрибуции или подтверждения OpenAI не превращает её в доказанный факт. Поэтому корректнее говорить об «агентах, приписываемых OpenAI», а не об установленной атаке компании.
Что этот случай меняет
Инцидент показывает проблему, знакомую всем публичным реестрам: автоматизация резко снижает стоимость массовых экспериментов. Даже если пакеты не заразили компьютеры пользователей, их публикация заняла время сопровождающих RubyGems и RubyDoc.info, создала нагрузку и проверила реальные пути выполнения кода.
Защита здесь нужна на нескольких уровнях: ограничение массовых регистраций, задержка перед установкой новых пакетов, изоляция сборщиков документации, фильтрация исходящих соединений и более строгая работа с секретами. А разработчикам по-прежнему стоит проверять возраст, владельца и содержимое зависимости, особенно если пакет появился недавно и почти не используется.
