W paczce yardxabc889, wgranej do rejestru RubyGems w maju, leży plik nazwany evil.rb. Nad kodem wisi komentarz autora: wyłącz złośliwość w następnej wersji i podbij numerek. Program pobiera kalendarz posiedzeń londyńskiej dzielnicy Lambeth i wpisuje go do opisu paczki. Potem kasuje po sobie ślad, buduje nową wersję i odsyła ją do rejestru. Takich paczek przybyło w maju bardzo dużo. Troje badaczy przypisało je agentom OpenAI w raporcie z 11 września 2026. Tego samego dnia zespół RubyGems napisał, że nie potrafi tego rozstrzygnąć. Z dostępnych mu dowodów nie wynika, czy paczki powstały z ręki człowieka, czy maszyny.
Co siedzi w paczkach, które sami otworzyliśmy
W czterech otwartych przez nas paczkach siedzi kod uruchamiany przez cudzy serwer, adresy stron urzędowych i skrypt z zaszytym kluczem dostępowym. RubyGems to rejestr bibliotek dla języka Ruby, odpowiednik npm dla JavaScriptu. Paczki wymienione w raporcie z 11 września otworzyliśmy w archiwum diffend.io, które przechowuje zawartość opublikowanych wersji.
Mechanizm w yardxabc889 opiera się na zwyczaju rejestru. Po wgraniu paczki serwis RubyDoc.info buduje dla niej dokumentację, a przy okazji wykonuje plik konfiguracyjny .yardopts. W tej paczce .yardopts zawiera jedną linijkę: załaduj evil.rb. Reszta dzieje się już na cudzym serwerze.
Dwie kolejne paczki, lambQ4340 i lambcal434a1, mają w metadanych pole autora wypełnione trzema literami: oai. Pole opisu służy normalnie do jednego zdania o tym, co biblioteka robi. W obu paczkach siedzi tam zamiast tego znacznik HTML z adresem serwisu dzielnicy, przepuszczonym przez pośrednik r.jina.ai. Czwarta paczka, slnleaker5, ma jedenaście plików, w tym stulinijkowy skrypt zaczynający się od zaszytego klucza dostępowego. W środku leżą trzy inne gotowe paczki, spakowane jedna w drugiej.
Najdziwniejszy w tej historii jest cel. Trzy z czterech otwartych przez nas paczek sięgają po kalendarz posiedzeń londyńskiej dzielnicy Lambeth. Są to dane, które każdy może pobrać wprost ze strony urzędu. Raport opisuje też paczki używające webhooków rejestru jako magazynu danych. Webhook to adres, pod który rejestr sam wysyła powiadomienie po opublikowaniu paczki. Agenty wpisywały w ten adres pobrane treści, pocięte na kawałki po 220 znaków. Autorzy raportu piszą wprost, że nie wiedzą, po co ktokolwiek miałby tak robić.
W rejestrze tych paczek już nie ma
Sprawdziliśmy w interfejsie programistycznym RubyGems cztery nazwy podane w raporcie: oaitest1778473828, oaibootx8192, oaibootz9218 i chatoaitestgit1778552630. Każda odpowiada kodem 404 i komunikatem, że takiej biblioteki nie znaleziono. Wyszukiwarka rejestru na zapytania oaiboot i oaitest zwraca pustą listę.
Samo 404 niczego by nie znaczyło, więc zrobiliśmy próbę kontrolną. Pakiet rails odpowiada normalnie. Pięć bibliotek usuniętych po głośnym incydencie z 2019 roku daje dokładnie tę samą odpowiedź co nasza czwórka. Wniosek jest więc ostrożny: paczki zostały z rejestru wyjęte, tak jak wyjmuje się pakiety uznane za złośliwe. Ich dawnej zawartości interfejs już nie pokazuje i sprawdziliśmy ją gdzie indziej.
Na czym stoi przypisanie agentom OpenAI
Przypisanie opiera się na metadanych paczek, na wyniku detektora treści generowanych przez modele i na podobieństwie do wcześniejszego roju z niemieckiej wiki. Przesłanki warto znać w całości, zanim uzna się sprawę za zamkniętą.
- Setki paczek mają w nazwie człon
oai, piętnaście wpisujeoaiw pole autora, jedna podaje adres pocztowy zawierający słowoopenai. - Próbka przepuszczona przez narzędzie Pangram została oceniona jako napisana w całości przez model językowy. To przesłanka za maszyną, nie za konkretną firmą.
- Zachowanie roju przypomina agenty, które wiosną zapisywały się na starej niemieckiej wiki, a tamte OpenAI publicznie uznało za swoje. Opisywaliśmy tę sprawę przy agentach wymieniających się odpowiedziami na wiki.
- Czerwcowe paczki sięgały po 49 tych samych plików co agenty z wiki, a niemal 1400 paczek korzysta z tego samego pośrednika do pobierania stron.
Teraz druga strona tego rachunku, którą raport również podaje wprost. Badacze nie mieli wglądu w dzienniki OpenAI ani w łańcuchy rozumowania modeli, więc atrybucja opiera się w całości na tym, co widać w publicznych metadanych. Pole autora w paczce Ruby wpisuje ten, kto ją publikuje, i nikt tego nie weryfikuje. Według raportu OpenAI nigdy nie powiadomiło rejestru, że odpowiada za ten ruch, i do dziś się do niego nie przyznało.
Rejestr opisuje tę samą sprawę inaczej niż badacze
Rejestr potwierdza kampanię i próby zdobycia kluczy, a jednocześnie nie potwierdza ani ich skuteczności, ani udziału agentów AI. Stanowisko RubyGems podpisał Colby Swandale, kierownik techniczny Ruby Central. Firma odniosła się do sprawy po doniesieniu dziennika “The Wall Street Journal” i po publikacji badaczy, których nazywa Nightingale Collective. Powiązaną aktywność opisała wcześniej firma Socket pod nazwą GemStuffer.
Rejestr potwierdza przebieg wydarzeń i własne działania. Kampanię prowadziły świeżo założone konta. Zespół wstrzymał rejestrację nowych użytkowników, zablokował i usunął konta, wycofał ponad 500 złośliwych paczek, a rejestracje przywrócił 16 maja. Instalacje i publikacje dotychczasowych użytkowników działały przez cały czas.
W trzech miejscach obie relacje się rozchodzą, a trzecie jest najważniejsze.
| Sprawa | Raport badaczy | Stanowisko RubyGems |
|---|---|---|
| Skala | ponad 2000 paczek wgranych 11 i 12 maja, 83 kolejne 18 czerwca | ponad 500 wycofanych złośliwych paczek |
| Kradzież kluczy dostępowych | co najmniej sześć paczek próbowało wyciągnąć cudze klucze przez lukę w buforowaniu, opisaną publicznie dopiero 22 lipca | śledztwo nie znalazło dowodów, że którakolwiek próba się powiodła |
| Kto to zrobił | agenty OpenAI, na podstawie metadanych paczek | “na podstawie dostępnych nam dowodów nie jesteśmy w stanie ustalić, czy paczki tworzyły i publikowały agenty AI” |
Ostatni wiersz jest sednem całej sprawy. Rejestr gasił tę kampanię i jako jedyny ma wgląd we własne dzienniki. Tezy postawionej w raporcie mimo to nie potwierdza. Dodaje przy tym zdanie o własnym podejściu. Zajmuje się rozpoznawaniem i blokowaniem nadużyć niezależnie od tego, czy stoi za nimi człowiek, czy program.
Co z tego wynika dla kogoś, kto sam uruchamia agenty
Praktyczna lekcja nie dotyczy Ruby’ego i nie wymaga rozstrzygnięcia, czyje to były agenty. Dotyczy tego, co robi program, któremu wolno wychodzić do sieci i publikować.
Każdy element tej układanki jest zwyczajną, przewidzianą funkcją. Publikacja paczki, automatyczne budowanie dokumentacji, wykonanie pliku konfiguracyjnego, wysłanie żądania przez pośrednik. Nadużycie polega na złożeniu ich w łańcuch, którego nikt nie zaprojektował. Dokładnie ten wzorzec opisywaliśmy przy włamaniach z użyciem Claude Code oraz przy ostrzeżeniu o kluczu wykonawcy w Agents API.
Dla zespołu, który stawia agenty u siebie, wnioski są nudne i tanie we wdrożeniu. Ruch wychodzący ograniczaj listą dozwolonych adresów zamiast blokowania pojedynczych metod. Zapisuj, dokąd agent faktycznie się łączył, i te dzienniki czytaj. Klucz dostępowy, który agent może odczytać, traktuj jak klucz już ujawniony. Cała ta historia dała się odtworzyć wyłącznie dlatego, że rejestr i archiwum trzymały zawartość każdej wgranej wersji.
Agenci AI · Kodożercy
Agenci AI dla osób, które nie programują
Kurs Agenci AI od Kodożerców powstał dla marketerów, menedżerów i freelancerów. Uczysz się na gotowym przykładzie, a potem budujesz to samo u siebie: agent przejmuje zadania, które dziś zjadają Ci czas.
Zacznij od pierwszego agenta →
Najczęstsze pytania
Czy mój projekt w Ruby mógł na tym ucierpieć?
Paczki nosiły wymyślone nazwy w rodzaju oaibootx8192 i nie podszywały się pod popularne biblioteki. Przez pomyłkę w nazwie nie wchodziły więc do cudzych projektów. Instalowanie bibliotek nie było zagrożone, a opublikowanych wydań nie da się nadpisać. Zagrożone były stare klucze dostępowe osób logujących się klientem gem starszym niż 3.2.0. Taki klucz pozwalał zarządzać cudzymi paczkami, ale nie przejąć konta. Wszystkie klucze tego typu rejestr unieważnił 23 lipca, a kluczy zakresowych luka nigdy nie obejmowała. Jeżeli masz w rejestrze własne biblioteki, sprawdź w nich wersje, których nie publikowałeś, nieoczekiwane wycofania, nieznanych właścicieli, zaufanych wydawców i webhooki.
Czy da się jeszcze zobaczyć, co było w tych paczkach?
W samym rejestrze już nie. Zawartość opublikowanych wersji przechowuje natomiast archiwum diffend.io i to stamtąd pochodzą cytowane wyżej pliki. Jest to o tyle istotne, że pozwala każdemu sprawdzić twierdzenia raportu samodzielnie, zamiast przyjmować je na słowo. Warto z tego skorzystać, bo relacje prasowe streszczają na ogół sam raport.
Podsumowanie
Sprawa ma dziś dwa stanowiska i jeden zbiór artefaktów. Raport trojga badaczy z 11 września przypisuje agentom OpenAI ponad dwa tysiące paczek wgranych do RubyGems w maju. Opisuje też ścieżkę zdalnego wykonania kodu przez serwis budujący dokumentację oraz próby wyciągnięcia cudzych kluczy. Rejestr potwierdza kampanię, wycofanie ponad 500 paczek i czterodniową przerwę w rejestracji. Skuteczności ataku na klucze ani atrybucji do agentów AI już nie potwierdza. Artefakty są za to publiczne i sprawdziliśmy je sami. Cztery nazwy z raportu zniknęły z interfejsu rejestru. W archiwum widać pole autora oai, plik evil.rb i paczkę, która po wykonaniu kasuje własny ślad. Kto wpisał te metadane, z samych metadanych nie wynika.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
