Yapılan son incelemeler, LiteLLM ile çalışan açık yapay zekâ gateway’lerinin kayda değer bir bölümünün, kurulum kılavuzunda örnek olarak verilen sk-1234 yönetici anahtarını hâlâ kabul ettiğini ortaya koydu. Şubat ayında yapılan taramada bulunan 3.074 açık LiteLLM gateway’in 294’ü bu anahtarı kabul etti; bunların 191’inde ise hiç anahtar tanımlanmamıştı. Bu durum, yönetici erişimi elde eden bir saldırganın sunucuda saklanan model sağlayıcı API anahtarlarını, bazı kurulumlarda da bulut IAM kimlik bilgilerini görebilmesi anlamına geliyor.
LiteLLM, şirketlerin uygulamaları ile ücretini ödedikleri model sağlayıcıları arasına yerleştirilen açık kaynaklı bir AI gateway olarak kullanılıyor. Yönetici anahtarı, hem kimlik doğrulamasını açan anahtar rolünü görüyor hem de sistemin idari kapısını temsil ediyor. Araştırmacılar, bu anahtarı ele geçiren birinin yalnızca model sağlayıcılarının anahtarlarını okumakla kalmayıp, gateway’in çalıştığı makinenin bulut yetkilerine kadar uzanabildiğini belirtiyor. İncelemede bu erişimin, gateway’in yönlendirildiği ortamın IAM bilgilerine ulaşabildiği de gösterildi.
Varsayılan anahtarın bu kadar kritik görülmesinin nedeni, LiteLLM’in yönetici anahtarını iki işi aynı anda yapan bir unsur olarak tasarlaması. 1.82.0-stable sürümünden önce, master key olmadan başlatılan bir gateway gelen her isteğe tam yönetici yetkisi veriyordu. Bu da sistemde yalnızca yöneticinin görmesi gereken kayıtların, prompt ve yanıt akışlarının, MCP üzerinden bağlanan iç araçların ve saklanan sağlayıcı anahtarlarının erişilebilir hale gelmesi demekti. Çalınan sağlayıcı anahtarları ayrıca saldırgana, kurbanın faturası üzerinden model iş yükü çalıştırma imkânı da veriyor; bu kullanım LLMjacking olarak biliniyor.
Taramadaki sayılar, Şubat ayında tek bir çalışma ile elde edildi. Aynı ay Shodan üzerinde görülen 3.074 LiteLLM örneğinin 294’ü sk-1234 anahtarını kabul ediyordu. Bunların 191’inde hiç anahtar ayarlanmamıştı; geri kalanlarda ise kurulum kılavuzundaki örnek değer bırakılmıştı. Ağustos ayında yapılan ikinci taramada 85 binden fazla örnek görüldü, ancak araştırmacılar bunların çoğunun honeypot ya da test sistemi gibi göründüğünü, bu yüzden iki sayının birbirine kıyaslanamayacağını aktardı. Eylül itibarıyla da kurulum kılavuzu, gerçek kullanıma geçmeden önce kısa bir yorum satırının üzerinde hâlâ sk-1234 değerini gösteriyordu.
LiteLLM’in güvenlik politikasında, master key tanımlamamak gibi kurulum hatası gerektiren saldırılar açıkça kapsam dışı sayılıyor. Proje, bu tür durumları güvenlik açığı olarak değerlendirmediğini de yazıyor. Şirketin yaklaşımı ile araştırmacıların bulguları bu noktada ayrışıyor; ancak kaynak metindeki verilere göre açık bir CVE kaydı olmayan bu yönetici erişimi senaryoları, varsayılan bir anahtarın bırakılması halinde doğrudan işleyen saldırı yolları yaratıyor.
İncelemede öne çıkan bir başka nokta, geçiş yönlendirmesi yapan endpoint’ler oldu. LiteLLM, yöneticinin istediği herhangi bir URL’ye istek iletebilen bir pass-through endpoint oluşturmasına izin veriyor. Ancak hedef adresin özel IP aralıkları, localhost ya da bulut metadata adresleri için denetlenmediği belirtiliyor. Bu nedenle saldırgan, trafiği instance metadata service’e yönlendirerek dönen IAM kimlik bilgilerini okuyabiliyor. IMDSv2’ye geçiş de bunu durdurmuyor; çünkü LiteLLM dokümantasyonunda, x-pass- önekiyle gönderilen tüm başlıkların hedefe önek çıkarılmış halde iletildiği yazıyor. Araştırmacılar da IMDSv2’nin zorunlu kıldığı başlıkları bu yöntemle göndermeyi başardıklarını aktardı. Buna karşın, gerçek bir kurulumda bu yöntemin kullanıldığına dair kamuya açık bir örnek yok; gösterim yönetici erişimi gerektiriyor ve araştırmacılar bunu ispat çalışması olarak sundu.
LiteLLM tarafı, pass-through davranışını kendi tehdit modelinde yöneticiler güvenilir kabul edildiği için tasarımın parçası olarak görüyor. Bu yüzden açıklanan metadata erişimi için ne bir CVE yayımlandı ne de bir yama duyuruldu. Aynı durum, geçiş yolunun kendisi için de geçerli; proje bu alanı bir güvenlik açığı olarak sınıflandırmıyor. Buna karşın, saldırganın önce yönetici erişimi kazanması gerektiği için risk zinciri, master key’in nasıl yönetildiğine doğrudan bağlı kalıyor.
Rapordaki kod çalıştırma zafiyetlerinden biri CVE-2026-59821 olarak numaralandırıldı. Araştırmacılar bunu root seviyesinde, kimlik doğrulama sonrası kod çalıştırma olarak tanımlarken; LiteLLM aynı zafiyet için yayımladığı duyuruda düşük etki puanı verdi ve yüksek yetkili bir hesap gerektirdiğini yazdı. Her iki açıklama da aynı davranışı tarif ediyor: 1.82.0-stable sürümünden önce özel kod guardrail’i oluşturan ve güncelleyen endpoint’ler, test endpoint’lerinin uyguladığı sandbox ve pattern kontrollerini atlıyordu. Böylece bu endpoint’lere ulaşabilen biri, kapsayıcı içinde çalışan Python kodu gönderebiliyordu. Duyuruya göre, master key olmayan bir kurulumda çağrıları proxy yöneticisi olarak yorumlayan sistem, bu endpoint’lerin erişim alanını da genişletiyordu.
Aynı sınıftaki bir başka açık CVE-2026-40217 koduyla Mayıs ayında ayrıca yayımlandı. Bu duyuruda sandbox’tan bytecode teknikleriyle kaçılabildiği, kodun varsayılan Docker imajında root olarak çalışan proxy sürecinde yürütülebileceği yazıyor. Etkilenen sürümler 1.81.8 ile 1.83.10 arasındaki aralık olarak verildi; duyuru metninde ise düzeltmenin 1.83.10 olduğunu, başka bir bölümde 1.83.11 ifadesinin geçtiği de dikkat çekiyor. Bu endpoint’e erişmek için proxy-admin yetkisi gerekiyor ve master key de tam olarak bu yetkiyi sağlıyor.
Wiz’in açıkladığı bu iki kod çalıştırma sorunu, raporun yayımlandığı 9 Eylül’den aylar önce kapatılmıştı. Kaynak metne göre düzeltmeler Şubat ve Nisan aylarında yapıldı, CVE kayıtları ise Temmuz’da yayımlandı. Yani mesele yeni bir açık zincirinden çok, varsayılan anahtar ve yanlış yapılandırmaların, kapatılmış eski zafiyetlerle birleştiğinde ne kadar geniş bir etki alanı oluşturabildiğini gösteriyor.
LiteLLM ekosisteminde bununla karışabilecek başka açıklar da bulunuyor, ancak bunlar aynı saldırı yolunu temsil etmiyor. CISA, 2 Eylül’de Known Exploited Vulnerabilities kataloğuna bir LiteLLM açığı ekledi. CVE-2026-59822 numaralı bu sorun, CVSS 8.8 puanına sahip ve bir saldırganın herhangi bir Bearer token ile, tek karakterlik bir token dâhil, geçerli bir MCP oturumu açmasına izin veriyor. Federal sivil kurumların bunu 16 Eylül’e kadar gidermesi gerekiyor. Wiz, 7 Temmuz’dan itibaren kendi honeypot’larında tek karakterli token’larla model listeleme endpoint’lerini yoklayan istekler gördüğünü aktardı. Şirket, bu açık için MCP sunucusuna erişim dışında bir kullanım tarif etmedi.
Uzaktan kod çalıştırmak için kullanılan daha eski açık ise CVE-2026-42271. CVSS puanı 8.7 olan bu hata, kimliği doğrulanmış herhangi bir kullanıcının iki MCP test endpoint’i üzerinden host üzerinde komut çalıştırmasına izin veriyordu. Horizon3.ai, Haziran ayında bu açığın CVE-2026-48710 numaralı bir Starlette host-header açığıyla birleştirilerek hiçbir kimlik bilgisi olmadan da kullanılabildiğini bildirdi. Wiz’in honeypot kayıtlarında bu açıkla madencilik yazılımı kurulduğu da görüldü.
Microsoft, Ağustos ayında paylaştığı bir vakada saldırganların LiteLLM gateway süreci içinde komut çalıştırdığını, kapsayıcının environment değişkenlerinden master key, sağlayıcı anahtarları ve veritabanı bağlantı dizesini okuduğunu anlattı. Ardından bu bağlantı dizesiyle alttaki PostgreSQL veritabanına erişildiği ve LiteLLM’in model ile virtual-key tablolarındaki kayıtların kopyalandığı belirtildi. Microsoft, saldırganların erişimi açık gateway üzerinden elde ettiğine yüksek güvenle inandığını ve giriş noktasının CVE-2026-42271 ile CVE-2026-48710 zinciriyle uyumlu olduğunu söyledi. Şirket bu nedenle AI gateway’lerin Tier-0 sır depoları gibi ele alınması gerektiğini vurguladı.
Mevcut düzeltme tablosuna göre 1.84.0 ve sonraki sürümlere geçmek listelenen tüm açıkları kapsıyor. CVE-2026-59822 için düzeltme 1.84.0’da, CVE-2026-42271 için 1.83.7’de, CVE-2026-59821 için 1.82.0-stable’da, CVE-2026-40217 için ise 1.83.10’da veriliyor; ancak duyuru metninde 1.83.11 ifadesi de yer alıyor. İlgili NVD kayıtları için CVE bağlantıları şu şekilde izlenebiliyor: CVE-2026-59822, CVE-2026-42271, CVE-2026-59821 ve CVE-2026-40217.
Yama uygulanamayan ortamlarda LiteLLM’in kendi duyurularında önerdiği geçici önlemler de net. /mcp/ yolunu ve iki MCP test endpoint’ini, yani POST /mcp-rest/test/connection ile POST /mcp-rest/test/tools/list isteklerini reverse proxy ya da API gateway katmanında engellemek gerekiyor. Ayrıca POST /guardrails/test_custom_code istekleri de bloklanmalı; POST /guardrails ve PUT /guardrails/{guardrail_id} erişimleri yalnızca yöneticilerle sınırlandırılmalı. Geçiş endpoint’leri yeniden gözden geçirilmeli, kapsayıcının dış ağa çıkışı kısıtlanmalı ve iş yüküne yalnızca ihtiyaç duyduğu en dar bulut IAM rolü verilmeli.
Bir ihlal şüphesi varsa, incelemeye göre guardrails listesindeki beklenmedik kayıtlar kontrol edilmeli, bellekte kalan kodu temizlemek için süreç yeniden başlatılmalı ve sağlayıcı anahtarları, master key ile veritabanı kimlik bilgileri döndürülmeli. Yalnızca sürüm yükseltmek, saldırganın eklediği bir guardrail’i ya da bıraktığı SSH anahtarını silmiyor. Instance metadata yoluna yapılan pass-through için ise LiteLLM tarafında bir yama bulunmuyor; proje bunu açık olarak sınıflandırmadığı için elde kalan kontroller yine dış ağ sınırları ve dar IAM yetkileri oluyor.
Kaynak metin, devralınan bir gateway’de MCP ya da pass-through yönlendirmesinin açık olup olmadığını nasıl doğrulayacağını söylemiyor. Microsoft’un paylaştığı avlanma sorguları ise yapılandırmayı değil, yalnızca istismarı yakalıyor. Bu nedenle tartışma, tek bir varsayılan anahtarın ve birkaç açık endpoint’in, görünürde sıradan bir AI gateway’i nasıl geniş bir erişim kapısına çevirebildiği etrafında dönüyor.