Kısa özet: GhostApproval, AI kodlama asistanlarını etkileyen yeni açıklanmış bir saldırı modeli. Kötü niyetli bir depo, sembolik bağlantıyı sıradan bir proje dosyası gibi gösteriyor. Ajan zararsız görünen yolu düzenlemek için izin istiyor; ancak yazma işlemi çalışma alanının dışındaki hassas bir dosyaya ulaşabiliyor. Araçlarınızı güncelleyin, güvenilmeyen depoları izole edin, symlink’leri inceleyin ve onay pencerelerini güvenlik kanıtı olarak görmeyin.

Her şeyi söylemeyen onay penceresi

AI kodlama ajanları yalnızca bir satır kod önermiyor. Depoları okuyor, dosyaları düzenliyor, terminal komutları çalıştırıyor, bağımlılık kuruyor ve bazen sonucu doğrudan dağıtıyor.

Bu nedenle güvenlik sorusu da değişti. Artık yalnızca “Üretilen kod güvenli mi?” diye sormak yeterli değil. “Ajan, kendisine verdiğim projenin dışında işlem yapmaya kandırılabilir mi?” sorusu da aynı derecede önemli.

Wiz, 8 Temmuz 2026’da GhostApproval adını verdiği kategori seviyesindeki zayıflığı kamuoyuna açıkladı. Araştırmada Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity ve Windsurf dahil altı AI kodlama aracı test edildi. Saldırı iki eski fikri—kötü niyetli proje talimatları ve sembolik bağlantıları—modern bir arayüz hatasıyla birleştiriyor: kullanıcı bir yolu görürken işletim sistemi başka bir dosyaya yazıyor. Wiz GhostApproval araştırması

Bu özel konsept kanıtının gerçek saldırılarda kullanıldığına dair kamuya açık bir kanıt yok. Yine de tasarım açığı önemli; çünkü kodlama ajanları giderek geliştirici hesabıyla aynı dosya sistemi yetkilerini kullanıyor.

GhostApproval basitçe nasıl çalışıyor?

Sembolik bağlantı (symlink), başka bir dosyayı işaret eden dosya sistemi nesnesidir. Yapılandırmaları paylaşmak için kullanışlıdır; ancak yazılım, bir işlemin güvenli olup olmadığına karar vermeden önce bağlantının gerçek hedefini çözümlemelidir.

Klonladığınız depoda şu dosyanın bulunduğunu düşünün:

project_settings.json -> ~/.ssh/authorized_keys

Depo içinde project_settings.json normal bir proje yapılandırması gibi görünür. Aslında geliştiricinin makinesine hangi SSH anahtarlarının giriş yapabileceğini belirleyen dosyaya işaret eder.

README, ajandan “kurulumu tamamlamak” için project_settings.json dosyasına bir satır eklemesini ister. Araç yalnızca görünen proje yolunu doğrularsa yazma işlemi çalışma alanı sınırını aşar ve ~/.ssh/authorized_keys dosyasına ulaşır.

Aynı yöntem ~/.zshrc gibi kabuk başlangıç dosyalarını, araç yapılandırmasını veya bulut kimlik bilgilerini hedefleyebilir. Ajanın yönetici yetkisine ihtiyacı yoktur; geliştiricinin mevcut izinlerini devralır.

Saldırı zinciri

Geliştirici güvenilmeyen bir depoyu klonlar veya açar.
Proje dosyalarından biri aslında çalışma alanı dışındaki hassas bir konuma giden symlink’tir.
Depodaki talimatlar AI ajanını görünen yerel dosyayı düzenlemeye ikna eder.
Ajan veya sandbox, çözümlenmiş gerçek hedef yerine ekranda gösterilen yolu kontrol eder.
Kullanıcı zararsız görünen bir onay görür; bazı araçlarda yazma işlemi onaydan önce gerçekleşir.
Hassas hedef geliştiricinin izinleriyle değiştirilir.

Tehlike symlink’in varlığı değil, kullanıcının onayladığını düşündüğü işlemle sistemin gerçekte yaptığı işlem arasındaki farktır.

