Cloudflare a închis o vulnerabilitate în serviciile Containers și Sandboxes care permitea unui client cu plan Workers Paid să recupereze date reziduale din containerele altor clienți găzduite pe același host fizic. Din 4 septembrie, când a fost raportată prin HackerOne de Oren Yomtov, cercetător la Accomplish, până pe 19 septembrie 2026, când Cloudflare a încheiat toate măsurile de remediere, problema a trecut prin analiză, confirmare și corectare pe infrastructură. Compania spune că nu există dovezi că date reale de client au fost expuse prin această metodă, iar clienții nu trebuie să facă nimic.

Diferența dintre o breșă teoretică și una exploatată în producție este exact ce separă panica de decizia tehnică. Aici avem o vulnerabilitate confirmată, cu impact potențial real, dar fără dovadă de exploatare efectivă. Asta nu o face mai puțin importantă. O face mai interesantă pentru cine vrea să înțeleagă cum arată izolarea reală între chiriași într-un cloud modern.

Ce s-a întâmplat, pe scurt

Cloudflare Containers rulează aplicații containerizate pe infrastructura companiei, alături de Cloudflare Workers, folosite frecvent pentru servicii backend, procesare de joburi și medii de execuție de cod. Problema era într-un pool de stocare partajat configurat să sară peste operațiunea de ștergere (zeroing) a blocurilor reutilizate de 64 KiB. Când volumul subțire din spatele discului rădăcină al unui container era șters, blocurile fizice reveneau într-un pool comun mai multor conturi de client.

Mecanismul exploatării e elegant în simplitate. Scriind doar 4 KiB într-o zonă nefolosită a discului unui container nou, se forța alocarea unui bloc fizic reutilizat de 64 KiB. Fără operațiunea de ștergere, doar cei 4 KiB scriși suprascriau blocul, lăsând restul de 60 KiB într-o stare citibilă, cu date posibile din containerul unui client anterior. Cercetătorii au găsit material rezidual pe 18 din 24 de plasări de containere și pe 20 din 22 de noduri testate, inclusiv structuri de directoare, pagini de baze de date și baze SQLite complete structural.

Cloudflare a explicat că un atacator nu ar fi avut control asupra victimei sau host-ului și nu ar fi putut citi un disc activ atașat. Impactul potențial ar fi fost dezvăluirea de metadate de sistem de fișiere, structuri de directoare, pagini de baze de date și date de aplicație. Cercetătorii au folosit doar scripturi care verificau și returnau numărători agregate, nu conținut real de disc, deci nu au expus date reale de client în evaluarea lor. Nu au demonstrat nici o metodă de a modifica datele altui client sau de a-i perturba activitatea.

Remedierea: Cloudflare a eliminat setarea care cauza sărirea ștergerii blocurilor, a retras discurile de container existente și a curățat snapshot-urile cache care puteau conține mapări vechi. Toate acțiunile s-au încheiat pe 19 septembrie 2026. După examinarea log-urilor, telemetriei și datelor istorice, compania nu a găsit dovezi că date de client au fost expuse prin metoda descrisă de Accomplish. Corecțiile s-au aplicat automat pe infrastructură.

Sursa: BleepingComputer

De ce contează izolarea între chiriași

Când cumperi un serviciu cloud, nu cumperi doar CPU și bandă. Cumperi o promisiune: că datele tale nu ajung niciodată la alt client care plătește pe aceeași factură. Această promisiune se numește izolare multi-tenant și este una dintre cele mai greu de verificat din exterior. Nu o vezi în panoul de control. Nu o simți în performanță. O observi doar când cineva o sparge, sau când un cercetător ca Yomtov o testează metodic.

Ce face cazul interesant este tipul de defect. Nu a fost o eroare de logică în codul aplicațiilor clienților, nici o configurare greșită de firewall. A fost o optimizare de performanță în stratul de stocare: să sari peste ștergerea blocurilor pentru a economisi operațiuni de scriere. Optimizarea era corectă în izolare. Devenea periculoasă în momentul în care blocul respectiv era reasignat altui chiriaș. Exact acolo intervine decizia de arhitectură.

Aici e lecția pe care orice echipă tehnică ar trebui să o scrie pe perete: orice optimizare care presupune că un resursă partajată nu va fi văzută de altcineva trebuie tratată drept potențial periculos. Nu e o problemă de răutate, ci de model mental. Ingineul care a scris setarea de skip zeroing probabil nu avea în cap scenariul reasignării către alt cont.

Ce nu știm încă

Sursa nu precizează câte conturi sau câți clienți au fost afectați potențial. Nu știm dacă problema exista doar în anumite regiuni sau pe toată infrastructura globală. Nu știm dacă setarea de skip zeroing era prezentă de la lansarea serviciului sau a fost introdusă ulterior, ceea ce ar schimba dramaturg diferit fereastra de expunere. Nu avem o listă publică de noduri afectate și nici o declarație despre cât timp a funcționat pool-ul în această configurație.

