Docker Sandboxes’ta kritik açık: AI agent’ın VM’indeki kod macOS host dosyalarına ulaşabiliyor

Docker, Docker Sandboxes‘ta macOS’u etkileyen kritik bir açığı duyurdu. Sandbox’ın sanal makinesinde çalışan zararlı kod, içeriye paylaşılan proje klasörünün dışına çıkıp host’taki herhangi bir dosyayı okuyabiliyor veya değiştirebiliyor. Bu erişim, sanal makineyi çalıştıran host hesabının yetkileriyle gerçekleşiyor.

Açık CVE-2026-77179 koduyla takip ediliyor ve Critical olarak derecelendirildi. 0.28.0 ile 0.42.0 öncesi macOS sürümlerini etkiliyor; düzeltme 7 Eylül’de çıkan 0.42.0 ile geldi. Aynı sürüm, High dereceli ikinci bir açığı da kapatıyor. Docker güvenlik duyurusunu 15 Eylül’de yayınladı.

Docker Sandboxes nedir, neden önemli?

Docker Sandboxes, her AI coding agent’ı kendi küçük sanal makinesinde çalıştırıyor ve proje klasörünü bu makinenin içine paylaşıyor. Amaç basit: agent’ın çalıştırdığı şeylerden host’u korumak.

Buradaki tehdit modeli önemli. Kaçış yapabilecek kod, sanal makinenin içinde çalışan herhangi bir şey: kullanıcısına karşı çevrilmiş bir coding agent ya da agent’ın kurup çalıştırdığı zararlı bir paket. Agent sanal makinenin içinde paket kuruyor ve sudo ile komut çalıştırıyor.

Docker’ın izolasyon dokümantasyonu bunu açıkça söylüyor: izolasyon kontrolü sanal makine içindeki yetki ayrımı değil, hypervisor sınırı. Yani sandbox’ın içinde root olmak zaten beklenen bir durum; güvenlik tamamen sınırın tutmasına dayanıyor. Bu açık tam olarak o sınırı deliyor.

Açığın istismarı için sandbox’ın içinde zararlı kod çalışıyor olması gerekiyor. Ama sandbox’ın varlık sebebi zaten güvenilmeyen kodu çalıştırmak. Dolayısıyla bu ön koşul, riski azaltan bir faktör sayılmamalı.

CVE-2026-77179: virtio-fs üzerinden kaçış

Kaçış, virtio-fs host server üzerinden gerçekleşiyor. Bu bileşen, Mac ile sanal makine arasındaki dosya paylaşımının host tarafı. Docker’a göre server, silinmiş bir dosyayı saklanan yoldan yeniden açarken symlink’leri takip ediyordu.

Guest, yani sanal makinenin içinde çalışan kod, bir üst dizini symlink ile değiştirip dosyaları VMM kullanıcısı olarak okuyabiliyor veya değiştirebiliyordu. VMM kullanıcısı, sanal makine monitörünün çalıştığı host hesabı. Docker’ın ifadesiyle bu durum “potansiyel olarak host üzerinde kod çalıştırmaya yol açabiliyor”.

Dikkat çeken bir çelişki var: Docker’ın dokümantasyonu Mart’tan beri, workspace dışını gösteren symlink’lerin takip edilmediğini söylüyor. Workspace, Docker’ın paylaşılan proje klasörü için kullandığı terim. Yani dokümante edilen davranış ile gerçek davranış arasında bir fark vardı.

Kullanıcı hesabıyla dosya yazabilmek pratikte çok şey demek. ~/.zshrc, ~/.ssh/, LaunchAgents dizini veya credential içeren konfigürasyon dosyaları, hepsi o hesabın erişiminde.

CVE-2026-79994: Unix socket relay’inde TOCTOU

Aynı sürüm ikinci bir açığı da kapatıyor: CVE-2026-79994, Docker tarafından High olarak derecelendirildi, CVSS 8.7. Açık, sandbox’ın yetkili workspace’i içindeki Unix domain socket’lerine bağlanmasını sağlayan relay bileşeninde.

Relay önce socket yolunun workspace içinde olup olmadığını kontrol ediyor, sonra yol adını kullanarak yeniden bağlanıyordu. Kontrol ile bağlantı arasındaki aralıkta yol üzerindeki bir dizini symlink ile değiştiren bir guest, host’un workspace dışındaki herhangi bir AF_UNIX socket’ine bağlanmasını sağlayabiliyordu. Docker’a göre bu, “o socket’in sağladığı verileri veya host tarafı yetenekleri açığa çıkarıyor”.

Bu klasik bir time-of-check to time-of-use (TOCTOU) hatası. Host’ta Docker daemon socket’i veya SSH agent socket’i gibi yüksek yetkili socket’ler çalışıyorsa etkisi ciddi olabilir.

Açık 0.37.0 ile 0.41.9 arası sürümleri etkiliyor. Docker ilk açığı yalnızca macOS’a özgü olarak listelerken, bunun için bir platform belirtmiyor. Docker Sandboxes ise macOS, Windows ve Linux host’larında çalışıyor. Yani bu açığın yalnızca Mac’lerle sınırlı olduğunu varsaymamak gerekiyor.

