Tre forskere brugte måneder på ikke at angribe sandkassen
Eilon Cohen, Dan Lisichkin og Ariel Fogel fra Pillar Security stillede et snævert spørgsmål til de sandkasser, der følger med AI-kodeagenter. Ikke om murene holder, men om murene står det rigtige sted. Den 20. juli 2026 begyndte de at offentliggøre svaret som en serie, de kalder Week of Sandbox Escapes, med ét indlæg om dagen om Cursor, OpenAI Codex CLI, Google Gemini CLI og Google Antigravity.
I hvert eneste tilfælde opførte agenten sig, som den skulle. Den holdt sig inden for det arbejdsområde, den havde fået, og brød ingen af de regler, sandkassen håndhæver. Den skrev en fil. En proces uden for sandkassen læste bagefter filen, stolede på den og kørte det, der stod i den. Udbruddet skete, uden at agenten på noget tidspunkt rørte grænsen.
Pillar samler fundet i én sætning: en agents skadesradius er ikke agentprocessen, den er alt det, agenten kan skrive, og som værten bagefter stoler på. Netop dét er historien, og det er grunden til, at sagen ikke er lukket, selv om de enkelte fejl bliver rettet.
Én socket forklarer tre af de fire produkter
Det klareste fund er samtidig det mindst eksotiske. Codex CLI, Cursor og Gemini CLI kunne alle nå værtens lokale Docker-socket inde fra deres sandkasser. En privilegeret dæmon på værten starter uden videre en container for enhver, der kan tale med den, og den container kører helt uden for sandkassen. Én enkelt advisory, GHSA-v4xv-rqh3-w9mc, dækker tre af de fire testede produkter. Den er rettet.
Codex havde desuden en svaghed af en helt anden type. Tilladelseslisten over sikre kommandoer godkendte kommandoer ud fra navnet alene. Den lod git show passere som en ren læseoperation uden at tage højde for, hvad farlige argumenter til git show rent faktisk kan sætte i gang. Det er rettet i version 0.95.0, og indberetningen udløste en dusør i kategorien høj alvorlighed.
Læser man de to fund sammen, træder mønsteret frem. Begge dele er tilladelseslister. Begge er skrevet ud fra det, en driftsansvarlig kan få øje på, en sti til en socket og et kommandonavn, og ikke ud fra, hvad de ting kan sætte i gang, når nogen først har fat i dem.
Udbruddene kom gennem filer, din editor i forvejen stoler på
Cursor stod for tre af dem. En agent kunne skrive fortolkeren i et virtuelt Python-miljø om og så vente på, at editorens egen Python-udvidelse, der kører helt uden sandkasse, kørte den. Den kunne oprette en Git-mappe under et navn uden for standarden, så de stibaserede sandkasseregler ikke slog til, og lade fsmonitor tage den op. Og den kunne lægge en hook-konfiguration ind i arbejdsområdet, som værktøjerne derefter kørte uden sandkasse. Den sidste har fået CVE-2026-48124 og advisory GHSA-pc9j-3qc2-95wv, og alle tre er rettet i Cursor 3.0.0.
Googles to fund hører til samme familie. Den Seatbelt-profil på macOS, der ligger bag Antigravity, var skrevet som en blokeringsliste, og en blokeringsliste tillader alt, der ikke udtrykkeligt er nævnt. Dertil kom, at en opgavekonfiguration i .vscode kunne komme uden om beskyttelsen i Secure Mode. Google kaldte over for forskerne rapporten enestående i kvalitet, klassificerede derefter fundene som svære at udnytte, fordi de kræver social manipulation, og nedgraderede dem på det grundlag.
Klassifikationen kan forsvares på sine egne præmisser og er alligevel uden betydning for den, der har værktøjerne i drift. For en agent er social manipulation en sætning i en README, en kommentar til en sag eller et afsnit i dokumentationen til en afhængighed. At læse ikke-betroet tekst er agentens helt almindelige arbejdsdag.
Den grænse, du købte, er ikke den grænse, du har
Alle disse produkter fremstiller sandkassen som den kontrol, der gør autonom programmering acceptabel. Det er det svar, en sikkerhedsgennemgang får, og det er grunden til, at godkendelserne blev givet. Undersøgelsen viser, at sandkassen styrer én ting, nemlig agentprocessen. Den har aldrig været en påstand om arbejdsområdet.
Arbejdsområdet er den egentlige angrebsflade, for arbejdsområdet bliver læst af en lang række processer, der blev tegnet år før agenterne fandtes, og som alle går ud fra, at et menneske har skrevet det, de læser. Python-udvidelsen. Git-dæmonen. Docker-socketen. Pre-commit-hooket. Installationsværktøjet til afhængigheder. CI-kørslen, der kloner grenen. Ingen af dem er bygget til at betragte indholdet i et repository som fjendtligt input, og hver eneste af dem gør nu netop det.
Dermed er styringen rettet mod det forkerte. Ejerne har godkendt agenter. Det, der har brug for en politik, er arbejdsområdet, og reglen er kort: et repository, som en AI-agent kan skrive i, er ikke-betroet input til hver eneste proces længere nede i kæden, på lige fod med en fil, en fremmed har uploadet.
Hvad du bør ændre i denne uge
Begynd med socketen, for én advisory dækkede tre af de fire produkter. Ingen kodeagent har brug for adgang til en Docker-socket, og at fjerne adgangen er en konfigurationsændring og ikke et projekt. Opgradér derefter versionerne. Cursor 3.0.0 og Codex CLI 0.95.0 er de rettede linjer, og udviklingsværktøjer opdateres pr. bruger og ikke pr. maskinpark, så en leverandør, der har udsendt en rettelse, er ikke det samme som ingeniører, der har den installeret.
Den holdbare ændring ligger i, hvor agenterne kører. En gren, en agent har været inde i, bør nå frem til CI som ikke-betroet, og i praksis vil det sige, at pipelinen ikke kører hooks, opgaver eller fortolkere fra den gren, før et menneske har godkendt ændringerne. Det er en beslutning om pipelinen og ikke om værktøjerne, og den holder også efter den næste offentliggørelse.
Under NIS2 er en hændelse, der begynder i en udviklers editor og ender i din produktionspipeline, anmeldelsespligtig inden for samme frist som enhver anden hændelse. Pligten skelner ikke mellem en angriber, der har phishet en ingeniør, og en agent, der har læst en forgiftet README, så kontrollen skal sidde der, hvor pipelinen kan håndhæve den.
Læs videre: nginx-rettelsen er ude, exploitet kommer i august | ServiceNow patchede sin egen sky først, dig 103 dage senere
