Sikkerhedsforskere opdagede to metoder til at bryde ud af OpenAI Codex-sandkassen og få adgang til ressourcer på værtscomputeren. OpenAI rettede angiveligt begge sårbarheder inden for otte dage, men én af fejlene gjorde det muligt at køre kommandoer fra den strengeste sandkassetilstand.
Forskere opdager to fejl i Codex
Oren Yomtov fra Accomplish AI og andre forskere rapporterede begge sårbarheder til OpenAI den 12. august.
Den første teknik, kaldet Heapjack, påvirkede en komponent, som Codex Desktop og Codex CLI brugte. Ifølge forskerne kunne den køre kommandoer uden for sandkassen uden at anmode om godkendelse eller vise synlig aktivitet.
Den anden fejl, kaldet Overpatch, gjorde det muligt for Codex’ patchværktøj at skrive uden for den tilladte projektmappe.
OpenAI rettede Heapjack i Codex Desktop-build 26.818.21641. Samtidig løste virksomheden Overpatch i Codex CLI-version 0.149.0.
Brugere bør installere disse eller nyere versioner.
Heapjack angriber delt hukommelse
Heapjack var rettet mod en komponent kaldet node_repl. Codex Desktop føjede komponenten til den globale konfigurationsfil for Codex under installationen.
Ifølge forskerne behøvede brugerne ikke at aktivere funktionen manuelt. Desuden gjorde den globale konfiguration det muligt for Codex CLI-brugere at arve værktøjet.
Komponenten kørte en enkelt Node.js-proces med to JavaScript-eksekveringskontekster. En betroet kontekst indeholdt OpenAI’s kode, mens en ikke-betroet kontekst håndterede agentens kode.
Den betroede kontekst autentificerede sig med et tilfældigt token, der blev oprettet under hver session. Begge kontekster kørte dog i den samme Node.js-proces og delte den samme hukommelsesheap.
Derfor kunne den ikke-betroede kontekst gennemsøge den delte hukommelse efter autentificeringstokenet.
Ikke-betroet kode finder det hemmelige token
Forskerne brugte Node.js-funktionalitet til at tage et øjebliksbillede af processens hukommelse.
Den ikke-betroede kode søgte derefter efter strenge, der matchede det forventede tokenformat. Den indsendte mulige tokens og observerede svarene.
Et forkert token udløste en autorisationsfejl. Det korrekte token kombineret med et ugyldigt argument returnerede dog et andet valideringssvar.
Denne forskel i adfærd bekræftede, hvornår koden havde identificeret det gyldige token.
Angrebet kunne derefter skrive sin egen anmodning til den kommunikationskanal, som den betroede kontekst brugte. Denne kanal oprettede forbindelse til en overordnet proces, der kørte uden for sandkassen.
Fordi anmodningen indeholdt det gyldige token, accepterede den overordnede proces den som betroet.
Heapjack muliggør kørsel af kommandoer på værtssystemet
Heapjack-konceptbeviset brugte værtssystemets open-kommando til at starte en applikation.
Applikationen kørte uden for Codex’ procestræ. Derfor kunne sandkassen ikke længere kontrollere dens aktivitet.
Ifølge forskerne kunne den samme adgang nå Unix-sockets og andre ressourcer på værtssystemet. Potentielle mål omfattede sockets til Docker-dæmonen og værktøjer, der ændrer den globale Codex-konfiguration.
Angrebet virkede angiveligt i skrivebeskyttet tilstand, som har de strengeste sandkassebegrænsninger. I denne tilstand bør agenten ikke kunne skrive filer eller køre kommandoer uden for sit isolerede miljø.
Udbruddet fra Codex-sandkassen underminerede derfor den primære beskyttelse, som skulle inddæmme ikke-betroet indhold fra kodelagre.
Skadeligt kodelager kunne udløse Heapjack
Forskerne beskrev et scenarie med et skadeligt kodelager.
En udvikler kunne åbne en anden persons kodelager i Codex og stille agenten et almindeligt spørgsmål om koden. Skjulte instruktioner i kodelageret kunne derefter påvirke agenten.
Instruktionerne kunne få Codex til at udnytte Heapjack. Dermed kunne kodelagerets skaber potentielt køre kommandoer uden for sandkassen på udviklerens computer.
Udvikleren behøvede ikke at godkende handlingen. Desuden viste brugerfladen muligvis ingen synlig advarsel, mens angrebet kørte.
Denne angrebsvej gjorde sårbarheden særligt alvorlig. Udviklere bruger ofte kodeagenter til at undersøge ukendte kodelagre, fejlfinde projekter og forklare kildekode.
Overpatch omgår begrænsninger for arbejdsområdet
Det andet udbrud fra Codex-sandkassen, kaldet Overpatch, påvirkede Codex CLI med åben kildekode.
I workspace-write-tilstand kan Codex ændre filer i den aktive projektmappe. Sandkassen bør dog blokere forsøg på at skrive andre steder.
Eksempelvis bør en direkte shell-kommando rettet mod brugerens hjemmemappe mislykkes.
Forskerne fandt ud af, at Codex’ apply_patch-værktøj kunne omgå denne begrænsning. Værktøjet beregnede sine egne skrivetilladelser ud fra stierne i en patch.
Når en patch henviste til en mappe, gav systemet adgang til den pågældende stis overordnede mappe. Derfor kunne en nøje udvalgt sti udvide det tilladte område.
Patch-udnyttelse når hjemmemappen
Forskerne oprettede en patch med to ændringer.
Den første ændring henviste til en midlertidig mappe. Selvom den ikke foretog nogen væsentlig ændring, udvidede den det område, som patchværktøjet kunne tilgå.
Den anden ændring var rettet mod et symbolsk link, der førte til brugerens hjemmemappe. Gennem linket føjede patchen en kommando til konfigurationsfilen .zshrc.
Uden den første ændring afviste sandkassen skrivehandlingen. Når begge ændringer var inkluderet, kunne handlingen dog gennemføres.
Den skadelige linje ville derefter køre uden for sandkassen, når udvikleren åbnede en ny terminalsession.
I modsætning til Heapjack krævede Overpatch workspace-write-tilstand. Ikke desto mindre krydsede angrebet en grænse, som burde have begrænset ændringerne til projektmappen.
Begge fejl deler det samme designproblem
Heapjack og Overpatch påvirkede forskellige komponenter, men forskerne identificerede en fælles sikkerhedsfejl.
I begge tilfælde stolede systemet på oplysninger, der blev kontrolleret inde fra det miljø, som det forsøgte at begrænse.
Patchværktøjet beregnede tilladelser ud fra angriberkontrollerede stier. Samtidig opbevarede node_repl sin autentificeringshemmelighed i hukommelse, der blev delt med ikke-betroet kode.
Derfor var den beskyttede komponent med til at afgøre, om en handling måtte krydse dens egen sikkerhedsgrænse.
Et stærkere design ville håndhæve grænsen gennem en separat proces eller komponent. Ikke-betroet kode bør ikke kunne få adgang til hemmeligheden eller styre de data, der bruges til at beregne tilladelser.
AI-kodeagenter står over for større sandkasserisici
Resultaterne om udbruddet fra Codex-sandkassen afspejler en bredere udfordring for AI-kodeværktøjer.
Kodeagenter interagerer regelmæssigt med ikke-betroede kildefiler, konfigurationsdata og projektinstruktioner. Samtidig har de brug for tilstrækkelig systemadgang til at køre tests og ændre kode.
Angribere kan misbruge denne kombination gennem skadelige kodelagre. Skjulte instruktioner kan overtale en agent til at oprette filer eller aktivere betroede værktøjer uden for sandkassen.
Forskere demonstrerede lignende teknikker mod flere kodeagenter i juli 2026. Disse angreb holdt agenten inde i sandkassen, men oprettede filer, som betroede eksterne værktøjer senere kørte.
Derfor er det muligvis ikke tilstrækkeligt kun at sikre agenten. Udviklere skal også overveje, hvordan handlinger i sandkassen interagerer med software, der kører på værtssystemet.
Codex-brugere bør opdatere med det samme
OpenAI rettede angiveligt begge sårbarheder inden for otte dage efter at have modtaget forskernes rapport.
Brugere bør opdatere Codex Desktop til build 26.818.21641 eller nyere. De bør også installere Codex CLI-version 0.149.0 eller en nyere udgave.
Udviklere bør være særligt forsigtige, når de åbner ukendte kodelagre med AI-kodeagenter. Et projekt kan indeholde skadelige instruktioner, selvom dets kildekode virker harmløs.
Ved at holde Codex opdateret lukkes de to rapporterede sårbarheder. Udviklere bør dog fortsat behandle ikke-betroede kodelagre som potentielt farligt indhold.
0 svar til “Forskere bryder ud af OpenAI Codex-sandkassen og kører kommandoer på værtssystemet”