Sikkerhetsforskere oppdaget to metoder for å bryte ut av OpenAI Codex-sandkassen og få tilgang til ressurser på vertsdatamaskinen. OpenAI skal ha rettet begge sårbarhetene innen åtte dager, men én av feilene gjorde det mulig å kjøre kommandoer fra den strengeste sandkassemodusen.
Forskere oppdager to feil i Codex
Oren Yomtov fra Accomplish AI og andre forskere rapporterte begge sårbarhetene til OpenAI 12. august.
Den første teknikken, kalt Heapjack, påvirket en komponent som Codex Desktop og Codex CLI brukte. Ifølge forskerne kunne den kjøre kommandoer utenfor sandkassen uten å be om godkjenning eller vise synlig aktivitet.
Den andre feilen, kalt Overpatch, gjorde det mulig for Codex’ patchverktøy å skrive utenfor den tillatte prosjektkatalogen.
OpenAI rettet Heapjack i Codex Desktop-versjon 26.818.21641. Samtidig løste selskapet Overpatch i Codex CLI-versjon 0.149.0.
Brukere bør installere disse eller nyere versjoner.
Heapjack retter seg mot delt minne
Heapjack rettet seg mot en komponent kalt node_repl. Codex Desktop la til komponenten i den globale konfigurasjonsfilen for Codex under installasjonen.
Ifølge forskerne trengte ikke brukerne å aktivere funksjonen manuelt. Den globale konfigurasjonen gjorde dessuten at brukere av Codex CLI arvet verktøyet.
Komponenten kjørte én Node.js-prosess med to kjøringskontekster for JavaScript. En betrodd kontekst inneholdt OpenAIs kode, mens en ikke-klarert kontekst håndterte agentens kode.
Den betrodde konteksten autentiserte seg med et tilfeldig token som ble opprettet under hver økt. Begge kontekstene kjørte imidlertid i den samme Node.js-prosessen og delte den samme minneheapen.
Dermed kunne den ikke-klarerte konteksten søke gjennom det delte minnet etter autentiseringstokenet.
Ikke-klarert kode finner det hemmelige tokenet
Forskerne brukte Node.js-funksjonalitet til å ta et øyeblikksbilde av prosessminnet.
Den ikke-klarerte koden søkte deretter etter strenger som samsvarte med det forventede tokenformatet. Den sendte inn mulige tokener og observerte svarene.
Et feil token ga en autorisasjonsfeil. Et riktig token kombinert med et ugyldig argument returnerte imidlertid et annet valideringssvar.
Denne forskjellen i oppførsel bekreftet når koden hadde identifisert det gyldige tokenet.
Angrepet kunne deretter skrive sin egen forespørsel til kommunikasjonskanalen som den betrodde konteksten brukte. Denne kanalen var koblet til en overordnet prosess som kjørte utenfor sandkassen.
Fordi forespørselen inneholdt det gyldige tokenet, godtok den overordnede prosessen den som betrodd.
Heapjack muliggjør kommandokjøring på vertssystemet
Konseptbeviset for Heapjack brukte vertssystemets open-kommando til å starte et program.
Programmet kjørte utenfor prosesstreet til Codex. Derfor kunne sandkassen ikke lenger kontrollere aktiviteten.
Ifølge forskerne kunne den samme tilgangen nå Unix-sockets og andre ressurser på vertssystemet. Potensielle mål omfattet sockets for Docker-demonen og verktøy som endrer den globale Codex-konfigurasjonen.
Angrepet fungerte angivelig i skrivebeskyttet modus, som har de strengeste sandkassebegrensningene. I denne modusen skal agenten ikke kunne skrive filer eller kjøre kommandoer utenfor det isolerte miljøet.
Utbruddet fra Codex-sandkassen undergravde derfor hovedbeskyttelsen som skal begrense ikke-klarert innhold i kodelagre.
Skadelig kodelager kunne utløse Heapjack
Forskerne beskrev et scenario med et skadelig kodelager.
En utvikler kunne åpne en annen persons kodelager i Codex og stille agenten et vanlig spørsmål om koden. Skjulte instruksjoner i kodelageret kunne deretter påvirke agenten.
Disse instruksjonene kunne få Codex til å utnytte Heapjack. Dermed kunne personen bak kodelageret potensielt kjøre kommandoer utenfor sandkassen på utviklerens datamaskin.
Utvikleren ville ikke trenge å godkjenne handlingen. Grensesnittet ville dessuten kanskje ikke vise noen synlig advarsel mens angrepet pågikk.
Denne angrepsveien gjorde sårbarheten særlig alvorlig. Utviklere bruker ofte kodeagenter til å undersøke ukjente kodelagre, feilsøke prosjekter og forklare kildekode.
Overpatch omgår begrensninger for arbeidsområdet
Det andre utbruddet fra Codex-sandkassen, kalt Overpatch, påvirket Codex CLI med åpen kildekode.
I workspace-write-modus kan Codex endre filer i den aktive prosjektkatalogen. Sandkassen skal imidlertid blokkere forsøk på å skrive andre steder.
En direkte shell-kommando som retter seg mot brukerens hjemmekatalog, skal for eksempel mislykkes.
Forskerne oppdaget at Codex’ apply_patch-verktøy kunne omgå denne begrensningen. Verktøyet beregnet sine egne skrivetillatelser ut fra stiene i en patch.
Når en patch henviste til en katalog, ga systemet tilgang til den overordnede katalogen til denne stien. Dermed kunne en nøye utvalgt sti utvide det tillatte området.
Patch-utnyttelse når hjemmekatalogen
Forskerne opprettet en patch som inneholdt to endringer.
Den første endringen henviste til en midlertidig katalog. Selv om den ikke utførte noen betydelig endring, utvidet den området som patchverktøyet kunne få tilgang til.
Den andre endringen rettet seg mot en symbolsk lenke som førte til brukerens hjemmekatalog. Gjennom denne lenken la patchen til en kommando i konfigurasjonsfilen .zshrc.
Uten den første endringen avviste sandkassen skriveoperasjonen. Da begge endringene var inkludert, kunne operasjonen imidlertid gjennomføres.
Den skadelige linjen ville deretter kjøre utenfor sandkassen når utvikleren åpnet en ny terminaløkt.
I motsetning til Heapjack krevde Overpatch workspace-write-modus. Likevel krysset angrepet en grense som skulle ha begrenset endringene til prosjektmappen.
Begge feilene deler det samme designproblemet
Heapjack og Overpatch påvirket forskjellige komponenter, men forskerne identifiserte en felles sikkerhetsfeil.
I begge tilfellene stolte systemet på informasjon som ble kontrollert fra innsiden av miljøet det forsøkte å begrense.
Patchverktøyet beregnet tillatelser ut fra angriperkontrollerte stier. Samtidig lagret node_repl autentiseringshemmeligheten sin i minne som ble delt med ikke-klarert kode.
Dermed bidro den beskyttede komponenten til å avgjøre om en handling skulle få krysse dens egen sikkerhetsgrense.
En sterkere utforming ville håndheve grensen gjennom en separat prosess eller komponent. Ikke-klarert kode bør ikke få tilgang til hemmeligheten eller kontrollere dataene som brukes til å beregne tillatelser.
AI-kodeagenter møter større sandkasserisikoer
Funnene om utbruddet fra Codex-sandkassen gjenspeiler en større utfordring som påvirker AI-baserte kodeverktøy.
Kodeagenter samhandler regelmessig med ikke-klarerte kildefiler, konfigurasjonsdata og prosjektinstruksjoner. Samtidig trenger de nok systemtilgang til å kjøre tester og endre kode.
Angripere kan utnytte denne kombinasjonen gjennom skadelige kodelagre. Skjulte instruksjoner kan få en agent til å opprette filer eller aktivere betrodde verktøy utenfor sandkassen.
Forskere demonstrerte lignende teknikker mot flere kodeagenter i juli 2026. Disse angrepene holdt agenten inne i sandkassen, men opprettet filer som betrodde eksterne verktøy senere kjørte.
Derfor er det kanskje ikke nok å sikre bare agenten. Utviklere må også vurdere hvordan handlinger i sandkassen samhandler med programvare som kjører på vertssystemet.
Codex-brukere bør oppdatere umiddelbart
OpenAI skal ha rettet begge sårbarhetene innen åtte dager etter at selskapet mottok forskernes rapport.
Brukere bør oppdatere Codex Desktop til versjon 26.818.21641 eller nyere. De bør også installere Codex CLI-versjon 0.149.0 eller en nyere utgave.
Utviklere bør være særlig forsiktige når de åpner ukjente kodelagre med AI-kodeagenter. Et prosjekt kan inneholde skadelige instruksjoner selv om kildekoden virker ufarlig.
Ved å holde Codex oppdatert lukkes de to rapporterte sårbarhetene. Utviklere bør likevel fortsette å behandle ikke-klarerte kodelagre som potensielt farlig innhold.
0 responses to “Forskere bryter ut av OpenAI Codex-sandkassen og kjører kommandoer på vertssystemet”