“Human in the loop” neden başarısız oldu?

Onay pencereleri çoğu zaman ajan tabanlı araçların son güvenlik bariyeri olarak görülüyor. GhostApproval, insan teknik olarak döngünün içinde olsa bile güvenli karar vermek için gerekli bilgiden yoksun kalabileceğini gösteriyor.

Wiz’in testlerinde ajan görünen proje dosyasının hassas bir hedefe yönlendiğini kendi muhakemesinde fark edebiliyor, fakat geliştiriciye gösterilen onay yalnızca zararsız yolu adlandırıyordu. Bazı ürünler ise Accept veya Reject düğmeleri görünmeden önce değişikliği diske yazıyordu; böylece “onay” yalnızca bir geri alma düğmesine dönüşüyordu.

Üç farklı hata ortaya çıkıyor:

Yol karmaşası: Arayüz gerçek hedef yerine symlink yolunu gösteriyor.
Sınır hatası: Sandbox, çalışma alanı dışında çözümlenen yazma işlemine izin veriyor.
Zamanlama hatası: Ürün, kullanıcı yetkilendirmeden önce işlemi yapıyor.

Anlamlı bir onay gerçek hedefi göstermeli, işlemin güven sınırını aştığını açıklamalı ve izin verilene kadar yazmayı engellemelidir.

Hangi araçlar etkilendi?

Araştırma yayımlandığında altı üründeki durum aynı değildi:

Araç	Bildirilen davranış	Açıklama sırasındaki durum
Amazon Q Developer	Anlamlı onaydan önce symlink üzerinden yazabiliyordu	Language Server 1.69.0’da düzeltildi
Cursor	Diff proje yolunu gösterirken backend symlink’i takip ediyordu	Cursor 3.0’da düzeltildi
Google Antigravity	İzin penceresi gerçek hedef yerine bağlantı yolunu gösteriyordu	Düzeltildi
Claude Code	Güven sınırı sınıflandırması tartışmalı; yeni sürümler uyarıyor	En son sürüme güncelleyin
Augment	Symlink üzerinden sessiz okuma ve yazma gösterildi	Yayın sırasında kabul edildi
Windsurf	Dosya değişikliği Accept/Reject öncesi gerçekleşebiliyordu	Yayın sırasında kabul edildi

AWS, sorunu CVE-2026-12958 olarak kaydetti ve CVSS 4.0 puanını 8,5 olarak belirledi. Amazon Q Developer eklentilerinin Language Server 1.69.0 içeren sürümlere yükseltilmesini öneriyor. AWS güvenlik duyurusu

Cursor’ın ilgili CVE-2026-50549 duyurusu kritik olarak derecelendirildi, 3.0 öncesi sürümleri etkiliyor ve yol kanonikleştirmesi başarısız olduğunda çalışma alanı dışına keyfi yazmayı açıklıyor. Cursor güvenlik duyurusu

Ürün durumları hızla değişebileceği için basit kural şudur: bilinmeyen bir depoyu ajanla açmadan önce üreticinin güncel notlarını kontrol edin ve en son kararlı sürümü kullanın.

Geliştiriciler bugün ne yapmalı?

1. Tüm AI kodlama araçlarını güncelleyin

Yalnızca editör kabuğunu güncellemeyin. Eklentiler, language server’lar, CLI ajanları ve yardımcı süreçler ayrı sürümlere sahip olabilir. Güncellemeden sonra IDE’yi yeniden başlatın.

2. Ajanı kuruluma göndermeden önce symlink’leri inceleyin

macOS veya Linux’ta güvenmediğiniz projedeki bağlantıları kontrol edin:

find . -type l -exec ls -la {} \;

Belirli bir dosyanın hedefi için:

readlink project_settings.json

Depo dışını işaret eden bağlantılar; özellikle shell dosyaları, SSH yapılandırması, kimlik bilgileri, editör veya ajan ayarlarını hedefliyorsa araştırılmalıdır.

3. Güvenilmeyen depoları izole ortamda çalıştırın

