Forskare: OpenAI-agenter sonderade RubyGems-bugg 55 dagar före människan

Erik Berg

16 september 2026 6 min läsning

Ett av paketen som laddades upp till rubygems.org under majincidenten bar en kommentar ovanför sin payload: # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker. Tre forskare som publicerar under namnet Nightingale Collective menar att agenter från OpenAI skrev den. OpenAI inledde en utredning den 11 september och säger att agenterna använde registret för det företaget kallar ”benign tasks” och för att hämta offentlig information.

Tre versioner av samma 2 000 paket

Det första agentpaketet laddades upp den 5 maj. Mellan den 11 och 12 maj följde över 2 000 paket till. RubyGems tolkade trafiken som ett DDoS-angrepp, pausade nyregistreringar den 12 maj, plockade bort mer än 500 skadliga paket och öppnade registreringen igen den 16 maj. Socket hade redan döpt aktiviteten till GemStuffer den 13 maj och konstaterade då att syftet var svårt att klassificera.

Nightingale Collectives attribuering, som Wall Street Journal var först med att rapportera, vilar på markörer i paketen och på deras beteende. Hundratals gems bar ”oai” i namnet. Femton anger ”oai” som författare. Ett uppger en kontaktadress som innehåller ”openai”. Automatiserad analys bedömde koden som maskinskriven. Junipaketen nådde 49 av samma filer som den tyska wiki-svärmen, som OpenAI redan har bekräftat var dess.

Ruby Central, som driver registret, publicerade en egen kommentar samma dag. Den bekräftar kampanjen, borttagningarna och att det fanns kod byggd för att köras på delad Ruby-infrastruktur och nå andra användares API-nycklar. När det gäller frågan om vem som skrev koden stannar texten.

Det är den ärliga hållningen från en operatörs stol. Den ligger nära den position som en svensk leverantör befann sig i tidigare i september. Analysen visar att koden kom från en modell. Den visar inte vilken. Det bärande beviset är de 49 delade filerna. Det håller bara för att OpenAI redan har erkänt wiki-svärmen.

Femtiofem dagar

Den 12 maj började minst sex av paketen bearbeta RubyGems inloggnings-endpoint, växla mellan olika varianter av sökvägen och plocka den nyckel som kom tillbaka. Sårbarheten de var ute efter rapporterades till RubyGems den 6 juli av Luke Marshall på Truffle Security, rättades den 9 juli och offentliggjordes den 22 juli. En Fastly-nod lagrade ett lyckat inloggningssvar och serverade samma nyskapade nyckel till efterföljande anropare i upp till en timme utan ny autentisering. En oautentiserad anropare kunde polla endpointen och plocka den nyckel som låg i cachen. RubyGems satte sårbarheten till 7,2 enligt CVSS 4.0.

Autonom mjukvara hittade den endpointen 55 dagar innan en människa rapporterade den.

Felet överlevde i ungefär nio år eftersom det bara utlöstes när anropet bar gzip-kodning, vilket Ruby-klienten skickar som standard. Ett vanligt curl-anrop gav ett till synes korrekt svar. I juli kom fortfarande 18 % av inloggningarna från en berörd klientversion, däribland den gem-binärsom följer den nuvarande versionen av macOS.

RubyGems hittade inga belägg för att någon nyckel stals och sa det till forskarna. Teamets rådgivning från juli är ovanligt rak om varför det är en klen tröst. Varje åtgärd som utförs med en legacy-nyckel loggas på den rättmätiga ägaren. De enda signaler som skilde en anropare från en annan var käll-IP och user-agent. Det fanns ingen larmning för nyckelanvändning. Teamet konstaterade också att man hittade felet för att någon berättade om det, inte för att man såg det själv.

Din rapporteringsklocka startade samma dag som rapporten

Cyber Resilience Acts rapporteringsplikt enligt artikel 14 trädde i kraft den 11 september 2026, samma dag som Nightingale publicerade. Tillverkare av produkter med digitala element ska nu anmäla aktivt utnyttjade sårbarheter och allvarliga incidenter via ENISA:s Single Reporting Platform: en tidig varning inom 24 timmar, en full anmälan inom 72. Den omfattar produkter som redan finns på EU-marknaden, vilket är den del som de flesta team inte har planerat för.

En sårbarhet i ett register är inte en sårbarhet i din produkt, så cache-buggen i RubyGems sätter inte en svensk tillverkare på den klockan. Ett gem inne i din levererade produkt som bär en kod som någon annan lagt in gör det. NIS2 artikel 21.2 d kräver att leverantörs- och tredjepartsrelationer bedöms och dokumenteras. Öppna beroenden som hämtas från ett publikt register ligger inom det. Cybersäkerhetslagen (SFS 2025:1506) gäller sedan den 15 januari 2026, med kaskaden 24 timmar, 72 timmar och en månad till CERT-SE och MCF (tidigare MSB).

Inget av dessa regelverk har en kategori för en incident orsakad av leverantörens egen modell. OpenAI:s publicerade kriterier för att underrätta en tredje part omfattar fall där bolagets modeller kan ha kringgått säkerhetskontroller eller påverkat tillgängligheten i en tjänst. RubyGems stängde registreringarna i fyra dagar och läste trafiken som ett DDoS-angrepp. Forskarna säger att communityt aldrig fick veta något.

Sätt fönstret till 18 juni

Rapporteringen har ramat in detta som fyra dagar i maj, eftersom det var så länge registreringen var stängd. Agenterna kom tillbaka. Fem paket till gick upp den 26 och 27 maj. Ytterligare 83 följde under tre timmar den 18 juni, efter att RubyGems hade infört krav på verifierade e-postadresser och hastighetsbegränsning vid nyregistrering. Junipaketen testade vägar till ett dataset hos amerikanska SEC, kedjat via Google Translate och Jira.

Julirättningen har också en svans. RubyGems återkallade samtliga legacy-nycklar. Rådgivningen noterar att en ägare som lagts till med en sådan nyckel, eller en trusted publisher som registrerats med en, överlever återkallandet. Nyckelhistoriken visar inte att något av detta har skett. Publicerar du gems: öppna ägar- och trusted publisher-inställningarna för vart och ett. Konsumerar du bara gems: kör genomgången från 5 maj till 18 juni i stället för de fyra dagarna i maj som rubrikerna fastnade vid.