Docker Sandboxes există ca să ruleze agenți de cod AI undeva unde nu pot strica mașina. Fiecare agent primește propria mașină virtuală mică, cu directorul proiectului partajat înăuntru, iar în acea mașină agentul instalează pachete și rulează comenzi cu sudo, pentru că exact ăsta e scopul.
Documentația Docker despre izolare e explicită în privința a ce înseamnă asta: granița hipervizorului „e controlul de izolare, nu separarea de privilegii din interiorul mașinii virtuale".
Nu există al doilea strat. Două vulnerabilități dezvăluite pe 15 septembrie au trecut de singurul care există.
Cele două vulnerabilități
CVE-2026-77179 — CVSS 9.4, critică, macOS. Serverul gazdă virtio-fs, care se ocupă de partajarea fișierelor între Mac și mașina virtuală, urma legături simbolice atunci când redeschidea un fișier șters, pornind de la o cale memorată.
Un oaspete malițios putea înlocui un director părinte cu un symlink după ce calea fusese consemnată, putea ieși din spațiul de lucru partajat și putea citi sau modifica orice fișier de pe gazdă, cu drepturile utilizatorului sub care rulează monitorul de mașină virtuală. Formularea Docker e că asta duce potențial la execuție de cod pe gazdă.
CVE-2026-79994 — CVSS 8.7, ridicată. O problemă de tip time-of-check to time-of-use în releul care permite unui sandbox să ajungă la socketuri de domeniu Unix din spațiul său de lucru autorizat.
Releul verifica dacă o cale de socket e în interiorul spațiului de lucru, apoi se reconecta folosind numele căii, nu o referință de fișier păstrată. Un oaspete care schimba un director intermediar cu un symlink, între verificare și conectare, putea face gazda să se conecteze la orice socket AF_UNIX din afara spațiului de lucru — expunând datele sau capabilitățile pe care le oferă acel socket.
CVE-2026-77179 server gazda virtio-fs 0.28.0 → sub 0.42.0 macOS CVE-2026-79994 socket oaspete-gazda 0.37.0 → sub 0.42.0 platforma neprecizata Remediate in 0.42.0, lansata pe 7 septembrie Versiune curenta 0.43.0
Nu există exploatare cunoscută. Niciuna dintre vulnerabilități nu e în catalogul CISA de breșe exploatate activ, iar EPSS estimează probabilitatea de exploatare în 30 de zile la mult sub un procent.
Cine e atacatorul, de fapt
Asta face povestea să merite mai mult decât o actualizare de versiune.
Modelul de amenințare de aici nu e un intrus din rețeaua ta. E codul care rulează în sandbox — adică agentul de cod pe care l-ai pornit deliberat sau orice instalează și rulează el.
Un agent poate fi întors împotriva utilizatorului prin injecție de prompt într-un fișier din repository, într-un comentariu la un issue, într-o pagină web pe care o deschide sau printr-un server MCP compromis. Sau poate pur și simplu instala o dependență malițioasă în timp ce face ce i-ai cerut. În aprilie, Cyera Research Labs a demonstrat cum un agent de cod cu prompt injectat, aflat într-un sandbox bazat pe Docker, putea fi păcălit să exploateze o altă vulnerabilitate Docker Engine împotriva gazdei.
Sandbox-ul e controlul care face acceptabilă rularea agenților. Eliminarea lui nu slăbește poziția de securitate — o desființează.
Măsura temporară are o precizare de citit de două ori
Dacă nu poți actualiza, recomandarea Docker pentru ambele vulnerabilități e să folosești modul clone și să eviți montările de gazdă cu drept de scriere. Implicit, sbx run partajează directorul curent cu drepturi de citire și scriere.
Modul clone funcționează doar când proiectul e un repository Git și se stabilește la crearea sandbox-ului — un sandbox existent trebuie șters și recreat cu --clone.
Mai important:
Modul clone protejează repository-ul de modificări, nu de citire. Repository-ul e montat doar pentru citire, iar fișierele neurmărite, precum
.env, rămân lizibile în interiorul sandbox-ului.
Am scris săptămâna trecută despre o campanie care recolta exact fișiere .env, credențiale AWS și stare Terraform de pe servere de dezvoltare expuse. Dacă un agent dintr-un sandbox în mod clone e compromis, acele fișiere îi sunt în continuare accesibile. Modul clone reduce raza de acțiune a unei scrieri. Nu face nimic pentru un secret.
Actualizează. Măsura temporară e o soluție de câteva ore, nu o poziție.
Intervalul, a șaptea oară
Docker a remediat ambele vulnerabilități în 0.42.0, pe 7 septembrie. A publicat avertizarea și fișele CVE pe 15 septembrie.
Notele de versiune pentru 0.42.0 nu menționează niciunul dintre CVE-uri. Printre intrările de rutină, listează o remediere pentru un proces din sandbox care putea face daemonul să deschidă un transport D-Bus pe gazdă și să execute o comandă arbitrară acolo — pe care Docker nu a legat-o de niciuna dintre fișe.
Deci cine a citit changelogul pe 7 septembrie nu avea cum să știe că e o actualizare urgentă de securitate. Cine l-a citit pe 15 a avut de evaluat opt zile de expunere retroactivă.
E acum al șaptelea incident dintr-o lună în care remedierea și dezvăluirea au fost separate de un interval semnificativ — după MikroTik, Plex, Chromium, PaperCut, StyleSmuggler și GitLab. Numărul de versiune e prima dezvăluire; avertizarea e a doua.
Două note mai mici, în aceeași direcție. Documentația Docker afirma din martie că legăturile simbolice care ies din spațiul de lucru nu sunt urmate — exact proprietatea de securitate care s-a dovedit că nu ține. Iar fișa CVE a celei de-a doua vulnerabilități a listat inițial o versiune de remediere care nu există, corectată după circa o oră.
Nimic din toate astea nu e neobișnuit. Tot ce e aici e motivul pentru care un număr de versiune dintr-un changelog nu e un semnal de securitate.
Ce ai de făcut
- Actualizează Docker Sandboxes la 0.42.0 sau mai nou. Versiunea curentă e 0.43.0.
- Verifică fiecare mașină pe care rulează agenți de cod, nu doar serverele. E software de laptop de dezvoltator. Nu apare într-un raport de patchuire de servere, iar pe macOS mașina personală e cea care ține cheile SSH, credențialele de cloud și materialul de semnare.
- Dacă nu poți actualiza azi, folosește modul clone și renunță la montările cu drept de scriere — înțelegând că secretele din arborele de lucru rămân lizibile.
- Stabilește la ce poate ajunge un agent compromis. Sandbox-ul limitează ce poate atinge pe gazdă. Nu limitează ce poate face cu credențialele aflate în sandbox împreună cu el sau cu accesul la rețea pe care i l-ai dat.
- Tratează sandbox-urile de agenți ca pe o clasă de produs care se patchuiește. Orice rulează cod nesigur prin proiectare are nevoie de aceeași disciplină de actualizare ca un browser, iar acum primește disciplina unui utilitar de dezvoltator.
4Tify analizează expunerea stațiilor de dezvoltare, inclusiv uneltele care rulează cod nesigur prin proiectare și credențialele aflate lângă ele. Dacă vrei o evaluare, scrie-ne.