Toate acestea sunt întrebări de verificat pentru oricine vrea să judece severitatea reală, nu doar să reacționeze la titlu. Cloudflare a spus clar că nu are dovezi de exploatare. Cercetătorii au spus clar că nu au extras conținut real. Aceasta este o constatare măsurată, nu o ipoteză. Confuzia apare când cineva transformă „nu am dovezi de exploatare" în „nu s-a exploatat sigur". A doua afirmație cere o probă care nu există în material.

Ce înseamnă pentru tine

Dacă ești antreprenor sau marketer în România și folosești Cloudflare Workers, Containers sau orice serviciu serverless care rulează cod, vestea e liniștitoare pe termen scurt. Corecția e automată, nu ai nimic de făcut. Dar nu te opri la „nu trebuie să fac nimic" și să închizi tab-ul. Gândește-te ce date pui în medii de execuție partajate.

Fișierele .env, credențialele bazei de date, cheile de API, profilele de browser folosite de automatizări, tot ce ajunge pe disc într-un container este material care ar putea supraviețui ștergerii unui bloc fizic dacă izolarea cade. Asta nu schimbă ce faci azi. Schimbă ce arhivezi. Regula simplă: dacă un secret nu trebuie să supraviețuiască unui container șters, nu îl scrie pe disc, ține-l în variabile de mediu injectate la runtime sau în servicii de secret management.

Pentru echipele care rulează procesare de joburi și medii de execuție de cod, merită o întrebare de arhitectură: ce date sensibile trec prin discul efemer al unui container și cât timp trăiesc ele acolo? Nu e o paranoia legată de Cloudflare. E o igienă care se aplică oricărui furnizor. Ai un checklist de securitate pentru serviciile serverless adoptate? Dacă nu, acum e momentul să îl scrii, pentru că auditoriile viitoare de conformitate vor cere exact această dovadă.

Pe partea de SEO și date, un astfel de incident nu îți afectează direct traficul, dar afectează încrederea în furnizor. Dacă lucrezi cu un stack care depinde de Workers pentru randare sau proxy, verifică dacă ai un fallback configurat. Nu pentru Cloudflare neapărat, pentru orice furnizor care poate intra în mentenanță de urgență. Un plan B de infrastructură este mai ieftin decât o zi de downtime.

Ce ar trebui să facă o echipă serioasă, ca recomandare

Acestea sunt recomandările noastre, nu fapte din sursă. Inventariază unde rulezi cod în medii partajate, fie că e Cloudflare, AWS Lambda, Cloud Run sau Vercel. Pentru fiecare, notează ce date persistă pe disc între invocări sau între containere. Clasifică-le în publice, interne și sensibile. Pentru cele sensibile, mută stocarea în afara discului efemer.

Apoi scrie un test de izolare. Nu trebuie să fie sofisticat. Un script care scrie un pattern unic pe disc într-o invocare și verifică dacă acel pattern apare în invocarea următoare pe un container nou este suficient ca să prinzi regresii evidente. Nu garantează că prinzi tot, dar îți dă un semnal timpuriu. Rulează-l periodic. Dacă furnizorul tău îl pică, ai dovezi pentru un tichet serios.

În final, abonează-te la canalele de securitate ale furnizorilor de infrastructură pe care îi folosești. Mulți antreprenori români descoperă un incident abia când apare în presă. Nu e o strategie. Un feed RSS, un webhook de status, un canal de incident response, orice te anunță mai repede decât un articol.

FAQ

A fost expusă date reale de clienți? Cloudflare spune că nu are dovezi de expunere prin această metodă. Cercetătorii au folosit doar scripturi de verificare care returnau numărători agregate, nu conținut real de disc. Constatarea este măsurată, nu o ipoteză de viitor.

Trebuie să fac ceva ca client Cloudflare? Nu. Cloudflare a spus explicit că remedierea s-a aplicat automat pe infrastructură și că nu este necesară nicio acțiune din partea clienților. Acțiunile s-au încheiat pe 19 septembrie 2026.

Poate atacatorul să modifice sau să blocheze datele mele? Cercetătorii nu au demonstrat nicio metodă de a modifica datele altui client sau de a-i perturba activitatea. Un atacator nu ar fi avut control asupra victimei sau a host-ului și nu ar fi putut citi un disc activ atașat.

Concluzia ALLSoft

Un astfel de incident este exact tipul de subiect unde AI-ul ajută la analiză, la structurarea timeline-ului, la transformarea unui advisory tehnic într-un checklist aplicabil pentru echipă, dar decizia și execuția rămân umane. Un media buyer sau un CTO nu poate delega unui model judecata despre ce date ajung pe un disc partajat. AI-ul analizează, omul decide, iar pasul concret de verificare și configurare îl face echipa potrivită.

Dacă vrei să treci de la reacție la proces, discută cu ALLSoft Agency despre un audit de infrastructură pentru stack-ul tău. Fără hype, fără promisiuni de invulnerabilitate, doar întrebările care contează puse la momentul potrivit.