Yapay zekâ ajanlarını kapatan “kafes” deliniyordu: Docker Sandboxes’taki açık, ajanın tek bir kopyalama komutuyla bilgisayardaki SSH anahtarlarına ulaşmasına izin veriyordu

Yapay zekâ kodlama ajanları artık geliştiricinin yerine kod yazıyor, paket kuruyor ve komut çalıştırıyor. Bu gücü güvenli kılmanın en popüler yollarından biri de ajanı “kafese” koymak: Docker Sandboxes, Claude Code, Codex ve Gemini CLI gibi ajanları bilgisayarın geri kalanından yalıtılmış bir ortamda çalıştırmak için geliştirildi. Güvenlik şirketi Endor Labs’tan araştırmacı Peyton Kennedy’nin 3 Kasım 2026’da yayımladığı bulgular ise bu kafesin önemli bir kapısının açık kaldığını gösterdi.

CVE-2026-103916 koduyla izlenen açık, ajanın izin verilmeyen klasörlerdeki dosyaları okumasına ve geliştiricinin bilgisayarındaki dosyaların üzerine yazmasına imkân tanıyordu. Açık, CVSS 3.1 ölçeğinde 8.2 (yüksek), CVSS 4.0 ölçeğinde 7.3 (yüksek) puan aldı. Kesin düzeltme, 3 Kasım’da yayımlanan 0.51.0 sürümüyle geldi.

Docker Sandboxes nasıl çalışıyor?

Docker Sandboxes’ta her ajan, kendi Linux çekirdeği, Docker hizmeti, dosya sistemi ve ağı olan hafif bir sanal makinede (microVM) çalışıyor. Sıradan bir Docker konteynerinden farkı, ana bilgisayarın çekirdeğini paylaşmaması; bu da daha güçlü bir yalıtım sağlıyor. Araç, Docker Desktop gerektirmeyen bağımsız sbx komut satırı aracı olarak dağıtılıyor.

Ajanın çalışabilmesi için elbette projenin kodlarına erişmesi gerekiyor. Geliştirici bu nedenle yalnızca belirli klasörleri, genellikle proje çalışma alanını, açıkça paylaşıyor. Bu onaylı klasörler bir izin listesi oluşturuyor ve kâğıt üzerinde ajanın bilgisayarda erişebileceği tek alanı belirliyor.

Açık nerede?

Kennedy’nin bulgusuna göre sorun, sandbox ile bilgisayar arasında dosya kopyalamak için kullanılan sbx cp komutunda. Bu komut, paylaşılan dosya sisteminden ayrı bir kanaldan çalışıyor ve izin listesini hiç kontrol etmiyor. Üstelik kendisine verilen yollardaki sembolik bağlantıları (başka bir dosya ya da klasörü gösteren kısayolları) çözüp doğrudan takip ediyor.

Ajan, çalışma alanına yazma iznine sahip olduğu için bu alandaki bir alt klasörü, bilgisayarın herhangi bir yerini gösteren bir kısayolla değiştirebiliyor. Bu kısayol sandbox içinde işe yaramıyor; ancak geliştirici, aracın yardım metninde de örnek olarak gösterilen sıradan bir kopyalama komutunu çalıştırdığında, kısayol bilgisayar tarafında çözülüyor ve işlem izin listesinin dışına taşıyor.

Komuttaki tek sembolik bağlantı koruması olan -L seçeneği, bir bağlantının bulunabileceği dört konumdan yalnızca birini denetliyordu. Araştırmacıya göre diğer üç konum açıktı ve hangi konumun kullanılacağını ajan seçebiliyordu.

İki ayrı risk: okuma ve yazma

