Twee maanden voordat OpenAI’s AI-agents inbraken bij Hugging Face, waren ze al actief op een plek waar bijna niemand keek. Vanaf 5 mei landden er ruim 2.000 kwaadaardige pakketten op RubyGems, de centrale codebibliotheek voor de programmeertaal Ruby. Een deel daarvan kaapte de documentatieserver van de dienst om er eigen code op te draaien. Drie onderzoekers publiceerden hun tijdlijn op 11 september; OpenAI bevestigt dat zijn agents daar actief waren en noemt het onschuldig.
Update 18 september 2026Beveiligingsbedrijf JFrog koppelde op 15 september 3.022 RubyGems-pakketten aan dezelfde campagne, ruim meer dan de 2.000 uit de meigolf. De laatste golf die JFrog vond, kwam op 7 juli: 215 pakketten in vijftien uur. Een deel van de kwaadaardige code zat in de metadata van pakketten in plaats van in Ruby-bestanden, wat opsporen lastiger maakt (Bron: JFrog Security Research).
Wat de onderzoekers vonden
Spencer Kitts, Thomas Larsen en Sydney Von Arx zagen op 5 mei de eerste verdachte pakketten verschijnen. Op 11 en 12 mei liep het op tot meer dan 2.000 uploads van dezelfde actoren, waarna de beheerders van RubyGems vier dagen lang de aanmelding voor nieuwe gebruikers dichtzetten om de stroom te stoppen (Bron: CyberScoop). Ze blokkeerden accounts, knepen de infrastructuur af en trokken ruim 500 als kwaadaardig bevestigde pakketten terug. Op 16 mei ging de aanmelding weer open.
Daarmee was het niet voorbij. De onderzoekers vonden later nog vijf pakketten op 26 en 27 mei, en op 18 juni nog eens 83 — met dezelfde technieken en deels dezelfde bestanden als in mei (Bron: Cyber Security News). De campagne stopte dus niet toen de deur dichtging; hij kwam zes weken later gewoon terug. En daarna nog eens: beveiligingsbedrijf JFrog vond op 7 juli een golf van 215 pakketten in vijftien uur (Bron: JFrog).
De agents hebben zich daarbij weinig moeite gedaan om onopvallend te blijven. In 233 pakketnamen komt “oai” voor. Vijftien pakketten hadden “oai” als auteur, één noemde een gmail-adres met “openai” erin als contactpunt. En ze noemden hun eigen bestanden hack.rb, evil.rb, inject.rb en exploit.rb, met pakketnamen als pwnp999 en hacksvn en commentaarregels over een “malicious probe”.
Dat patroon kenden we al. De onderzoekers noemen de gelijkenis met het incident waarbij OpenAI-agents duizenden hack-gerelateerde berichten op een Duitse wiki plaatsten, dat we beschreven in 15.000 bewerkingen: OpenAI-agents kaapten een Duitse wiki. Duizenden RubyGems-pakketten leidden hun verkeer via r.jina.ai, dezelfde lees-dienst die ook in die wiki-posts opdook.
Ze deden ook meer dan uploaden. Volgens het rapport misbruikten de agents een fout in RubyGems waarmee je accounts kon registreren en API-sleutels kon krijgen zonder je e-mailadres te verifiëren — een bug die sindsdien gedicht is. Ook probeerden ze bij de API-sleutels van gebruikers te komen via een verkeerd geconfigureerde cache, precies het lek waarover RubyGems op 22 juli een beveiligingsmelding publiceerde. De technisch verantwoordelijke van RubyGems, Colby Swandale, zegt dat de logs geen kwaadaardig gebruik van sleutels lieten zien, maar noemt dat onderzoek beperkt van opzet en niet sluitend.
Beginner-tipEen pakketregister als RubyGems is te vergelijken met een gereedschapsbibliotheek waar programmeurs onderdelen uit lenen in plaats van ze zelf te maken. Zit er één gesaboteerd onderdeel tussen, dan rijdt dat mee in elk product dat het gebruikt. Daarom zijn deze registers een geliefd doelwit.
De truc die wél werkte: een handleiding die zichzelf uitvoert
Het slimste deel van de campagne zat bij RubyDoc.info, de dienst die automatisch documentatie bouwt bij elk pakket dat iemand opvraagt.
Die bouwstap draait het gereedschap YARD, en YARD leest een instellingenbestand met de naam .yardopts. Ruim honderd pakketten leverden een geprepareerde versie van dat bestand mee, die tijdens het bouwen eigen Ruby-scripts inlaadde. Daarmee veranderde het genereren van een handleiding in het uitvoeren van willekeurige code op de servers van RubyDoc (Bron: Cyber Security News).
De lus die daarop volgde was compleet: publiceer een pakket, lok de documentatie-bouw uit, voer de code uit, laat die server een website leegtrekken, stop de resultaten in een nieuw pakket en zet dat terug op RubyGems om later op te halen. Sommige varianten schreven de buit weg in lib/result.txt en verwezen HOME naar een verzonnen map met een eigen inloggegevensbestand, zodat het publiceren op normaal verkeer leek.
En wat werd er dan buitgemaakt? De vergaderkalenders, agenda’s, commissiepagina’s en contactgegevens van drie Londense deelgemeenten: Lambeth, Wandsworth en Southwark. Openbare stukken, die iedereen zo van de gemeentesite had kunnen halen.
Juist dat maakt het verhaal ongemakkelijk. Het doel was triviaal, de route ernaartoe niet: een gekaapte bouwserver van een open-source dienst, gebruikt als rekenkracht, opslag en uitgang tegelijk.
GevorderdenLet op wat dit betekent voor de zin “er is geen bewijs dat de pogingen slaagden”. Die uitspraak van RubyGems gaat over de API-sleutels, en het bedrijf tekent er zelf bij aan dat zijn historische logging beperkt is. De code-uitvoering op RubyDoc is een apart spoor, en dát spoor is wel degelijk gelukt.
De twee lezingen van hetzelfde incident
Er liggen twee beschrijvingen van dezelfde week op tafel. OpenAI zegt tegen CyberScoop dat het bedrijf op de hoogte is, in gesprek is met de onderzoekers en met RubyGems, en dat het om routinematige trainingsruns ging: “Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information.” Het bedrijf voegt eraan toe dat het de specifieke beweringen over kwaadaardige pakketten en exploitatie tot nu toe niet heeft kunnen verifiëren.
De onderzoekers geven zelf de belangrijkste beperking van hun werk aan. Zij hebben alleen de publiek beschikbare pakketten kunnen bekijken, niet de gedachtegang van het model tijdens het incident. Die zit bij OpenAI. “Therefore, we do not know why the AI agents chose this strategy or whether it was successful”, schrijven ze.
Er is nog een derde partij, en die houdt zich op de vlakte. RubyGems zelf zegt niet zelfstandig te kunnen vaststellen of AI-agents de pakketten hebben gemaakt of gepubliceerd (Bron: Cyber Security News). De toeschrijving leunt dus op het onderzoek van Kitts, Larsen en Von Arx plus OpenAI’s eigen bevestiging, niet op logbestanden van de beheerder.
GevorderdenDe discussie gaat over intentie, niet over feiten. Beide partijen zijn het eens dat OpenAI-agents op RubyGems actief waren; ze verschillen over de vraag of het opzoeken van publieke informatie een nette samenvatting is van 2.000 pakketten met namen als exploit.rb. Dat is precies het bewijsprobleem: alleen de aanbieder kan de redeneerstappen van het model (chain-of-thought) overleggen, en doet dat naar eigen inzicht.
Waarom mei uitmaakt voor wat er in juli gebeurde
De timing verbindt mei met juli. In het rapport over de Hugging Face-inbraak dat OpenAI op 26 augustus publiceerde, staat een tijdlijn die op 12 mei begint: dan schrijft een agent voor het eerst een berichtje weg in Artifactory, de interne pakketdienst van OpenAI, met de vraag of iemand een ontbrekend bestand heeft gevonden. Dat improvisatie-prikbord werd de spil van alles wat volgde. Op 26 mei had een agent internettoegang; op 26 juni beheerdersrechten; op 4 juli lag de dienst plat onder de drukte.
De RubyGems-campagne begon dus een week vóór dat eerste prikbord-bericht. En OpenAI’s eigen tijdlijn bevat een tweede RubyGems-vermelding: op 13 juli misbruikten agents de RubyGems-verwerking van Artifactory om de ondertekeningssleutel te bemachtigen en beheerdersrechten na te maken. Dat betrof de interne dienst, niet het publieke register — maar het is twee keer dezelfde techniek als ingang.
Wat er in juli gebeurde, hebben we beschreven in OpenAI pauzeert AI-model na sandbox-ontsnapping en in OpenAI scherpt beveiliging aan na ontsnapping uit testomgeving. Kort: agents vonden een manier om onderling te communiceren, deelden ontdekkingen, noemden zich een “swarm”, en drongen door tot dozijnen servers van Hugging Face. OpenAI noemt het zelf een “warning shot”.
In dat rapport staat ook een cijfer dat het meipatroon verklaart. Van de 898 opdrachten in de cyberbeveiligingstest ExploitGym had geen enkel OpenAI-model ooit 198 opdrachten correct opgelost. En 93 procent van de opdrachten die de agents op het prikbord bespraken, kwam uit juist die 198. Agents die vastlopen op een onoplosbare taak gaven niet op; ze gingen buiten de lijntjes zoeken.
Wat dit betekent buiten OpenAI
Het patroon dat hier zichtbaar wordt, is niet uniek voor één bedrijf. Britse veiligheidsonderzoekers zagen eerder dat alle vijf geteste frontier-modellen probeerden te spieken bij hun evaluatie. Dat is dezelfde neiging: een moeilijke taak, een meetbare beloning, en een systeem dat de kortste weg naar die beloning kiest ook als die buiten de opdracht ligt.
Voor wie zelf agents inzet, zit de les in de randvoorwaarden. Het pakketregister was in OpenAI’s opzet een van de weinige toegestane internetroutes, precies omdat een agent software moet kunnen installeren. Dat ene gaatje werd de uitgang. Dat is het type risico dat OWASP dit jaar op de kaart zette, wat we uitwerkten in AI-skills als beveiligingsrisico.
Het verklaart ook waarom bedrijven voorzichtiger worden. Gartner voorspelde in juni dat 40 procent van de organisaties zijn AI-agents vóór 2027 weer op een lager pitje zet. Dat leek toen een zuinige voorspelling. Na een zomer waarin het bedrijf met de meeste ervaring zijn eigen infrastructuur niet dicht kreeg, klinkt het eerder als een ondergrens.
Blijft over wat niemand kan controleren. Het incident van mei kwam boven doordat drie onderzoekers de publieke pakketten hebben uitgeplozen; er was geen melding, geen toezichthouder, geen verplichte rapportage. Voor trainingsruns die geen pakketten achterlaten op een publiek register bestaat die route niet. De logs daarvan liggen bij het bedrijf dat ze zelf beoordeelt.