CVSS skorunun mümkün olan en üst değerine, 10.0'a ulaştığı açıklar ender görülür. Google'ın Gemini CLI aracında tespit edilen ve geçtiğimiz haftalarda düzeltilen açık bu kategoriye giriyor: headless modda çalışırken güvenilmeyen klasörleri otomatik olarak güvenilir kabul ederek, saldırganlara CI/CD ortamlarında uzaktan kod çalıştırma imkanı sunuyordu. Sorun, yapay zeka araçlarının "denetlenmiş içerik" ile "kontrol dışı içerik" arasındaki sınırı çizmekte başarısız olmasıydı. Sürüm 0.39.1 öncesinde araç, çalıştığı her dizinde .gemini/ klasörünün konfigürasyon dosyalarını ve ortam değişkenlerini hiçbir doğrulama yapmadan yüklerdi. Bu tasarım kararı, otomatizasyon ortamlarında kod çalıştırma yetkisinin kimden geldiğini sorgulama mekanizmasını es geçiyordu.
CI/CD hattında yetkilendirilmemiş kod yürütmesi nasıl gerçekleşti
Gemini CLI, geliştiricilere terminal üzerinden Google'ın yapay zeka modellerini kullanma imkanı veren bir npm paketidir. Headless modda çalışırken her klasörü konfigürasyon dosyaları ve ortam değişkenleri yükleme amacıyla otomatik olarak güvenilir kabul ediyordu. Bu davranış, --yolo modu olarak adlandırılan ve kullanıcı onayı beklemeden araç çağrılarını gerçekleştiren modla birleşince, CI/CD sistemlerinde tehlikeli bir yüzey oluşturdu.
Açığın teknik mekaniği şu şekilde işliyordu: Bir saldırgan, hedef bir depoya kötü amaçlı .gemini/config dosyası veya .gemini/.env ortam değişkeni dosyası ekleyebilir. CI pipeline'ı bu depoyu klonladığında ve Gemini CLI'yı çalıştırdığında, araç bu dosyaları güvenilir olarak yükler ve içlerindeki komutları çalıştırır. Saldırganlar .gemini/ dizininde kötü amaçlı ortam değişkenleri yoluyla kod çalıştırabilirledi. Bu, bir prompt injection saldırısı değil, altyapı düzeyinde bir yetkilendirme hatasıdır. Saldırı, kontrollü içeriğin sandbox başlatılmadan önce güvenilir yapılandırma olarak kabul edilmesiyle ilgilidir.
Güvenlik araştırmacıları Elad Meged ve Dan Lisichkin, CI/CD tedarik zinciri saldırı vektörlerini araştırırken bu açığı bağımsız olarak keşfetti. Novee Security tarafından açık bildirimi yapılmıştır.
Düzeltmenin yarattığı backward compatibility krizi
Google, 0.39.1 ve 0.40.0-preview.3 sürümlerinde düzeltmeyi yayınladı. Artık klasörlerin açıkça güvenilir olarak işaretlenmesi gerekiyor ve CI iş akışlarında GEMINI_TRUST_WORKSPACE ayarının manuel olarak yapılandırılması zorunlu. Policy engine, --yolo modunda bile araç whitelist'ini kontrol etmeye başladı.
Ancak düzeltme, GitHub Actions ekosisteminde beklenmedik bir yan etki yarattı. run-gemini-cli GitHub Action varsayılan olarak en yeni Gemini CLI sürümünü kullananlar otomatik güncellemeye tabi oluyor. Sürüm pini belirtmemiş iş akışları, güncellemeyle birlikte sessizce başarısız olmaya başladı çünkü önceki --yolo modunun davranışı değişti. Güvenlik açığı kapatıldı ama mevcut dağıtımlarda beklenen davranış kırıldı.
Geliştiriciler, CI/CD pipeline'larını manuel olarak güncellemeli ve GEMINI_TRUST_WORKSPACE ortam değişkenini eklemelidir. Otomatik güncelleme mekanizması, güvenlik açıklarını hızla kapatma avantajı sağlarken, aynı zamanda değişikliklerin tüm kullanıcılara anında yayılması nedeniyle iş akışlarında kesinti riski taşıyor.
Cursor IDE'deki benzer sorunlar: sandbox bypass ve kimlik bilgisi hırsızlığı
Gemini CLI'daki açık, yapay zeka araçlarında yalnız değil. Cursor IDE'de CVE-2026-26268 olarak etiketlenen açık, kötü niyetli bir Git post-checkout hook'u içeren çıplak depo aracılığıyla AI ajanının otomatik olarak kod yürütmesine izin veriyordu. Cursor 2.5 sürümü öncesinde, .git dosyasındaki kötü amaçlı hook'lar sandbox mekanizmasını bypass edebiliyordu. Saldırı senaryosu şu şekilde işliyor: Bir geliştiriciye özel olarak hazırlanmış bir Git deposu gönderiliyor. Geliştirici bu depoyu Cursor ile klonladığında, post-checkout hook otomatik olarak çalışıyor ve AI ajanının korumalı ortamını atlatıyor.
Cursor'da tespit edilen bir diğer açık ise CVSS 8.2 puanına sahip ve kurulu uzantıların SQLite veritabanında saklanan API anahtarlarına ve session token'larına yetkisiz erişimini engellemiyordu. Bu açık halen düzeltilmemiş durumda. Herhangi bir kurulu uzantı, Cursor'ın kimlik bilgilerini saklayan SQLite veritabanına erişebiliyor. Bu, erişim kontrolünün uzantı seviyesinde yeterince granüler olmadığını gösteriyor.
Her iki açık da yapay zeka ajanlarının kullanıcı onayı olmaksızın denetim zinciri dışında otomatik eylemler gerçekleştirmesiyle ortaya çıkıyor. Prompt injection saldırılarından farklı olarak, bu açıklar sandbox bypass ve yetkisiz erişim kontrol sorunlarıdır.
Token hırsızlığı ve tedarik zinciri pivotları
Bu tür açıkların tehdit modeli, basit kod yürütmeden çok daha geniş. Açık, token hırsızlığı, tedarik zinciri pivotları ve downstream sistemlere yanal hareket sağlamaya yetecek paydaş ve kimlik bilgilerine erişim veriyor. CI/CD ortamlarında çalışan araçlar, bulut platformlarına erişim token'larına, API anahtarlarına, veri tabanı kimlik bilgilerine ve dağıtım sırlarına sahip. Bir saldırgan, Gemini CLI açığını kullanarak CI sistemine sızarsa, bu kimlik bilgilerini çalabilir ve production ortamlarına yanal hareket yapabilir.
Örneğin, bir saldırgan GitHub Actions workflow'unda Gemini CLI'yı çalıştıran bir depoya kötü amaçlı konfigürasyon dosyası enjekte ederse, workflow çalıştığında CI ortamındaki GITHUB_TOKEN, AWS kimlik bilgileri veya Kubernetes erişim anahtarları gibi sırları okuyabilir. Bu sırlar downstream sistemlere erişim için kullanılabilir.
Cursor'daki token hırsızlığı senaryosu ise daha doğrudan: Kötü niyetli bir uzantı, Cursor'ın SQLite veritabanında saklanan API anahtarlarını okuyabilir ve bunları uzak bir sunucuya gönderebilir. Kullanıcılar, geliştirme ortamlarında OpenAI, Anthropic veya Google API anahtarlarını sakladıkları için, bu kimlik bilgilerinin çalınması doğrudan mali ve veri kaybına yol açabilir.
CI/CD entegrasyonunda tasarım kararlarının maliyet
Gemini CLI, kullanıcı deneyimini basitleştirmek için headless modda otomatik güven politikası benimsedi. Bu, manuel onay gerektirmeyen hızlı entegrasyon anlamına geliyordu ama aynı zamanda güvenlik sınırını belirsizleştirdi. Cursor, uzantı ekosistemini zenginleştirmek için SQLite veritabanı erişimini serbestçe bıraktı ama bu da yetkisiz erişim riskini yarattı.
Bu kararlar, kullanılabilirlik ve güvenlik arasındaki dengesini yansıtıyor. Ancak CI/CD ortamlarında, bu denge daha hassastır çünkü araçlar headless modda çalışır ve insan denetimine tabi değildir. Bir geliştirici IDE'sinde yapay zeka aracı kullanırken, aracın yaptığı işlemleri görebilir ve onaylayabilir. CI pipeline'ında ise araç otomatik çalışır ve kullanıcı etkileşimi yoktur. Bu nedenle, CI/CD entegrasyonu için tasarlanan araçların güvenlik modelinin varsayılan olarak daha kısıtlayıcı olması gerekir.
Google'ın düzeltmesi bu yönde bir adım: Artık klasörler açıkça güvenilir olarak işaretlenmeli ve CI ortamlarında GEMINI_TRUST_WORKSPACE ortam değişkeni manuel olarak ayarlanmalıdır. Bu, otomasyonu biraz zorlaştırır ama altyapı seviyesinde güvenlik sınırını yeniden tanımlar. Cursor'ın halen düzeltilmemiş token erişimi sorunu ise devam eden bir risk temsil ediyor.
Vulnerable workflows need version pinning and explicit trust configuration
Gemini CLI kullanan ekipler için acil adımlar bellidir. GitHub Actions veya benzeri platformlarda kullanılan tüm yapay zeka araçlarının sürümlerini pinine ekleyin. run-gemini-cli gibi action'ları @latest yerine belirli bir sürüm etiketiyle kullanın. Örneğin @v0.39.1 yerine @latest bırakmak, bir sonraki breaking change'i otomatik olarak ortaya çıkaracaktır.
Gemini CLI kullanan iş akışlarına GEMINI_TRUST_WORKSPACE=true ortam değişkenini ekleyin. Bu değişken, aracın hangi klasörleri güvenilir kabul edeceğini açıkça belirtir. Varsayılan güven politikasına güvenmek yerine, hangi dizinlerin konfigürasyon yüklemeye yetkili olduğunu açıkça tanımlayın.
CI ortamlarında kullanılan kimlik bilgilerinin kapsamını minimumda tutun. Her iş akışının yalnızca görevini tamamlamak için gereken izinlere sahip olması gerekir. Token'ların geçerlilik sürelerini kısıtlayın ve rotasyonu otomatikleştirin.
Cursor gibi geliştirici araçlarında kullanılan uzantıları düzenli olarak gözden geçirin. API anahtarlarını Cursor'ın SQLite veritabanında değil, sistem-level secret manager'da saklayın. Bu, SQLite erişimi açıklarından bağımsız olarak kimlik bilgilerini korur.
