Codex-verktøy stjal OpenAI-tokens fra utviklere

Et utviklerverktøy for OpenAI Codex ble brukt som lokkemiddel i et mer avansert supply chain-angrep enn den vanlige typosquat-historien. Pakken het codexui-android, lå på npm, hadde et ekte GitHub-prosjekt rundt seg og leverte faktisk funksjonalitet: et fjernstyrt webgrensesnitt for Codex.

Ifølge Aikido Security inneholdt npm-versjonene likevel ekstra kode som ikke lå i GitHub-repoet. Den koden leste ~/.codex/auth.json, eller tilsvarende CODEX_HOME/auth.json, og sendte innholdet til sentry.anyclaw.store/startlog. Dataene omfattet blant annet access_token, refresh_token, id_token og konto-ID.

Det gjør saken mer alvorlig enn nok et lite npm-havari. Codex-tokenet er ikke bare en API-nøkkel i en testmappe. Det kan være koblet til en utviklers faktiske OpenAI- eller ChatGPT-konto, arbeidsflyt og rettigheter. OpenAI advarer selv i dokumentasjonen om at ~/.codex/auth.json må behandles som et passord når filbasert lagring brukes.

The Hacker News omtalte saken bredt mandag og skriver at pakken hadde over 29.000 ukentlige nedlastinger. Aikido oppga opprinnelig rundt 27.000. npm sitt eget nedlastingsendepunkt viser 29.145 nedlastinger for siste uke på sjekktidspunktet. Det er ikke et gigantisk tall sammenlignet med de største pakkene, men nok til at dette treffer et reelt utviklermiljø.

Den viktige detaljen er hvordan angrepet var pakket inn. GitHub-koden så ren ut. Den skadelige delen lå i artefakten som faktisk ble publisert på npm. Det betyr at en vanlig kildekodegjennomgang av repoet ikke ville vært nok. Kontrollen måtte ha skjedd på pakken som installeres.

Aikido skriver at koden kjørte ved oppstart, før applikasjonslogikken. Den sjekket om auth-filen fantes, krypterte innholdet enkelt og sendte det til et domene som lignet legitim Sentry-telemetri. Feil ble undertrykt. En utvikler som bare så trafikk til noe som startet med sentry, kunne lett avfeie det som ordinær logging.

Android gjorde angrepsflaten større

Aikido peker også på Android-apper fra samme miljø som en ekstra distribusjonsvei. Appene skal ha pakket en Termux-lignende Linux-runtime og kjørt Node.js i en PRoot-sandkasse. Ved oppstart hentet de codexui-android@latest, uten å pinne versjonen. Dermed kunne en endring i npm-pakken automatisk bli kjørt i appmiljøet.

The Hacker News skriver at én av Android-appene hadde mer enn 50.000 nedlastinger, og at en annen relatert app hadde over 10.000. Det betyr ikke at alle brukere nødvendigvis fikk tokens stjålet. Men det viser hvorfor AI-utviklerverktøy ikke lenger kan vurderes som små lokale hjelpemidler. De kan fungere som distribusjonskanaler for konto- og kildekodetilgang.

På GitHub svarte maintaineren at saken ble undersøkt og at berørt funksjonalitet og relatert data var under fjerning. Ifølge Aikido ble ikke det sentrale spørsmålet besvart: hvorfor koden bare lå i npm-pakken og ikke i GitHub-kilden, og hvorfor et domene under samme miljø tok imot tokens. Her bør virksomheter ikke vente på en pen forklaring før de rydder opp.

Hva norske CIO-er og CISO-er bør ta med seg

Første poeng: AI-verktøy er nå en del av programvareforsyningskjeden. Det gjelder ikke bare modellleverandøren. Det gjelder CLI-er, nettleserutvidelser, GitHub Actions, VS Code-utvidelser, mobilapper, lokale wrappers og små npm-pakker som utviklere installerer for å spare ti minutter.

Andre poeng: kildekoden er ikke hele sannheten. Dette angrepet utnyttet avstanden mellom et legitimt repo og en publisert installasjonspakke. Derfor må kontrollregimet se på artefakter, checksums, provenance, publiseringshistorikk og installasjonsatferd. Det er ikke nok å peke på at «GitHub så greit ut».

Tredje poeng: token-lagring må behandles som privilegert identitet. Mange virksomheter har gode prosesser for AWS-nøkler og GitHub PAT-er, men svakere rutiner for AI-verktøyenes lokale auth-filer. Den forskjellen holder ikke. Hvis en Codex-klient har tilgang til virksomhetens kode, arbeidsområder eller enterprise-kontroller, er tokenet en produksjonshemmelighet.

Praktiske tiltak nå er ganske konkrete. Sjekk om codexui-android finnes i utviklermiljøer, lockfiler, lokale npm-cacher, images eller mobile testoppsett. Søk i DNS-, proxy- og EDR-logger etter sentry.anyclaw.store og /startlog. Roter eller tilbakekall berørte OpenAI-/Codex-sesjoner. Og sett policy for at AI-verktøy som installerer @latest i runtime ikke får kjøre i virksomhetsmiljø uten eksplisitt godkjenning.

For sikkerhetsmiljøet er saken også et varsel om hvor attraktivt AI-utviklerøkosystemet har blitt. Angriperen trenger ikke lenger gå rett på produksjonsserveren. Det kan holde å bygge et nyttig lite verktøy, få utviklere til å bruke det og vente til tokenene begynner å tikke inn.

Dette er derfor ikke en marginal npm-historie. Det er en tidlig mal for hvordan angrep mot AI-arbeidsflyter vil se ut: legitim nytte først, skjult eksfiltrering etterpå, og tokens som bro videre inn i kode, data og automatisering.

Kilder og medier

Primærkilde: Aikido Security, Charlie Eriksen, «Legitimate-Looking Codex Remote UI Secretly Steals Your AI Tokens», publisert 27. mai 2026 og oppdatert 28. mai 2026: https://www.aikido.dev/blog/codex-remote-ui-steals-ai-tokens

Kreditering: Aikido Security står for den tekniske hovedanalysen av codexui-android, npm-artefakten, Android-vektoren og exfil-endepunktet.

Top-tier sikkerhetsdekning: The Hacker News, «OpenAI Codex Authentication Tokens Stolen in codexui-android npm Supply Chain Attack», publisert 1. juni 2026: https://thehackernews.com/2026/06/openai-codex-authentication-tokens.html

OpenAI-dokumentasjon om Codex-autentisering og lokal tokenlagring: https://developers.openai.com/codex/auth

npm-nedlastingsdata for codexui-android: https://api.npmjs.org/downloads/point/last-week/codexui-android

GitHub-tråd med disclosure og maintainer-svar: https://github.com/friuns2/codex-mobile/issues/198

Thumbnail: OpenAI Image 2 / hogby.ai