Yapılandırma enjeksiyonu açıkları, kötü niyetli depoların AI kodlama ajanları üzerinden komut çalıştırmasına izin veriyor

Ajanlarda yeni bir güvenlik açığı sınıfı

Manifold Security'den gelen, Eylül 2026'da raporlanan ve bir dev.to analizinde ele alınan güvenlik araştırması, depo kontrolündeki yapılandırma dosyalarının ajanın hangi komutları çalıştıracağını kontrol edebilmesiyle sonuçlanan bir güvenlik açığı sınıfını belgeliyor. Adı geçen etkilenen araçlar arasında Claude Code, Codex, Goose, Qwen Code ve Grok Build yer alıyor; sorunlar CVE-2026-19592 dahil kimliklerle takip ediliyor ve CVSS 7,0 ila 7,3 aralığında derecelendiriliyor.

Yazıda çerçevelendiği şekliyle temel sorun, yanlış yere çizilmiş bir güven zinciri: geliştirici ajana güvenir, ajan depoda bulduğu her yapılandırmaya güvenir ve depo bir saldırganın kontrolünde olabilir. Bu yol boyunca hiçbir şey, depo içeriğinin üzerine hareket edilmesi açısından güvenli olduğu varsayımını doğrulamıyor.

Enjeksiyon nasıl çalışıyor

Modern kodlama ajanlarına depo okuma, komut çalıştırma ve dosya değiştirme yetenekleri veriliyor. Etkilenen uygulamalarda, bir depoyu açan ajan aynı zamanda yapılandırma dosyalarını da okuyor ve bu dosyalardaki değerler ajanın alt süreçleri nasıl çağıracağını etkileyebiliyor. Bir yapılandırma değeri komut, shell parçası ya da çalıştırılabilir dosya yolu belirleyebildiği için, yapılandırma dosyası fiilen bir çalıştırma aracına dönüşüyor.

Teslim yolları tanıdık: özenle hazırlanmış bir depo, bir pull request üzerinden sunulan depo ya da klonlanmış bir bağımlılık. Her durumda geliştiricinin kötü niyetli dosyayı kendisinin açması gerekmiyor. Ajan dosyayı önce okuyor ve hatalı tasarımlarda, geliştiricinin ayrıcalıklarıyla ve bir onay adımı olmadan üzerinde harekete geçebiliyor.

Yalnızca bir iş istasyonu sorunu değil

dev.to analizi, bunun sınırlı bir etki alanına sahip tek dizüstü bilgisayar sorunu olduğu fikrine itiraz ediyor. Kodlama ajanları kullanan geliştiriciler genellikle kaynak kontrol sistemlerine, paket kayıtlarına, bulut ortamlarına ve CI sistemlerine uzanan kimlik bilgilerine sahiptir ve ajan tarafından çalıştırılan bir komut bu ortamı devralır: ortam değişkenleri, yapılandırma dosyaları, kimlik bilgisi yardımcıları ve SSH agent soketleri. Ele geçirilen varlık depo değil, geliştiricinin kimliği ve o kimliğin erişebildiği her şeydir.

Bir de otomasyon boyutu var. Ajanların depoları gözetimsiz işlediği durumlarda, örneğin bir inceleme hattında veya zamanlanmış bir görevde, enjeksiyon noktası geliştiricinin iş istasyonundan, daha geniş ayrıcalıklara sahip ve daha az görünür kanıt bırakabilecek otomatik bir sisteme kayıyor.

Ortak tasarım kararları

Yazıya göre, etkilenen araçlarda üç örüntü tekrarlanıyor:

• Depo içindeki yapılandırma dosyaları güvenilmeyen girdi olarak değil, proje ayarları olarak ele alınıyor. Bu kullanışlıdır ve aynı zamanda güvenlik açığının kendisidir.
• Yapılandırma değerlerinin komut veya çalıştırılabilir dosya yolu belirtmesine izin veriliyor, bu da yapılandırmayı koda dönüştürüyor.
• Depo içeriğini okuma ile üzerinde harekete geçme arasında yetersiz ayrım var. Yalnızca içerik okuyan bir ajan sınırlıdır; içeriği okuyup sonra geliştiricinin ayrıcalıklarıyla çalıştıran bir ajan sınırlı değildir.

Pratik önlemler

Önerilen savunmalar bu analizden doğrudan çıkıyor:

• Depo yapılandırmasını güvenilmeyen girdi olarak ele alın ve ajan ayarlarındaki değişiklikleri, CI iş akışlarındaki veya derleme betiklerindeki değişikliklere uygulanan aynı özenle inceleyin.

• Aracın desteklediği her yerde, ajan bir komut çalıştırmadan önce bir onay adımını etkinleştirin; özellikle geliştiricinin kendi talimatından değil depo içeriğinden türetilen komutlar için.

• Ajanları azaltılmış ayrıcalıkla çalıştırın: ortamı daraltın, gereksiz token'ları shell'den kaldırın ve geliştirici bağlamında uzun ömürlü bulut kimlik bilgilerinden kaçının.

• Gözetimsiz ajan çalıştırmalarını, tanımlı bir dosya sistemi görünümüne ve ağ politikasına sahip bir container ya da sandbox içinde izole edin; üretim kimlik bilgilerine erişimi olan bir makinede değil.

• Araçları yamalayın, ardından inceleyin. Güvenlik açığı komut çalıştırmayla sonuçlandığı için, etkilenmiş bir makinede beklenmeyen giden bağlantılar, yeni kalıcılık kayıtları ve shell profillerinde veya kimlik bilgisi yardımcılarındaki değişiklikler açısından kontrol edilmelidir.

Neden önemli

Bu bir bellek bozulması ya da ince bir ayrıştırıcı hatası değil. Bu, depo içeriğinin üzerinde harekete geçilmeye uygun olduğu yönündeki bir tasarım varsayımı ve bu varsayım, güven modellerinden daha hızlı dağıtılan araçlara gömülmüş durumda. Bir depoyu okuyup ardından bir şey çalıştıran her araç tek bir soruya karşı test edilmelidir: bir saldırgan bu dosyayı kontrol ederse, ajanı ne yaptırabilir? Cevap geliştiricinin kimlik bilgileriyle bir komut çalıştırmayı içeriyorsa, yapılandırma dosyası bir saldırı yüzeyidir ve böyle ele alınmalıdır.