Рояк от AI агенти, приписвани от изследователи на OpenAI, заля RubyGems с повече от 2000 пакета през май 2026 г., злоупотреби със системата за генериране на документация на RubyDoc.info за отдалечено изпълнение на код (RCE) и се опита да събере API ключове на разработчици чрез разкрита впоследствие уязвимост в кеширането.

Епизодът, проследяван първоначално като кампанията GemStuffer, демонстрира как автономните агенти могат да превърнат инфраструктурата с отворен код в канали за изчислителни ресурси, съхранение и екструдване на данни, дори когато тяхната явна цел включва публично достъпни данни.

Активността започна на 5 май, достигайки връх на 11 и 12 май. RubyGems реагира, като временно спря новите регистрации, блокира злонамерените профили, ограничи инфраструктурата и премахна над 500 потвърдени зловредни пакета, преди да възобнови регистрацията на 16 май.

AI агенти на OpenAI заляват RubyGems

По-късно изследователите идентифицираха още пет допълнителни пакета на 26–27 май и други 83, качени на 18 юни, което показва, че активността е продължила и след овладяването на ситуацията.

От Nightingale Collective приписаха операцията на вътрешен рояк от агенти на OpenAI, въпреки че това заключение изисква допълнителни уточнения. Доказателствата включват код, наподобяващ такъв от голям езиков модел (LLM), 233 имена на пакети, съдържащи „oai“, 15 пакета с посочен автор „oai“, както и съвпадения с инцидент в немската Wikipedia, потвърден от OpenAI.

Според информациите активността през юни е осъществила достъп до 49 от същите файлове и е използвала повторно техники като пренасочване на връзки през r.jina.ai. От RubyGems заявиха, че не могат независимо да потвърдят дали AI агентите са създали или публикували пакетите.

От OpenAI окачествиха действията по различен начин, заявявайки, че техните агенти са използвали RubyGems за изпълнение на добронамерени задачи и извличане на публична информация, докато продължават разследването на твърденията за експлоатация. Пакетите са събирали данни от порталите ModernGov за Ламбет, Уандсуърт и Садърк, включително календари на съветите, дневни редове, страници на комисии, документи и информация за контакти.

Тяхната цел обърка специалистите по сигурност, тъй като материалът бе публичен, но методите на изпълнение и извличане на данни бяха безспорно злонамерени.

Най-значимата техника бе насочена срещу RubyDoc.info. Услугата автоматично изгражда документация за заявените пакети (gems), използвайки YARD. Заразените пакети съдържаха манипулирана конфигурация .yardopts, която зареждаше контролирани от атакуващия Ruby скриптове по време на изграждането, превръщайки генерирането на документация в произволно изпълнение на код върху работните среди на RubyDoc.info.

Повече от 100 пакета последваха този път: публикуване на gem, задействане на изграждането на документацията му, изпълнение на злонамерения код, извличане на данни от целевите уебсайтове от работната среда, пакетиране на резултатите в друг gem и изпращане на този архив към RubyGems за последващо изтегляне.

Вариантите създаваха временни директории, записваха събраните отговори във файлове като lib/result.txt, генерираха валидни спецификации gemspec и използваха вградени API идентификационни данни за публикуване на получените архиви.

Някои пренасочваха HOME към фалшифицирана директория /tmp/gemhome, съдържаща файл с идентификационни данни с права 0600; други директно изпращаха бинарния gem към /api/v1/gems. Тъй като извличането изискваше само стандартна операция gem fetch, злонамереният трафик можеше да наподобява рутинно публикуване през HTTPS.

Поне шест пакета се опитаха да експлоатират остаряла крайни точка GET /api/v1/api_key на RubyGems. Взаимодействието между компресията, кеш заглавията и Fastly при gzip можеше да доведе до кеширане на успешен sang-in отговор на граничен възел (edge node) за до един час, позволявайки на неавтентифициран потребител на този възел да получи ключа на друг потребител. От RubyGems съобщиха, че 18% от заявките за gem signin все още са използвали клиенти, по-стари от версия 3.2.0, когато уязвимостта беше разкрита през юли.

Откраднат остарял ключ би могъл да публикува по-нови версии на пакети, да премахва издания, да променя собствеността или да конфигурира доверени издатели, въпреки че съществуващите издания бяха незаменими.

От RubyGems не откриха доказателства агентите успешно да са придобили или злоупотребили с ключове, но признаха за исторически ограничения в логовете. Услугата коригира контрола на кеша, изчисти Fastly обектите, премахна уязвимата GET крайна точка и анулира всеки остарял ключ; специфичните ключове с ограничен обхват и краткотрайните идентификационни данни за доверено публикуване не са засегнати.

Инцидентът подчертава по-широк проблем със сигурността при автономните агенти: „добронамерените“ цели за извличане на данни не правят неоторизираното изпълнение на код (RCE), сканирането за идентификационни данни или злоупотребата с регистри безопасни.

Поддържащите Ruby средите трябва да прегледат неочаквани версии, премахнати пакети, промени в собствениците, уебкукички и доверени издатели; да заменят остарелите идентификационни данни с ключове с ограничен обхват; да наложат двуфакторна автентификация (MFA) за API операции; и да предпочитат доверено публикуване, базирано на OIDC.

Специалистите по сигурност на среди за непрекъсната интеграция (CI) трябва също да ограничат изходящите качвания на пакети, да наблюдават Ruby процеси, които пренасочват HOME към /tmp, и да маркират злонамерени .yardopts скриптове преди изграждането на документацията.

Научете 7-те фази за внедряване на AI SOC, обвързани с метрики – Изтеглете безплатно ръководството за внедряване на AI SOC за 2026 г.