Etkilenen sürümler

İstismar durumu

Docker herhangi bir istismar bildirmedi. CISA’nın her iki CVE kaydına eklediği değerlendirme istismarı “none” olarak listeliyor. İki açık da 16 Eylül tarihli sürüm itibarıyla CISA’nın Known Exploited Vulnerabilities (KEV) kataloğunda değil.

Ne yapmalı?

1. 0.42.0 veya sonrasına güncelleyin. 17 Eylül itibarıyla en güncel sürüm 15 Eylül’de yayınlanan 0.43.0.
2. Hemen güncelleyemiyorsanız clone mode kullanın ve read-write host mount eklemekten kaçının. Docker bunu her iki açık için de öneriyor.

Clone mode’un sınırlarını bilmek önemli:

• Varsayılan olarak sbx run mevcut dizini sandbox’a okuma ve yazma erişimiyle paylaşıyor
• Clone mode yalnızca proje bir Git deposuysa çalışıyor
• Clone mode sandbox oluşturulurken ayarlanıyor; mevcut bir sandbox silinip --clone ile yeniden oluşturulmalı
• Clone mode depoyu değişikliğe karşı koruyor, okumaya karşı değil. Depo /run/sandbox/source altına salt okunur bağlanıyor, .env gibi takip edilmeyen dosyalar sandbox içinden okunabilir kalıyor

# mevcut sandbox'ı silip clone mode ile yeniden oluşturun
sbx run --clone

Son madde özellikle kritik. Clone mode bir geçici önlem, ama .env dosyanızdaki credential’ları sandbox içindeki koddan saklamıyor. Agent’lar ve credential ilişkisini daha önce ele almıştık: AI agent’ın davranışını değil, erişebildiği şeyleri kontrol edin.

Duyuru sürecindeki boşluklar

Açıkların kendisi kadar duyurulma biçimi de dikkat çekiyor:

• Docker CVE kayıtlarını ve güvenlik duyurusunu 15 Eylül’de, yani 0.42.0 çıktıktan sekiz gün sonra yayınladı
• 0.42.0 sürüm notları, hem GitHub’da hem Docker dokümantasyon sitesinde, 17 Eylül itibarıyla iki CVE’den de bahsetmiyor
• Aynı sürüm notlarında rutin düzeltmeler arasında şu madde geçiyor: “sandbox içindeki bir süreç, daemon’a host D-Bus transport’unu açtırıp host üzerinde keyfi komut çalıştırabiliyordu”. Docker bu düzeltmeyi iki CVE’den biriyle ilişkilendirmedi
• CVE-2026-79994 kaydı ilk yayınlandığında düzeltilmiş sürüm olarak 0.41.0’ı gösteriyor ve var olmayan bir 0.41.0 sürüm sayfasına link veriyordu. Docker, kaydı yayınladıktan yaklaşık bir saat sonra ikisini de 0.42.0 olarak düzeltti

D-Bus maddesi ayrıca incelenmeye değer. Sandbox içinden host’ta keyfi komut çalıştırma, tanım olarak bir sandbox kaçışı. Buna ayrı bir CVE atanıp atanmayacağı belli değil.

Sessiz yama pratiği, güncellemeyi “rutin” sayıp erteleyen kullanıcıları sekiz gün boyunca bilgisiz bıraktı. Sürüm notlarını okuyarak güvenlik önceliği belirleyen ekipler için bu önemli bir uyarı.

Keşfedenler

Docker, CVE-2026-77179’u bulan accomplish.ai’dan Oren Yomtov’a ve CVE-2026-79994’ü bulan ThreatNotify’dan Jurre van Bergen’e teşekkür ediyor.

Bu açık, AI agent güvenliğinin son aylardaki ana temasının bir örneği daha. Agent’lara geniş yetki verip riski izolasyonla dengeleme yaklaşımı, izolasyonun kendisi kadar güvenli. Sandbox’ın içinde root olmak normal kabul edildiğinde, hypervisor sınırındaki tek bir symlink hatası tüm modeli çökertiyor.

Benzer bir desen daha önce Claude Cowork’te de görülmüştü: SharedRoot zafiyeti, tek mesajla AI agent’ın VM’den kaçıp Mac dosyalarına erişmesine izin veriyordu. VM escape sınıfı açıkların masaüstü sanallaştırmadaki bir başka örneği de VMware Workstation ve Fusion’daki CVE-2026-59346 idi. Ortak nokta aynı: dosya paylaşımı ve cihaz emülasyonu gibi guest ile host arasında köprü kuran bileşenler, bu sınırın en zayıf halkası.

Pratik öneri net. Docker Sandboxes kullanıyorsanız sürümünüzü kontrol edin ve 0.43.0’a geçin. Agent’larla çalışırken sandbox’ı tek savunma hattı olarak görmeyin: host’ta, sandbox’a paylaşılan klasörde ve .env dosyalarında production credential tutmamak, izolasyon delindiğinde zararı sınırlayan asıl önlem.

Kaynak: https://thehackernews.com/2026/09/critical-docker-sandboxes-flaw-lets.html