Açığa çıkan LiteLLM ağ geçitlerinin neredeyse 10'da 1'i örnek 'sk-1234' yönetici anahtarını kabul etti.
Swati Khandelwal 10 Eyl 2026 Bulut Güvenliği / Yapay Zeka
Wiz Research'un Şubat ayında taradığı internete açık LiteLLM sunucularının yaklaşık onda biri, LiteLLM'in kendi kurulum kılavuzundaki örnek yönetici anahtarı olan sk-1234'ü kabul etti.
LiteLLM açık kaynaklı bir yapay zeka ağ geçididir; bir şirketin uygulamaları ile ödediği model sağlayıcıları arasına koyduğu yazılımdır. Bu anahtar, ağ geçidinin yönetici kimliğidir.
Bu anahtara sahip olan herkes sunucuda saklanan her model sağlayıcısının API anahtarını okuyabilir. Wiz'in testlerinde bu anahtar, ağ geçidinin çalıştığı makinenin bulut IAM kimlik bilgilerine de ulaştı.
Anahtarı değiştirmek yükseltme gerektirmez ve Wiz raporunda buna sahip olmaya bağlı olan her yolu kapatır.
Sayı Nereden Geliyor
Wiz tek bir tarama yaptı. Şubat ayında Shodan'da 3.074 LiteLLM ağ geçidi buldu ve bunların 294'ü anahtarı kabul etti.
Bu 294'ün 191'inde hiç anahtar ayarlanmamıştı, bu yüzden her şeyi kabul ederlerdi. Kalanlarında kurulum kılavuzundaki değer yerinde bırakılmıştı.
Ağustos'taki ikinci tarama 85.000'den fazla örnek buldu, ancak Wiz bunların çoğunun bal peteği veya test sistemleri gibi görünmesini söyledi, bu yüzden iki sayı karşılaştırılamaz. Güncel bir rakam yok.
9 Eylül itibarıyla LiteLLM'in kurulum kılavuzu hâlâ sk-1234 kullanıyor; operatörlerin gerçek kullanımdan önce uzun rastgele bir değerle değiştirmesi gerektiğini söyleyen bir yorumun üzerinde yer alıyor.
Neden Tek Bir Anahtar Bu Kadar Önemli
Ana anahtar aynı anda iki iş yapar ve bu, varsayılan bir değerin ciddi olmasını sağlayan şeydir. Bu hem yönetici kimliğidir hem de kimlik doğrulamayı etkinleştiren anahtardır.
1.82.0-stable sürümünden önce, ana anahtar olmadan başlatılan bir ağ geçidi gelen her isteğe tam yönetici hakları verirdi.
Bu sunuculardan birindeki bir yönetici çok şeye ulaşabilir. Ağ geçidi, yönlendirdiği her sağlayıcı için bir API anahtarı tutabilir, üzerinden geçen her istem ve yanıtı görebilir ve Model Context Protocol (MCP) üzerinden dahili araçlara bağlanabilir.
Ayrıca genellikle dağıtıldığı iş yükünün bulut izinleriyle çalışır. Çalınan sağlayıcı anahtarları tek başına saldırganın model iş yüklerini mağdurun faturasına çalıştırmasına izin verir; bu kötüye kullanıma LLMjacking denir.
Anahtarın Bulut Hesabına Nasıl Ulaştığı
LiteLLM bir yöneticinin geçit uç noktası oluşturmasına izin verir; bu rota, yöneticinin seçtiği herhangi bir URL'ye istekleri iletir.
Hedef URL özel adres aralıklarına, localhost'a veya bulut meta veri adreslerine karşı kontrol edilmez. Bir yönetici bu nedenle rotayı örnek meta veri hizmetine yönlendirebilir ve döndürdüğü IAM kimlik bilgilerini okuyabilir.
IMDSv2'ye geçmek bunu durdurmaz. LiteLLM, x-pass- önekiyle gönderilen herhangi bir başlığın öneki kaldırılarak hedefe geçirildiğini belgeliyor ve Wiz IMDSv2'nin gerektirdiği başlıkları göndermek için bunu kullandı.
Hiçbir kaynak bunun gerçek bir dağıtımda yapıldığını bildirmiyor. Bu bir gösterimdir ve önce yönetici erişimi gerektirir.
Wiz, özelliğin amaçlandığı gibi çalıştığını savunuyor, çünkü LiteLLM'in tehdit modeli yöneticileri güvenilir olarak ele alır. Bunun bir CVE'si yok ve düzeltmesi yok.
Proje giriş yoluna dair aynı şeyi söylüyor. Yayınlanan güvenlik politikası, ana anahtar ayarlamama gibi bir kurulum hatası gerektiren saldırıları "açıkça kapsam dışı" olarak listeliyor ve güvenlik açığı olarak ele almıyor.
Koruyucu Ray Kusuru ve Tartışmalı Ciddiyet
Wiz raporundaki tek kod yürütme kusuru CVE-2026-59821'dir ve araştırmacılar ile bakımcılar bunu çok farklı şekilde tanımlıyor.
Wiz bunu kök düzeyinde kimlik doğrulama sonrası kod yürütme olarak adlandırıyor ve ağ geçidi konteyneri içinde uid=0(root) döndüren bir test gösteriyor. LiteLLM'in aynı CVE için yayınladığı danışma, bunu Düşük (CVSS ölçeğinde 2.1) olarak değerlendiriyor ve yüksek ayrıcalıklı bir hesap gerektiren bir kusur olarak tanımlıyor.
Her ikisi de aynı davranışı tanımlıyor. 1.82.0-stable'den önce, özel kod koruyucu raylarını oluşturan ve güncelleyen uç noktalar, test uç noktasının uyguladığı kum havuzu ve desen kontrollerini atlıyordu, böylece onlara ulaşabilen herkes konteyner içinde çalışan Python gönderebiliyordu.
Danışma, ana anahtar olmayan bir dağıtımda arayanların vekil yöneticiler olarak ele alındığını ekliyor; bu da bu uç noktaların erişilebilir olmasını sağladı.
Wiz raporu, 1.82.0'dan sonra varsayılan anahtara sahip bir saldırganın yalnızca kum havuzu içinde kod çalıştırabileceğini belirtiyor. LiteLLM'in kendi kaydı bunun her sürüm için geçerli olduğunu desteklemiyor.
Mayıs ayında yayınlanan ayrı bir danışma CVE-2026-40217, kum havuzundan bayt kodu teknikleri kullanılarak vekil işleminde kod çalıştırılarak kaçılabileceğini söylüyor; danışma vekilin varsayılan Docker imajında root olarak çalıştığını belirtiyor.
Bu, 1.81.8'den 1.83.10 hariç sürümleri kapsıyor ve uç noktaya ulaşmak için vekil-yönetici kimlik bilgisi gerekiyor. Ana anahtar bu kimlik bilgisidir.
Wiz'in bildirdiği her iki kusur da 9 Eylül tarihli raporundan aylar önce, Şubat ve Nisan'da düzeltildi ve CVE'leri Temmuz'da yayınlandı.
Ayrıca: Zaten Sömürülen LiteLLM Kusurları
Bunlar daha eski sorunlardır ve hiçbiri yukarıda anlatılan bulut kimlik bilgilerine giden yol değildir. Aynı ürünü etkiledikleri ve karıştırılması kolay olduğu için burada listelenmiştir.
CISA, 2 Eylül'de LiteLLM kusurundan birini Bilinen Sömürülen Güvenlik Açıkları kataloğuna ekledi. CVE-2026-59822 (CVSS puanı: 8.8), tek karakter uzunluğunda olan da dahil olmak üzere herhangi bir Bearer belirteciyle kimliği doğrulanmamış bir saldırganın geçerli bir MCP oturumu açmasına izin veriyor. Federal sivil kurumların 16 Eylül'e kadar ele alması gerekiyor.
Wiz, 7 Temmuz'dan itibaren kendi bal peteği sistemlerine karşı kullanıldığını gördü; istekler model listeleme uç noktalarını araştırmak için tek karakterli belirteçler taşıyordu. Wiz bunun başka bir kullanımını tanımlamadı.
Bu kusur yukarıdaki kod yürütme veya kimlik bilgisi yollarına ulaşmaz. Wiz bunun "yalnızca MCP sunucu erişimine izin verdiğini" belirtiyor. Erişilebilecek şey, bir kuruluşun hangi araç sunucularını bağladığına bağlıdır.
Saldırganların kod çalıştırmak için kullandığı LiteLLM kusuru farklıdır. CVE-2026-42271 (CVSS puanı: 8.7) herhangi bir doğrulanmış kullanıcının iki MCP test uç noktası üzerinden ana bilgisayarda komut çalıştırmasına izin veriyordu ve Horizon3.ai Haziran'da bunun Starlette host-header kusuru CVE-2026-48710 ile zincirlenerek hiçbir kimlik bilgisi olmadan aynı şeyi yapabileceğini bildirdi.
Wiz'in bal peteği sistemleri bu kusurun kripto para madencisi yüklemesi için kullanıldığını kaydetti.
Microsoft Ağustos ayında saldırganların bir LiteLLM ağ geçidi sürecinin içinde komut çalıştırdığını, konteynerin ortamından ana anahtarı, sağlayıcı anahtarlarını ve veritabanı bağlantı dizesini okuduğunu ve ardından bu dizede altta yatan PostgreSQL veritabanına erişip LiteLLM'in model ve sanal anahtar tablolarından kayıtları kopyaladığını bildirdi.
Microsoft, saldırganların erişimi yüksek güvenle açığa çıkan ağ geçidi üzerinden sağladığını değerlendiriyor ve giriş noktasının CVE-2026-42271 ve CVE-2026-48710 zinciriyle eşleştiğini söylüyor. Şirket "Yapay zeka ağ geçitlerini Tier-0 sır depoları olarak ele alın" dedi.
Şimdi Ne Yapılmalı
1.84.0 veya daha yeniye yükseltmek tablodaki her kusuru kapsar. Sürüm aralıkları danışmalarda belirtildiği gibidir.
Ne sağlar
MCP kimlik doğrulama atlama
Herhangi bir Bearer belirtecinden doğrulanmış bir MCP oturumu, bu örneğin yapılandırdığı MCP araçlarına ulaşır
CVE-2026-42271, MCP test uç noktası komut yürütme
Herhangi doğrulanmış kullanıcı ana bilgisayarda komut çalıştırır
1.74.2'den, ancak 1.83.7 hariç
özel kod koruyucu rayı kontrol atlama
Ağ geçidi konteyneri içinde kod yürütme
koruyucu ray kum havuzu kaçışı
Varsayılan konteyner imajında root olarak kod yürütme
1.81.8'den, ancak 1.83.10 hariç
1.83.10, danışma metni 1.83.11 diyor
Ana anahtarı sk-1234'ten uzun rastgele bir değere değiştirin. Bu yükseltme gerektirmez. Önce ayrı bir tuz anahtarının ayarlanıp ayarlanmadığını kontrol edin, çünkü döndürme prosedürü farklıdır ve yanlış olanı kullanmak saklanan kimlik bilgilerinin okunamaz kalmasına neden olabilir.
1.84.0 veya daha yeniye yükseltin. Bu sürüm tablodaki her kusurun düzeltilmiş sürümünün üzerindedir.
Henüz yükseltme yapamıyorsanız, /mcp/ ve iki MCP test uç noktasını, POST /mcp-rest/test/connection ve POST /mcp-rest/test/tools/list'i ters proxy veya API ağ geçidinizde engelleyin.
Ayrıca POST /guardrails/test_custom_code'u engelleyin ve POST /guardrails ve PUT /guardrails/{guardrail_id} isteklerini yöneticilerle sınırlayın. Bunlar LiteLLM'in kendi danışmalarındaki geçici çözümlerdir.
Ağ geçidindeki geçit uç noktalarını gözden geçirin, konteynerin dış ağ erişimini kısıtlayın ve iş yüküne çalışabilmesi için en dar bulut IAM rolünü verin.
Bir saldırganın erişimi olmuş olabileceğini düşünüyorsanız, oluşturmadığınız girdiler için koruyucu raylar listesini gözden geçirin ve bellekte tutulan kodu temizlemek için süreci yeniden başlatın, ardından sağlayıcı anahtarlarını, ana anahtarı ve veritabanı kimlik bilgilerini döndürün. Yükseltme, saldırganın kaydettiği bir koruyucu rayı veya eklediği bir SSH anahtarını kaldırmaz.
Örnek meta veriye geçit rotası için yama yok, çünkü LiteLLM bunu bir kusur olarak ele almıyor. Dış ağ sınırları ve dar IAM rolleri mevcut tek kontrollerdir.
MCP veya geçit rotalarının devraldığınız bir ağ geçidinde etkin olup olmadığını nasıl kontrol edeceğinizi hiçbir kaynak açıklamıyor. Microsoft'un avcılık sorguları yapılandırmayı değil sömürüyü bulur.