• Yazma: Ajanın yerleştirdiği tek bir kısayol ve geliştiricinin çalıştırdığı tek bir “dışarı kopyalama” komutuyla, geliştiricinin yazma yetkisi olan herhangi bir mevcut klasöre sandbox’ın belirlediği içerik yazılabiliyordu. Araştırmacı, .zshrc, ~/.ssh/authorized_keys, git yapılandırması ya da bir projedeki git kancası gibi dosyaların bu yolla değiştirilmesinin, bir sonraki sıradan işlemde kod çalıştırmaya dönüşebileceğini belirtiyor; ancak bu son adımı göstermediğini, bunu bir sonuç olarak değil akıl yürütme olarak sunduğunu da not ediyor.
• Okuma: Kısayol bir üst klasöre yerleştirildiğinde, geliştiricinin içeri kopyaladığı dosya aslında bilgisayardaki başka bir dosya olabiliyordu. Bulut kimlik bilgileri dosyası ya da SSH özel anahtarı gibi adı tahmin edilebilir dosyalar bu yolla sandbox’a çekilebiliyordu.

Durumu daha da sinsi kılan ayrıntı, başarılı bir dışarı kopyalamanın ekrana hiçbir şey yazdırmaması. Dosyanın beklenmedik bir yere gittiğini fark etmek için geliştiricinin elinde bir ipucu bulunmuyor. Üstelik ajanlı çalışma akışlarında bu kopyalama komutunu çoğu zaman ajanın kendisi öneriyor.

İstem enjeksiyonu ile tetiklenebilir

Bu açığın kötüye kullanılması için ajanın “kötü niyetli” olması gerekmiyor. Endor Labs’e göre bir saldırgan, ajanın işlediği bir web sayfası, bağımlılık ya da belge içine gizlenen talimatlarla, yani istem enjeksiyonu (prompt injection) yoluyla, ajanı bu kısayolu yerleştirmeye yönlendirebilir. Bu da yapay zekâ ajanlarının en temel güvenlik sorunlarından birinin, yalıtım katmanındaki küçük bir boşlukla birleştiğinde nasıl ciddi bir riske dönüşebileceğini gösteriyor.

Düzeltme neden gecikti?

Docker’ın düzeltmeyi ilk olarak 13 Ekim 2026’da 0.48.0 sürümüyle yayımlaması planlanmıştı. Ancak yama yayına girdikten sonra Docker ekibi düzeltmenin eksik olduğunu belirledi. Kesin çözüm, 3 Kasım’da yayımlanan 0.51.0 sürümüyle geldi. Bu, sbx cp komutunda bulunan ilk açık da değil: Daha önce, arşiv içindeki yollar üzerinden hedef klasörden kaçışa izin veren CVE-2026-17106 açığı 0.38.0 sürümüyle kapatılmıştı.

Geliştiriciler ne yapmalı?

1. Docker Sandboxes (sbx) aracını hemen 0.51.0 veya üzeri bir sürüme güncelleyin.
2. Güncellemeye kadar sbx cp komutunu, güvenmediğiniz birinin yazdığı bir komut gibi değerlendirin; kopyalamadan önce hedef ve kaynak yolun gerçekte nereye çıktığını realpath ile kontrol edin. Yalnızca son bileşeni kontrol etmek yetmiyor; kısayol yolun herhangi bir parçasında olabilir.
3. Mümkünse sandbox’a hiç bağlanmamış klasörlere ve bu klasörlerden kopyalama yapın.
4. Özellikle ajanın kendisinin önerdiği kopyalama komutlarına karşı daha temkinli olun.

Sandbox’lar neden zor?

Araştırmacı, 2026’da bir yapay zekâ ajanı sandbox’ında aynı türden bir hatayı ikinci kez bulduğunu belirtiyor. Her iki vakada da yalıtım katmanının kendisi düzgün çalışıyordu; sorun, güvenlik modelinin hesaba katmadığı ikinci bir dosya kanalındaydı. Kennedy’nin vardığı sonuç açık: Geliştirici adına dosya taşıyan kanallar, geliştiricinin kendi işlemi gibi göründüğü için güvenlik modelinin dışında kalmaya en yatkın kanallar. Yol ajanın kontrolündeyse, geliştiricinin kopyası ajanın seçtiği yere yazılıyor.

Kaynak: Endor Labs güvenlik araştırması, Docker Sandboxes sürüm bilgileri