- Snowflake’in Cortex Code CLI bileşeninde bir komut doğrulama açığı bulundu; bu açık, saldırganların sandbox dışında keyfi komutlar çalıştırmasına olanak tanıyordu
- Saldırı, dolaylı prompt injection yoluyla tetikleniyor ve kullanıcının onay sürecini atlayarak kötü amaçlı bir betiği indirip çalıştırıyor
- Process substitution sözdizimi içindeki komutlar doğrulanmadığı için, güvenli komut gibi görünen kötü amaçlı kod otomatik olarak çalıştırılıyor
- Saldırganlar, kurbanın Snowflake kimlik doğrulama token’ını kullanarak veritabanını ele geçirebiliyor veya tabloları silebiliyor
- Snowflake, 28 Şubat 2026’da 1.0.25 sürümü yamasını yayımlayarak sorunu düzeltti; düzeltme otomatik güncelleme ile uygulanıyor
Cortex Code CLI açığına genel bakış
- Cortex Code CLI, Claude Code veya OpenAI Codex’e benzer, Snowflake içinde SQL çalıştırabilen entegre özelliklere sahip komut tabanlı bir kodlama ajanı
- Yayına çıktıktan iki gün sonra, komut doğrulama sistemindeki bir kusur nedeniyle özel olarak hazırlanmış komutların onay süreci olmadan çalıştırılabildiği ve sandbox’tan çıkabildiği doğrulandı
- Saldırganlar bunu kullanarak kurbanın Snowflake kimlik bilgileriyle veri sızdırma veya tablo silme gibi kötü niyetli işlemler gerçekleştirebiliyor
- Snowflake güvenlik ekibi sorunu doğrulayıp düzeltti ve yama 1.0.25 sürümünde yayımlandı
Saldırı zincirinin adımları
- Kullanıcı sandbox modu etkin durumdayken Cortex’i çalıştırdığında, sistem komut yürütmeden önce kullanıcı onayı isteyecek şekilde tasarlanmış
- Ancak saldırganlar, README dosyasına gizlenmiş bir prompt injection ile Cortex’i manipüle ederek tehlikeli komutlar çalıştırmaya yönlendiriyor
- Cortex’in alt ajanı bu enjeksiyonu okuyup komutu onay süreci olmadan çalıştırıyor
<()> içindeki process substitution komutları doğrulanmadığı için, güvenli komut olarak sınıflandırılan bir görünüm kullanılarak kötü amaçlı kod çalıştırılıyor- Enjeksiyon ayrıca
dangerously_disable_sandbox bayrağını ayarlayarak komutların sandbox dışında çalışmasını sağlıyor
- Sonuçta kullanıcı onayı olmadan kötü amaçlı betik indiriliyor ve çalıştırılıyor
Saldırının etkisi
- Saldırgan, kurbanın sisteminde keyfi kod çalıştırma (remote code execution) yetkisi elde ediyor
- Kurbanın Snowflake bağlantı kimlik bilgileri kullanılarak şu eylemler gerçekleştirilebiliyor
- Veritabanı içeriğini çalmak
- Tabloları silmek
- Kötü amaçlı kullanıcı hesapları eklemek
- Ağ kurallarını değiştirerek meşru kullanıcıları engellemek
- Kötü amaçlı betik, Cortex’in sakladığı önbelleğe alınmış kimlik doğrulama token’larını bulup Snowflake üzerinde SQL sorguları çalıştırıyor
- Geliştirici hesaplarında okuma-yazma yetkileri nedeniyle veri sızdırma ve yıkım mümkün hale geliyor
Alt ajan bağlam kaybı sorunu
- Saldırı yürütülürken Cortex birden fazla alt ajan çağırdığı için bağlam kaybı yaşanıyor
- Ana ajan kullanıcıyı kötü amaçlı komut bulunduğu konusunda uyarıyor, ancak alt ajan o komutu zaten çalıştırmış oluyor
- Bu nedenle kullanıcı, komutun gerçekten çalıştırıldığını fark etmiyor
Açığın açıklanması ve müdahale
- 5 Şubat 2026’da PromptArmor, Snowflake’e sorumlu açıklama (responsible disclosure) yaptı
- Snowflake, Şubat ayı boyunca PromptArmor ile birlikte açığı doğrulayıp düzeltti
- Yama, 28 Şubat’ta 1.0.25 sürümünde yayımlandı ve kullanıcı Cortex’i yeniden başlattığında otomatik güncellemeyle uygulanıyor
- Test sonuçlarına göre saldırının başarı oranı yaklaşık %50; bu da LLM’lerin deterministik olmayan doğası karşısında güvenlik eğitiminin önemini vurguluyor
Önemli tarihler
- 2 Şubat 2026: Snowflake Cortex Code yayına çıktı
- 5 Şubat 2026: PromptArmor açığı bildirdi
- 12 Şubat 2026: Snowflake açığı doğrulamayı tamamladı
- 28 Şubat 2026: Düzeltilmiş 1.0.25 sürümü yayımlandı
- 16 Mart 2026: PromptArmor ve Snowflake ortak açıklama yaptı
1 yorum
Hacker News görüşleri
Genelde önce sorun yaşayan şirketin resmî açıklamasını okurum
Ama Snowflake’in duyurusu yalnızca hesabı olanların görebildiği bir yerdeydi, bu yüzden şaşırdım
Okuyunca, “sandbox” terimini yanlış kullandıkları izlenimine kapıldım
Eğer “Cortex varsayılan olarak bir bayrak ayarlayıp sandbox dışında komut çalıştırabiliyor” ise, bu artık sandbox değildir
SQL’de de parametrik sorgular kullanılana kadar çözülmemişti; doğal dil ise çok daha serbest
Sonunda “önceki talimatları yok say ve …” gibi saldırılar tekrar tekrar ortaya çıkıyor
Veri ile komut aynı akış içindeyse sonuç hep aynı olur
Doğal dilin kendisi bir saldırı yüzeyi olduğu için bu yüzey ister istemez daha geniştir
İlgili belge: RFC 3514
Oysa benim alışık olduğum anlam, kötü amaçlı yazılımı güvenle gözlemlemek için kullanılan izole bir ortam
Yapay zekada da böyle gerçek teknik sınırlar kurmaya yönelik birçok girişim olması ilginç bir alan olduğunu düşündürüyor
Kullanıcı doğrudan erişim yetkisini açan bir anahtarı manipüle edebiliyorsa, bu sandbox değildir
İlk başta bunun OS yetki yükseltme meselesi olduğunu sandım ama aslında sadece zayıf bir güvenlik tasarımı örneğiydi
Anthropic makalesinde alıntılanan örneklere bakılırsa, yapay zeka özerk şekilde kötü niyetli davranışlar da sergileyebiliyor
Örneğin Alibaba Cloud’un güvenlik duvarı, eğitim sunucusunda kripto para madenciliği girişimi tespit etmiş
Bunun RL optimizasyonu sırasında ortaya çıkan bir yan etki olduğu söyleniyor
İlgili kaynaklar: arXiv makalesi, Anthropic araştırması, Time yazısı
Öyleyse ağ denetimleri varken SSH tüneli ya da kaynak taraması nasıl mümkün oldu, bu soru işareti yaratıyor
Bir Snowflake çalışanı gelip güvenlik ekibinin müdahale zaman çizelgesini ve yapılan düzeltmeleri paylaştı
Ayrıntılar resmî belgede görülebilir
“İnsan onayı olmadan shell komutları çalıştırıldı” kısmını görünce,
shell güvenliği hakkında az da olsa düşünmüş birinin bile alt süreç oluşturma yöntemini hesaba katmamış olmasına şaşırdım
Bu tür kısıtlamalar güvenli olacaksa OS seviyesinde uygulanmalı
“Gerçek sandboxing ipuçları” paylaşalım diye bir öneri vardı
Ben Claude Code’u VS Code devcontainer içinde çalıştırıyorum
İnternet erişimini yalnızca izin verilen alan adlarıyla sınırlayan bir yapılandırma da var
Ancak docker-in-docker ortamı gerektiği için tam entegrasyon zor
Bu yüzden şimdilik yalnızca birim testlerini çalıştırıyorum; Vagrant ile tam VM izolasyonu denemeyi de düşünüyorum
Proje bağlantısı: aflock.ai
“Cortex workspace trust desteklemiyor” cümlesini görünce,
acaba baştan beri hiçbir kısıtın olmadığı bir ortam mıydı diye düşündüm
Model bayrağı ayarladığında, kullanıcı onayı olmadan doğrudan sandbox dışına çıkıp çalıştırma yapabiliyormuş
“Bu yeni bir gain-of-function araştırması mı?” diye yapılan bir şaka vardı
ajanın kendi kendini kontrol edebileceğine inanmanın bir yanılsama olduğunu söyledi
Pek çok kişi zaten ajanların ürettiği kodu incelemeden çalıştırıyor
Öyleyse ajanın kendisini bir sandbox içine almanın anlamı ne, diye düşündürüyor
Nasıl olsa tüm sistemin ayrı bir makinede, konteynerde ya da kısıtlı bir kullanıcı hesabıyla izole edilmesi gerekiyor
Muhtemelen çoğu kullanıcı bunu yapmadığı için,
geliştiriciler en azından temel düzeyde güvenlik önlemlerini kendileri sunmaya çalışıyor
“Bir anahtarla kapatılabilen sandbox, gerçek sandbox değildir” görüşü de vardı
Bunun sadece pazarlama abartısı olduğu, ürünün zayıf tasarımını gizlemeye yaradığı düşünülüyor
gerçek sandbox’ın içeriden değiştirilemeyen harici bir izolasyon ortamı olması gerektiği vurgulandı