Docker, 15 Eylül'de yayımladığı güvenlik duyurusunda, macOS'ta Docker Sandboxes sanal makinesi içinde çalışan kötü amaçlı kodun, kendisine paylaşılan proje dizininden dışarı çıkarak ana bilgisayardaki başka dosyaları okuyabileceğini ve değiştirebileceğini açıkladı.
Bu kaçış, sanal makineyi çalıştıran ana bilgisayar hesabının yetkileriyle gerçekleşiyor. CVE-2026-77179 kodlu açık Kritik seviyede derecelendirildi; macOS'ta 0.28.0 ile 0.42.0 arasındaki sürümleri etkiliyor ve 7 Eylül'de yayımlanan 0.42.0 sürümüyle kapatıldı.
Docker Sandboxes, her yapay zeka kodlama aracısını kendi küçük sanal makinesinde çalıştırıyor ve proje dizinini bu makineyle paylaşıyor. Dışarı sızabilen kod, sanal makinenin içinde çalışan her şey olabiliyor: kullanıcısına karşı döndürülmüş bir kodlama aracısı ya da aracının kurup çalıştırdığı herhangi bir kötü amaçlı yazılım.
Docker, açığın istismar edildiğine dair bir bulgu bildirmedi. CISA'nın CVE kaydına eklediği değerlendirmede de istismar "yok" olarak gösteriliyor; açık, 16 Eylül'de yayımlanan katalog sürümü itibarıyla CISA'nın Bilinen İstismar Edilen Zafiyetler (KEV) listesinde de yer almıyor.
Açığın işlemesi için sanal alanın içinde kötü amaçlı kod bulunması gerekiyor; zaten sanal alanın varlık amacı da ana bilgisayarı aracının çalıştırdığı şeylerden korumak. Araç, sanal makine içinde paketler kuruyor ve sudo ile komutlar çalıştırıyor. Docker'ın izolasyon dokümantasyonunda, hipervizör sınırının "izolasyon kontrolünün kendisi olduğu, sanal makine içi yetki ayrımının olmadığı" belirtiliyor.
Kaçış, Mac ile sanal makine arasındaki dosya paylaşımının ana bilgisayar tarafı olan virtio-fs sunucusu üzerinden gerçekleşiyor. Docker'a göre bu sunucu, kayıtlı bir yoldan silinmiş bir dosyayı yeniden açarken sembolik bağlantıları (symlink) takip ediyordu.
Docker'ın açıklamasına göre sanal makine içinde çalışan taraf, bir üst dizini sembolik bağlantıyla değiştirip VMM kullanıcısının — yani sanal makine monitörünün çalıştığı ana bilgisayar hesabının — yetkileriyle dosya okuyup değiştirebiliyor; bu da "ana bilgisayarda kod çalıştırılmasına yol açabiliyor."
Docker'ın dokümantasyonunda Mart ayından bu yana, çalışma alanının — yani paylaşılan proje dizininin — dışına işaret eden sembolik bağlantıların takip edilmediği yazıyordu.
Aynı sürüm, ikinci bir açığı da kapatıyor. CVE-2026-79994 kodlu bu açık, Docker tarafından CVSS 8.7 puanıyla Yüksek seviyede derecelendirildi ve bir sanal alanın yetkili çalışma alanı içindeki Unix soketlerine bağlanmasını sağlayan aktarıcıda (relay) bulunuyor.
Aktarıcı, soket yolunun çalışma alanı içinde olup olmadığını kontrol ediyor, ardından yol adını kullanarak yeniden bağlanıyordu. Kontrol ile bağlantı arasındaki sürede yol üzerindeki bir dizini sembolik bağlantıyla değiştiren bir taraf, ana bilgisayarın çalışma alanı dışındaki herhangi bir AF_UNIX soketine bağlanmasını sağlayabiliyordu. Docker, bunun "o soketin sağladığı verileri veya ana bilgisayar tarafı yetenekleri açığa çıkarabileceğini" belirtti.
Bu açık 0.37.0 ile 0.41.9 arasındaki sürümleri etkiliyor; 0.42.0 etkilenmiyor. Docker ilk açığı yalnızca macOS'a özgü olarak listeliyor ancak bunun için bir platform belirtmiyor; oysa Docker Sandboxes macOS, Windows ve Linux ana bilgisayarlarında çalışıyor. CISA'nın kaydındaki değerlendirmede de istismar "yok" olarak gösteriliyor ve bu açık da KEV kataloğunda yer almıyor.
Etkilenen sürümler ve yüklenmesi gerekenler
virtio-fs ana bilgisayar sunucusu: 0.28.0 ile 0.42.0 arası (0.42.0 hariç) — Kritik, CVSS 9.4
Konuktan ana bilgisayara Unix soket aktarıcısı: 0.37.0 ile 0.42.0 arası (0.42.0 hariç) — Yüksek, CVSS 8.7
0.42.0 veya üzerine güncelleyin. 17 Eylül itibarıyla en güncel sürüm, 15 Eylül'de yayımlanan 0.43.0.
Hemen güncelleyemiyorsanız klon modunu kullanın ve okuma-yazma yetkili ana bilgisayar bağlantıları eklemekten kaçının. Docker, her iki açık için de bu tavsiyeyi veriyor.
Varsayılan olarak sbx run komutu, geçerli dizini okuma ve yazma erişimiyle sanal alana paylaşıyor. Klon modu yalnızca proje bir Git deposu olduğunda çalışıyor ve sanal alan oluşturulurken ayarlanıyor; dolayısıyla mevcut bir sanal alanın silinip --clone parametresiyle yeniden oluşturulması gerekiyor.
Klon modu depoyu değişikliklere karşı koruyor, okunmaya karşı değil. Docker'ın dokümantasyonuna göre depo /run/sandbox/source konumuna salt okunur bağlanıyor; .env gibi takip edilmeyen dosyalar sanal alanın içinden okunabilir kalıyor.
Docker, CVE kayıtlarını ve danışma belgesini, 0.42.0 sürümünün çıkışından sekiz gün sonra, 15 Eylül'de yayımladı.
GitHub'daki ve Docker'ın dokümantasyon sitesindeki 0.42.0 sürüm notlarında, 17 Eylül itibarıyla iki CVE'nin de adı geçmiyor. Rutin düzeltmeler arasında, "sanal alandaki bir işlemin arka plan servisini (daemon) ana bilgisayarda bir D-Bus aktarımı açtırıp ana bilgisayarda rastgele komut çalıştırmasına" ilişkin bir düzeltme listeleniyor. Docker bu düzeltmeyi iki CVE'den hiçbirine bağlamadı.
CVE-2026-79994 kaydında başlangıçta ilk düzeltilen sürüm olarak 0.41.0 gösterilmiş ve var olmayan bir 0.41.0 sürüm sayfasına bağlantı verilmişti. Docker, 15 Eylül'de kaydı yayımladıktan yaklaşık bir saat sonra her ikisini de 0.42.0 olarak düzeltti.
Docker, CVE-2026-77179'u accomplish.ai'dan Oren Yomtov'un, CVE-2026-79994'ü ise ThreatNotify'dan Jurre van Bergen'in bulduğunu belirtiyor.
Nisan ayında Cyera Research Labs, Docker tabanlı bir sanal alanın içindeki, komut enjeksiyonuyla yönlendirilmiş bir kodlama aracısının, ayrı bir Docker Engine açığını ana bilgisayarına karşı kullanmak üzere kandırılabileceğini anlatmıştı.