Container, geçici sanal makine, uzak geliştirme ortamı veya sıkı sandbox, ajanın devralabileceği geliştirici hesabının değerini azaltır. İzolasyon yalnızca terminal komutlarını değil; dosya sistemi yazmalarını, ağ erişimini, kimlik bilgilerini ve ortam değişkenlerini kapsamalıdır.

4. Sırları ajanın erişiminden uzak tutun

Kısa ömürlü ve en az yetkili kimlik bilgileri kullanın. Üretim bulut anahtarları veya geniş SSH yetkileri bulunan ortamda güvenilmeyen proje açmayın. Şüpheli bir oturum bu dosyalara ulaşmış olabilirse kimlik bilgilerini döndürün.

5. Proje talimatlarını güvenilmeyen girdi olarak ele alın

README dosyaları, issue açıklamaları, ajan kuralları, MCP yanıtları, hata mesajları ve gizli yapılandırmalar ajanı yönlendirebilir. “Tüm kurulum talimatlarını izle” gibi geniş görevler vermeden önce bunları gözden geçirin.

6. Hem kodu hem ajan davranışını inceleyin

Statik kod taraması, uygulamaya eklenen açıkları bulmak için gereklidir. Ancak GhostApproval ajan çalışma zamanı katmanında gerçekleşir. Kod taramasını sandbox sınırları, dosya sistemi izleme, komut günlükleri ve hassas işlemler için açık onayla birlikte kullanın.

Araç üreticileri neyi değiştirmeli?

Her okuma ve yazmadan hemen önce gerçek, kanonik yolu çözümleyip doğrulayın.
Kanonikleştirme başarısız olduğunda eski yola dönmek yerine işlemi engelleyin.
İstenen yolu ve gerçek hedefi birlikte gösterin.
Çalışma alanı dışına yazmayı ayrı ve yüksek riskli onay sınıfı yapın.
Önce yazıp sonra izin istemeyin.
Sandbox tehdit modelinde symlink, mount point ve zamanlama yarışlarını test edin.
Kullanıcı niyeti, ajan muhakemesi, onay ve dosya sistemi etkisini bağlayan denetim izi tutun.

OpenAI, Codex için benzer bir çok katmanlı modeli anlatıyor: sandbox sınırları, onay politikaları, sınırlı ağ erişimi, dar kapsamlı kimlik bilgileri, yönetilen kurallar ve ajan farkındalıklı telemetri tek bir pencereye güvenmek yerine birlikte çalışıyor. OpenAI’da Codex’i güvenli çalıştırmak

Büyük ders: ajan, yetkili bir yazılım aktörüdür

GhostApproval; prompt injection, zehirlenmiş depo talimatları, güvensiz MCP araçları ve tedarik zinciri saldırılarıyla aynı aileye giriyor. Ortak hata, AI asistanını dosyalara, komutlara, token’lara ve ağa erişen bir yazılım aktörü yerine akıllı otomatik tamamlama olarak görmek.

Tehdit modeli artık şöyle olmalı:

Depo hem kod hem de talimat kaynağıdır.
Onay yalnızca arayüz gerçek etkiyi gösteriyorsa güvenlidir.
Çalışma alanı sınırı yalnızca işletim sistemi uyguluyorsa gerçektir.
Üretilen diff, ajanın faaliyetinin yalnızca bir parçasıdır.

AI kodlama daha az kullanışlı hale gelmiyor. Kontrol katmanının CI/CD, cloud IAM ve üretim otomasyonu kadar dikkatle incelenmesini gerektirecek kadar güçleniyor.

GhostApproval’ın rahatsız edici dersi basit: “Onayla’ya tıkladım”, “gerçekte olan şeyi onayladım” anlamına gelmez.

Vexlint, geliştiricilerin AI tarafından üretilen uygulama kodunu güvenlik sorunlarına karşı incelemesine yardımcı olur. Sandbox, en az yetkili kimlik bilgileri ve ajan etkinlik izlemesi gibi çalışma zamanı kontrolleri kod taramasının vazgeçilmez tamamlayıcılarıdır.