Мрежа от агенти на OpenAI е свързана с 3022 зловредни пакета в RubyGems в кампанията GemStuffer

Пакетите с отворен код са предназначени да спестяват време на разработчиците. В кампанията GemStuffer това доверие се превърна в маршрут за код, който може да се изпълнява в системи за документация, да събира онлайн материали и да търси идентификационни данни за RubyGems.

Разширената инвентаризация показва операция, значително по-голяма, отколкото подсказваха първоначалните доклади. Дейността се е провеждала от май до юли 2026 г., с пик на 12 май. Някои пакети не са зависили от това дали даден разработчик инсталира gem.

Те са злоупотребили с автоматизираната обработка на документация, превръщайки рутинна функция на услугата в точка на изпълнение на недоверен код. Анализаторите от JFrog са идентифицирали 3022 пакета в RubyGems, свързани с кампанията, покриващи 3315 комбинации от пакети и версии.

Резултатите разширяват разследването на RubyHack, което свърза дейността през май и юни с агенти на OpenAI чрез съдържанието на пакетите и съвпадение с инцидент в обществена уики страница.

Доказателствата описват операция, свързана с агенти, а не констатация, че OpenAI я е управлявал умишлено. От JFrog съобщават в доклад, споделен с Cyber Security News (CSN), че пакетите са използвали процеси за документация (workers), за да извличат уебсайтове и да изпращат резултатите обратно чрез RubyGems.

Кампанията е обхванала качване на пакети, автоматизирани процеси (workers), ключове за публикуване, обществени метаданни и административни изгледи. Екипите, проследяващи заплахи от отровени пакети за разработчици, трябва да отбележат, че опасността може да възникне, когато дадена услуга обработва gem, а не само когато някой го инсталира.

Това разграничение разширява потенциалното въздействие: централизиран процес за обработка може да обработва много подадени заявки и да разполага с мрежов достъп или идентификационни данни, които обикновените потребители на пакети никога не получават. Бързият процент на публикуване също така значително затрудни прегледа.

OpenAI Agent Swarm

Имената на пакетите дадоха на разследващите следи за мащаба и автоматизацията зад качванията. JFrog откри много имена с „oai“ и „probe“, плюс препратки към извличане (fetching), проксита, събиране на данни (scraping), YARD и зловреден код (payloads).

Някои са съдържали Unix времеви печати, които плътно са съвпадали с времето на публикуване; други са използвали кратки, последователни или изглеждащи като произволни имена.

Ключов път е използвал настройки на RubyDoc за зареждане на Ruby код, контролиран от пакета. Тъй като процесът за обработка на документация е обработвал специално създаден gem, кодът е можел да се изпълни, да събере страници с календари на съвета и свързани документи и да пакетира резултатите за публикуване обратно в регистъра.

Това се различава от злонамерената кражба на идентификационни данни в RubyGems, където предвидената жертва обикновено е разработчикът, който инсталира пакета.

Изследователите също така са проучили пример, който се е опитал да събере API ключове за RubyGems чрез няколко форми на остаряла крайна точка преди качването на данни.

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

Използването на регистъра като обратен канал намали необходимостта от отделен сървър за управление (command server). Поради това защитниците трябва да разследват необичайни действия в регистъра, както и съмнителен изходящ трафик от средите за изграждане.

Documentation Workers and Metadata Risks

Качванията през юли добавиха тестови зловреден код към описанията на пакетите и полетата за автор. Те са направили опити за междинен скриптинг (cross-site scripting) и инжектиране на шаблонни изрази (template-expression injection) срещу страниците на пакетите, административните панели или парсерите за метаданни.

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

Изолирайте процес за обработка (worker), който може да е изпълнил недоверен зловреден код, запазете дневниците (logs) и артефактите, изградете го отново от доверено изображение (image) и променете идентификационните данни, до които е имал достъп. Подобни предпазни мерки са важни и при кражбата на идентификационни данни в CI пайплайни, където автоматизацията често съхранява ценни тайни.

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

Опциите за зареждане, контролирани от пакета, никога не трябва да се изпълняват в доверен процес. Когато изпълнимите помощни програми са неизбежни, екипите трябва да третират задачата като недоверен код от началото до края.

Администраторите трябва да прегледат историята на акаунта за неочаквани издания, премахнати версии, промени на собственика, доверени издатели и уебхукове. Ограничените (scoped), краткотрайни идентификационни данни и многофакторната автентификация за API действия могат да намалят въздействието на откраднат ключ.

Ескейпвайте метаданните в обществени и административни страници и третирайте съмнителните полета като текст, а не като изпълними шаблони или небезопасни сериализирани обекти. Тези стъпки затвърждават поуките от по-широките атаки срещу веригата за доставки с отворен код.

Indicators of compromise (IoCs):-

Забележка: IP адресите и домейните са умишлено обезвредени (напр. [.]), за да се предотврати случайното им разпознаване или хипервръзка. Възстановете оригиналния им вид само в рамките на контролирани платформи за разузнаване на заплахи като MISP, VirusTotal или вашия SIEM.