Cloudflare bekreftet 24. september 2026 at selskapet har rettet en sårbarhet i containerplattformen Cloudflare Containers og den avledede tjenesten Cloudflare Sandboxes. Feilen kunne i teorien la en betalende kunde lese rester av data som tidligere tilhørte en annen kunde på samme fysiske server. Sikkerhetsforsker Oren Yomtov i det israelske selskapet Accomplish meldte funnet gjennom Cloudflares bug bounty-program 4. september klokken 15:26 UTC, og Cloudflare rullet ut en første rettelse mindre enn åtte timer senere. Saken er en påminnelse om hvor tynn linjen mellom isolasjon og innsyn kan være i delt skyinfrastruktur. Den treffer også et tidspunkt der stadig flere nordiske selskaper flytter arbeidslaster til nettopp slike containertjenester i kanten av nettet.
Ifølge Cloudflares egen gjennomgang er det ingen tegn til at feilen faktisk ble misbrukt av andre enn forskerne selv og Cloudflares eget valideringsteam. Likevel er den tekniske forklaringen verdt å bruke tid på, fordi den peker på en svakhet som ikke handler om et klassisk containerutbrudd, men om hva som skjer i lagringslaget under virtuelle maskiner som i utgangspunktet er godt isolert.
Hva Cloudflare oppdaget i Containers og Sandboxes
Cloudflare Containers er en tjeneste der kunder kan kjøre eget kode i containere som Cloudflare automatisk plasserer på ledige servere i nettverket. Kunden velger ikke selv hvilken fysisk vert containeren havner på. Cloudflare Sandboxes bygger på samme underliggende plattform og markedsføres spesifikt for å kjøre uklarert kode, inkludert kode generert av AI-agenter som ikke er gjennomgått av et menneske først.
Forskerne demonstrerte at en kunde med en betalt Workers Paid-konto kunne hente ut rester av diskblokker som tidligere hadde vært brukt av andre kunders containere på samme vert. Angriperen kunne ikke velge offer, vert eller hvilke data som skulle dukke opp, og det var heller ingen garanti for at rester i det hele tatt fantes. Cloudflare skriver at selskapet har rettet feilen i hele Containers-flåten, at ingen kundetiltak er nødvendig, og at gjennomgang av historisk disk-I/O-telemetri ikke har avdekket ondsinnet utnyttelse. Det finnes foreløpig ikke noe eget CVE-nummer knyttet til hendelsen.
Slik fungerte datalekkasjen: gjenbrukte lagringsblokker uten nullstilling
Roten til problemet ligger i hvordan Cloudflare Containers håndterer diskplass. Hver container får en skrivbar rotdisk gjennom Linux-teknologien device mapper thin provisioning, forkortet dm-thin. Denne teknikken tildeler fysisk lagring først når en virtuell disk faktisk skriver til et område som ikke er brukt før. De berørte lagringspoolene brukte en blokkstørrelse på 64 KiB, og da en containers rotdisk ble slettet, gikk de fysiske blokkene tilbake til en delt pool som betjener arbeidslaster fra flere ulike kundekontoer.
Problemet oppstod fordi lagringspoolen var konfigurert med et alternativ kalt skip_block_zeroing. Normalt nullstiller dm-thin en gjenbrukt blokk før den gjøres tilgjengelig for en ny container. Med nullstilling avslått ble en tidligere brukt 64 KiB-blokk kun delvis overskrevet dersom den nye containeren skrev mindre enn hele blokken. Resten kunne fortsatt inneholde data fra forrige eier.
Selve teknikken i konseptbeviset var enkel å beskrive, selv om den krevde presist arbeid å utføre. Forskerne identifiserte 64 KiB-justerte områder som tilsvarte ledig plass i containerens ext4-filsystem, og skrev nøyaktig én 4 KiB-blokk inn i hvert slikt område. Når skrivingen traff et ikke-tildelt område, allokerte dm-thin en hel 64 KiB-blokk fra den delte poolen. Skrivingen fylte kun 4 KiB av blokken, og fordi nullstilling var avslått, kunne de resterende 60 KiB fortsatt inneholde data fra en tidligere container. En etterfølgende rålesing av disken kunne da avsløre langt mer enn det den nye containeren selv hadde skrevet.
Firecracker isolerte prosessoren, lagringslaget sviktet
Det som gjør saken spesielt interessant for lesere som følger skyinfrastruktur tett, er at selve virtualiseringen fungerte som den skulle. Hver container kjører i en dedikert virtuell maskin drevet av Firecracker, samme mikro-VM-teknologi som blant annet AWS bruker til Lambda og Fargate. Firecracker presenterer rotdisken for den virtuelle maskinen som enheten /dev/vdc. Selve prosess- og minneisolasjonen mellom kundenes virtuelle maskiner ble aldri brutt i denne saken. Svakheten satt i laget under VM-en, i hvordan delt lagringsplass ble gjenbrukt mellom tenanter. Det er et nyttig skille: en VM-grense kan holde stand samtidig som datalekkasje skjer gjennom et helt annet lag av stabelen.
# Illustrasjon av forskjellen mellom trygg og risikabel thin-pool-konfigurasjon
# (generisk LVM-eksempel, ikke Cloudflares faktiske produksjonsoppsett)
# Trygg: nullstiller nye blokker før de gjenbrukes (standardoppførsel)
lvcreate --type thin-pool --zero y -L 500G -T vg_data/tp_containers
# Risikabelt: hopper over nullstilling for å spare I/O, men lekker gamle data
lvcreate --type thin-pool --zero n -L 500G -T vg_data/tp_containersBevisene: 2.700 fremmede mapper i seks produksjonsmiljøer
For å bevise at de faktisk leste andre kunders data, og ikke bare sine egne testfiler, brukte forskerne katalogblokk-sjekksummer fra ext4-funksjonen metadata_csum. Disse sjekksummene er bundet til det spesifikke filsystemet og inoden de tilhører, noe som gjør det mulig å skille mellom blokker som stammer fra forskerens eget testfilsystem og blokker som stammer fra andre.
På tvers av seks produksjonsplasseringer testet forskerne 5.614 katalogblokker. Ingen av dem ble tilskrevet forskernes eget filsystem, mens 2.700 distinkte fremmede katalog-inoder ble identifisert gjennom sjekksumanalysen. For å validere metoden testet de også blokker de selv hadde opprettet og slettet i et kontrollert testfilsystem, og metoden klarte å tilordne alle 162 slike blokker korrekt. Totalt fant forskerne rester av data på 18 av 24 forsøkte plasseringer og på 20 av 22 underliggende noder, spredt over fire kontinenter. Dataene som ble gjenfunnet inkluderte katalogstrukturer, databasesider og komplette SQLite-databaser. Cloudflare understreker at materialet forskerne sendte inn ikke inneholdt gjenkjennelig innhold, tredjepartsnavn eller legitimasjon, og at forskerne bekreftet å ha slettet alt gjenfunnet materiale etter innsending.
Tidslinjen: fra varsel til full opprydding på 15 dager
Det som skiller denne saken fra mange andre skysårbarheter, er hvor raskt Cloudflare beveget seg fra rapport til produksjonsfiks. Under åtte timer gikk fra Yomtovs innmelding til at utrulling av rettelsen startet. Full opprydding av alt gammelt hurtigbufferdata tok derimot nesten to uker ekstra, fordi nullstilling av nye blokker ikke i seg selv fjernet rester som allerede lå i eksisterende diskbilder og hurtigbufrede image-lag.
| Tidspunkt (UTC) | Hendelse |
|---|---|
| 4. sept, 15:26 | Oren Yomtov (Accomplish) rapporterer sårbarheten via Cloudflares bug bounty-program |
| 4. sept, 18:45 | Cloudflare åpner sikkerhetshendelse og bekrefter produksjonsoppsettet som forårsaket feilen |
| 4. sept, 21:27 | Cloudflare slår sammen kjøretidsrettelsen og tilhørende gjenbrukstest |
| 4. sept, 22:03 | Endringer slås sammen for både nye og aktive lagringspooler |
| 4. sept, 23:15 | Utrulling av rettelsen starter i produksjon |
| 7. sept, 06:13 | Utrulling fullført, opprydding av gammelt pooldata starter |
| 14. sept, 10:50 | Forskerne bekrefter at konseptbeviset ikke lenger fungerer |
| 14. sept, 12:52 | Cloudflare utbetaler bug bounty-belønning til forskeren |
| 19. sept, 15:03 | Opprydding av alle hurtigbufrede snapshot fra før rettelsen er fullført |
| 24. sept | Cloudflare offentliggjør hendelsen i et eget blogginnlegg |
Hvor alvorlig var lekkasjen egentlig?
Alvorlighetsgraden må vurderes nyansert. På den ene siden krysset feilen en grunnleggende sikkerhetsgrense mellom kunder i et delt skymiljø, noe som i prinsippet kunne avsløre filsystemmetadata, katalogstrukturer, databasesider og applikasjonsdata. På den andre siden kunne en angriper verken velge offer, treffe en aktivt tilkoblet disk, eller endre en annen kundes levende data. Eksponeringen var avhengig av tilfeldig plassering og hvilke tidligere frigitte blokker dm-thin valgte å gjenbruke.
Cloudflare bygde egne deteksjonssignaturer basert på det karakteristiske mønsteret mellom en liten skriving og en påfølgende, uforholdsmessig stor lesing, og kjørte disse mot historisk telemetri fra containerinfrastrukturen. Selskapet fant kun aktivitet som kunne tilskrives forskerne selv og Cloudflares egne ingeniører under godkjent validering, og ingen tegn til at noen andre hadde brukt samme teknikk. Det er en vesentlig forskjell fra saker der loggene rett og slett mangler, eller der selskapet ikke har hatt mulighet til å lete i etterkant.
Forskeren bak funnet: Oren Yomtov og Accomplish
Oren Yomtov jobber for sikkerhetsselskapet Accomplish og fant sårbarheten gjennom systematisk testing av hvordan Cloudflare Containers håndterer diskallokering på tvers av kunder. Rapporten ble sendt inn gjennom HackerOne, plattformen Cloudflare bruker til å drifte sitt bug bounty-program. Cloudflare skriver at innsendingen inneholdt detaljerte tellinger, blokkoffset, størrelser og sjekksumresultater, men ingen faktiske filnavn, identifikatorer eller legitimasjon fra tredjeparter.
Ti dager etter rapporten bekreftet forskerne selv at konseptbeviset deres ikke lenger fungerte, noe som ga Cloudflare uavhengig bekreftelse på at rettelsen virket. Samme dag utbetalte Cloudflare en bug bounty-belønning, uten at beløpet er offentliggjort. Prosessen er et eksempel på ansvarlig sårbarhetsrapportering slik den er ment å fungere: forskeren fikk tid og rom til å validere funnet grundig, samtidig som Cloudflare fikk mulighet til å rette feilen før detaljene ble gjort offentlige tre uker senere.
Historien gjentar seg: runc og container-utbrudd siden 2019
Cloudflare-saken er ikke den første isolasjonsglippen i containerverdenen, men den skiller seg fra de fleste tidligere hendelsene ved at den ikke involverer selve container-kjøretiden. De mest kjente sårbarhetene de siste årene har derimot rammet nettopp runc, komponenten som ligger under Docker, containerd og store deler av Kubernetes-økosystemet.
| CVE | Komponent | Når | Kort beskrivelse |
|---|---|---|---|
| CVE-2019-5736 | runc | Februar 2019 | Ondsinnet container kunne overskrive host-binæren runc og oppnå kjøring på vertsnivå |
| CVE-2024-21626 (“Leaky Vessels”) | runc | Januar 2024 | Lekket fildeskriptor ga containerprosess tilgang til vertens filsystem-namespace |
| CVE-2025-31133 | runc | November 2025 | Feil håndtering av maskerte stier kunne omgå isolasjon via ondsinnede filsystemobjekter |
| CVE-2025-52565 | runc | November 2025 | Race/symlink-svakhet knyttet til bind-mount av /dev/console |
| CVE-2025-52881 | runc | November 2025 | Del av samme 2025-klynge med mount- og symlink-relaterte isolasjonsbrudd |
Leaky Vessels: da en glipp ga tilgang til hele verten
CVE-2024-21626, kjent under kallenavnet Leaky Vessels, rammet runc-versjoner til og med 1.1.11 og fikk en alvorlighetsgrad på rundt 8,2 til 8,6 avhengig av angrepsvektor. Feilen gjorde det mulig for en container å lekke en fildeskriptor tilbake til verten, og dermed få tilgang utenfor sin egen filsystem-boks. Sammen med CVE-2019-5736 og 2025-klyngen av runc-svakheter viser dette et mønster: selve grensesnittet mellom container og vert har vært et tilbakevendende mål i syv år på rad. Cloudflare-saken utvider dette bildet ved å vise at selv når VM- og container-grensen holder, kan lagringslaget under fortsatt lekke.
Cloudflare mot AWS, Google og Azure: hvem isolerer best?
De store skyleverandørene løser isolasjon på ulike måter, og det er verdt å sammenligne dem direkte nå som Cloudflares tilnærming har vist en svakhet i praksis. AWS Fargate bygger på en virtualiseringsgrense og har historisk brukt nettopp Firecracker-teknologien til å kjøre oppgaver i egne mikro-VM-er, samme teknologi Cloudflare selv bruker til å kjøre containere. Google Cloud Run legger til et ekstra lag med gVisor, en sandkasse i brukerrom som fanger opp systemkall før de når vertskjernen. Azure Container Apps tilbyr et administrert, isolert kjøremiljø, men Microsoft offentliggjør ikke i detalj hvilken underliggende mikro-VM- eller sandkasseteknologi som brukes, så en direkte sammenligning på det punktet er vanskelig å gjøre presist.
| Leverandør | Tjeneste | Isolasjonstilnærming |
|---|---|---|
| Cloudflare | Containers / Sandboxes | Firecracker-mikro-VM per container, delt dm-thin lagringspool under |
| AWS | Fargate | Virtualiseringsgrense, historisk basert på Firecracker-mikro-VM-er |
| Google Cloud | Cloud Run | gVisor-sandkasse i brukerrom mellom container og vertskjerne |
| Microsoft Azure | Container Apps | Administrert isolert kjøremiljø, underliggende teknologi ikke offentliggjort i detalj |
Det ironiske poenget er at Cloudflare og AWS i praksis lener seg på den samme mikro-VM-teknologien for selve isolasjonen av kjøretiden. Forskjellen som avgjorde denne saken lå ikke i valg av virtualisering, men i en enkeltstående konfigurasjonsinnstilling i lagringslaget under. Det betyr at ingen av de fire leverandørene automatisk er tryggere enn de andre bare fordi de bruker en bestemt isolasjonsteknologi. Sikkerheten avhenger like mye av driftsdetaljer som av arkitekturvalg på papiret.
Markedseffekten: rammer dette tilliten til Cloudflare?
Det finnes ingen dokumentert kursbevegelse i Cloudflare-aksjen som kan knyttes direkte til offentliggjøringen 24. september, og selskapet har ikke omtalt hendelsen som vesentlig i børssammenheng. Det er heller ikke unormalt: enkeltstående sikkerhetsrapporter uten bekreftet kundeskade flytter sjelden aksjekurser alene, spesielt når selskapet selv legger frem funnet med full åpenhet før noen andre gjør det.
Det som trolig betyr mer for Cloudflares omdømme på lengre sikt, er måten saken ble håndtert på. Selskapet publiserte et teknisk detaljert blogginnlegg med presise tidsstempler, forfattet av fire navngitte ingeniører, og krediterte forskerne åpent i stedet for å tone ned funnet. Sammenlignet med hendelser der leverandører har ventet måneder på å innrømme sårbarheter, eller der detaljene kun kommer frem gjennom tredjeparts sikkerhetsmedier, fremstår denne responsen som et forsøk på å bygge tillit gjennom åpenhet snarere enn å skjule problemet. Om det faktisk demper bekymring hos bedriftskunder gjenstår å se, men strategien er en tydelig kontrast til bransjens tidligere normer.
Norske og nordiske skykunder: hva betyr dette i praksis
Norske og nordiske selskaper bruker i økende grad Cloudflares plattform til kanttjenester, API-er og nå også kjøring av AI-agenter som genererer og utfører egen kode. Nettopp den siste bruken gjør Sandboxes-tjenesten spesielt relevant, fordi den er bygget for å kjøre kode ingen mennesker har sett på forhånd. Dersom en slik agent kjører i et miljø der lagringslaget lekker rester fra andre kunder, øker den potensielle skaden, selv om selve angrepet i denne saken krevde en villet, målrettet handling fra en betalende kunde.
For selskaper som bruker containertjenester i skyen generelt, er lærdommen at leverandørvalg og arkitekturdiagrammer ikke forteller hele historien om isolasjon. Driftskonfigurasjon på lagringslaget, som denne ene innstillingen i dm-thin, kan i praksis bety mer for datasikkerheten enn hvilken mikro-VM-teknologi som står øverst i markedsføringen. Det er verdt å stille konkrete spørsmål til leverandøren om nettopp lagringsgjenbruk mellom tenanter, ikke bare om VM- eller containerisolasjon i seg selv.
GDPR og NIS2: det regulatoriske bildet for europeiske kunder
Så langt finnes det ingen offentlig kjent tilsynssak, bot eller pålegg knyttet til denne konkrete hendelsen. Cloudflare har selv konkludert med at det ikke er funnet bevis for at kundedata faktisk ble kompromittert, noe som er relevant for om hendelsen i det hele tatt utløser meldeplikt etter personvernforordningen GDPR. Om en europeisk kunde likevel må vurdere meldeplikt, avhenger av konkrete forhold som datakategori, omfang og reell risiko for de registrerte, og det er noe hver enkelt virksomhet må vurdere selv basert på egen bruk av tjenesten.
Det EU-direktivet NIS2 er også relevant for virksomheter som faller innenfor dets virkeområde, ettersom det stiller krav til hendelseshåndtering og rapportering ved sikkerhetshendelser som påvirker konfidensialitet eller tilgjengelighet i vesentlige og viktige tjenester. Hvorvidt NIS2 faktisk utløses av denne konkrete Cloudflare-saken for en gitt norsk virksomhet, avhenger av sektor, størrelse og hvordan regelverket er gjennomført nasjonalt. Det finnes ingen bekreftet norsk håndhevingssak knyttet til hendelsen per nå.
Slik sjekker du om organisasjonen din er eksponert
- Kartlegg om dere bruker Cloudflare Containers eller Cloudflare Sandboxes, og på hvilken kontotype (kun Workers Paid-kontoer kunne i praksis utnytte feilen som betjent).
- Sjekk om dere kjører sensitive data, hemmeligheter eller legitimasjon direkte på skrivbare containerdisker uten kryptering på applikasjonsnivå.
- Vurder om AI-agenter i deres miljø får kjøre kode i delte, multi-tenant kjøretidsmiljøer uten et ekstra isolasjonslag dere selv kontrollerer.
- Be leverandøren om skriftlig bekreftelse på at rettelsen er rullet ut og at gammelt hurtigbufferdata faktisk er fjernet, ikke bare en generell forsikring om at saken er lukket.
- Dokumenter vurderingen internt, uavhengig av konklusjon, slik at den kan vises frem dersom NIS2 eller GDPR-spørsmål dukker opp senere.
- Følg med på om det kommer et eget CVE-nummer for saken, siden det kan påvirke interne sårbarhetsrapporter og revisjoner.
Fem spådommer for container-sikkerhet i skyen fremover
- Flere skyleverandører vil gå gjennom egne thin-provisioning-konfigurasjoner og fjerne lignende ytelsesoptimaliseringer som hopper over nullstilling av gjenbrukte blokker.
- Bug bounty-programmer vil se en økning i rapporter rettet mot lagringslag og gjenbruk av ressurser mellom tenanter, ikke bare klassiske VM- og container-escape.
- Tjenester som er spesifikt bygget for å kjøre AI-genererte agenter, som Cloudflare Sandboxes og tilsvarende produkter hos konkurrenter, vil møte strengere krav til lagringsisolasjon fra bedriftskunder.
- Flere leverandører vil følge Cloudflares eksempel med detaljerte, tidsstemplede offentlige gjennomganger fremfor korte pressemeldinger, ettersom åpenhet i denne saken har blitt lagt merke til i sikkerhetsmiljøet.
- Europeiske kunder vil i økende grad stille konkrete spørsmål om lagringsisolasjon i sine leverandørvurderinger under NIS2, fremfor å nøye seg med generelle forsikringer om skysikkerhet.
Ofte stilte spørsmål om Cloudflare Containers-sårbarheten
Hva er Cloudflare Containers og Cloudflare Sandboxes?
Cloudflare Containers lar kunder kjøre egen kode i containere som automatisk plasseres på servere i Cloudflares nettverk, mens Sandboxes er en avledet tjeneste bygget for å kjøre uklarert eller AI-generert kode oppå samme infrastruktur.
Er sårbarheten fortsatt aktiv?
Nei. Cloudflare fjernet konfigurasjonen som tillot problemet samme dag som feilen ble rapportert, og fullførte opprydding av alt gammelt hurtigbufferdata i containerflåten innen 19. september 2026.
Fikk sårbarheten et eget CVE-nummer?
Nei, ikke ifølge tilgjengelig informasjon per nå. Hendelsen er dokumentert gjennom Cloudflares eget blogginnlegg og bug bounty-prosess, ikke gjennom en offentlig CVE-oppføring.
Kan norske bedrifter sjekke om de ble rammet?
Cloudflare oppgir at ingen kundetiltak er nødvendig og at gjennomgang av telemetri ikke har vist tegn til misbruk utover forskernes egen testing. Selskaper som ønsker en egen vurdering bør likevel kontakte Cloudflare direkte og be om dokumentasjon for eget bruksmønster.
Hvem oppdaget sårbarheten?
Sikkerhetsforsker Oren Yomtov ved selskapet Accomplish rapporterte funnet gjennom Cloudflares bug bounty-program 4. september 2026, og mottok en belønning 14. september etter at rettelsen var bekreftet.
Er dette det samme som et container-escape?
Nei. Et klassisk container-escape, som CVE-2019-5736 eller CVE-2024-21626, gir en angriper tilgang utenfor container- eller VM-grensen mens arbeidslasten fortsatt kjører. I Cloudflare-saken forble selve VM- og containergrensen intakt, og lekkasjen skjedde gjennom gjenbruk av lagringsblokker mellom avsluttede arbeidslaster.
Må Cloudflare-kunder gjøre noe selv?
Nei. Cloudflare har uttalt at rettelsen er rullet ut i hele flåten og at ingen konfigurasjonsendring kreves fra kundens side.
Hvordan skiller dette seg fra tidligere runc-sårbarheter?
Tidligere runc-svakheter har handlet om selve container-kjøretiden og muligheten til å bryte ut til vertsmaskinen. Cloudflare-saken handler i stedet om et lagringslag under en ellers intakt Firecracker-mikro-VM, der en driftsinnstilling for ytelse fikk utilsiktede sikkerhetskonsekvenser.
