deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

LiteLLM MCP kimlik doğrulama atlama CISA'nın istismar listesine girdi; düzeltme için 1.84.0 gerekiyor, 1.83.9 yetmiyor

CISA'nın istismar edilen zafiyet kataloğuna, herhangi bir bearer token'ı kabul eden bir LiteLLM MCP açığı eklendi. Açığı yalnızca LiteLLM 1.84.0 kapatıyor; yaygın olarak önerilen 1.83.9 ise atlamayı açık bırakıyor.

LiteLLM MCP kimlik doğrulama atlama CISA'nın istismar listesine girdi; düzeltme için 1.84.0 gerekiyor, 1.83.9 yetmiyor

CISA, LiteLLM'ün MCP uç noktasındaki bir kimlik doğrulama atlama zafiyeti olan CVE-2026-59822'yi 2 Eylül 2026'da Bilinen İstismar Edilen Zafiyetler kataloğuna ekledi; bu listeye girmek, saldırganlar tarafından kullanıldığının doğrulandığına işaret eder. dev.to'da yayımlanan (ilk olarak mcpscore.dev'de yayınlanan) bir yazıya göre açık, bir bearer token taşıyan her isteği geçiryordu — token'ın geçerli olması gerekmiyordu — ve yalnızca LiteLLM 1.84.0'da kapatıldı.

Atlama nasıl çalışıyordu

LiteLLM, uygulamalar ile model sağlayıcılarının ve agent'lar ile MCP sunucularının arasında yer alır. MCP uç noktası, Authorization başlığını LiteLLM'ün kendi API anahtarlarına karşı doğrular. Bazı yukarı akış MCP sunucuları — örnek olarak Atlassian gösteriliyor — aynı başlıkta kendi OAuth token'larını beklediği için LiteLLM bir geri dönüş mekanizması ekledi: başlık bir LiteLLM anahtarıyla eşleşmediğinde, değeri yukarı akış token'ı olarak değerlendirip iletiyordu.

Bu geri dönüş, yalnızca OAuth için yapılandırılmış sunucular için değil, her sunucu için çalışıyordu. Fiili olarak, başarısız bir anahtar denetimi reddetmek yerine anonim bir oturum üretiyordu; böylece uydurma bir başlık, ağ geçidinden erişilebilen her aracı listeleyip çağırabiliyordu. 1.84.0'daki düzeltme, geri dönüşü yalnızca isteğin hedeflediği tüm sunucular OAuth için yapılandırılmışsa uyguluyor ve hedef bilinmiyorsa isteği reddediyor.

Neden 1.83.9'a yükseltmek yetmiyor

Ekim ayında iki başka LiteLLM zafiyetinin — 1.83.9'da düzeltilen user_config üzerinden bir server-side request forgery olan CVE-2026-59823 ve 1.83.0'da düzeltilen config uç noktası üzerinden bir yetki yükseltmesi olan CVE-2026-35029 — haberciliği, en az 1.83.9'a yükseltme tavsiyesini yaygınlaştırdı. dev.to'daki yazıya göre bu tavsiye MCP atlamasını açık bırakıyor: CVE-2026-59822, 1.84.0'dan önceki her sürümü etkiliyor; yani 1.83.9 ile 1.83.14 arasındaki sürümler hâlâ açıkta. Ayrıca üç zafiyetten CISA kataloğunda yer alan tek zafiyet bu.

Belirtim net

MCP yetkilendirme belirtimi, 18 Haziran 2025 sürümünden beri ve 28 Temmuz 2026 revizyonunda değişmeden, geçersiz veya süresi dolmuş token'lara HTTP 401 yanıtı verilmesini zorunlu kılıyor. Hiç hiçbir zaman yayınlamadığı bir token taşıyan bir isteğe başarıyla yanıt veren bir sunucu, yalnızca yanlış bir durum kodu seçmiş değildir: kimlik doğrulama denetimi ya hiç çalışmamıştır ya da çalışıp yok sayılmıştır. Neden sunucunun içindedir ama belirti hat üzerinde görülebilir.

Tek isteklik bir denetim

mcpscore 1.25.0, tam olarak bu gözleme dayanan auth_invalid_token_rejected kuralını içeriyor. Sabit bir ön ek ile rastgele bir UUID'den oluşan uydurma bir bearer token'la bir tools/list isteği gönderiyor. Herhangi bir 2xx yanıtı kuralı yüksek önem derecesiyle düşürüyor. 401 veya 403 geçer; RFC 6750 uyarınca WWW-Authenticate başlığında error="invalid_token" taşıyan başka bir 4xx de geçer — GitHub Copilot'un MCP sunucusu hatalı biçimli token'ları 400 ile reddettiği için eklenen bir istisna. 404, yönlendirme, hız sınırı veya 5xx gibi diğer her şey atlanıyor. Denetim salt okunur: tools/call göndermiyor, token'la yönlendirmeyi hiçbir zaman izlemiyor ve sunucunun açtığı her oturumu yine de kapatıyor.

mcpscore ekibi, sürüm öncesinde kuralı Asana, Linear, Notion, Sentry, Stripe ve GitHub Copilot dahil kimlik doğrulamalı üretim sunucularında çalıştırdığını söylüyor; hepsi uydurma token'ı reddetti.

Denetimin sınırları var. Bir sunucu, başka bir hizmet için üretilmiş gerçek bir token'ı kabul etmeye, istemci token'larını yukarı akış API'sine iletmeye veya token'ın taşıdığından daha fazla kapsam vermeye devam edebilir — belirtim üçünü de yasaklıyor ve hiçbiri dışarıdan görülemiyor, dolayısıyla bunları yakalamak kod incelemesi ve ağ geçidi politikası gerektiriyor. Kural ayrıca bir taban ret yanıtı gerektiriyor: token'sız bir isteğe 401 sorgusu yerine 500 yanıt veren bir sunucu test edilemez.

Neden önemli

Bu hata LiteLLM'den daha büyük. Başarısız bir kimlik doğrulama denetiminin sessizce varsayılan bir kimliğe dönüşmesi başarısızlık biçimi, herhangi bir MCP sunucusunun yayımlayabileceği bir şey ve belirtimin 401 gerekliliği buna kesin, dışarıdan test edilebilir bir imza veriyor. Ağ geçitleri riski katlıyor: tek bir kimlik doğrulama yolundaki tek bir geri dönüş, arkasına bağlı tüm MCP sunucularını ve bu sunucuların eriştiği hizmetleri bir kerede açığa çıkardı. LLM ve MCP ağ geçitlerine, fiilen dönüştükleri kimlik altyapısı gibi davranın — danışmanlık belgeleri yayımlandığında yamalayın, zorunlu değilse genel internetten uzak tutun ve ağ geçidini geçen bir isteğin arkasındaki sunucu tarafından yine de reddedildiğinden emin olun. Yeni mcpscore kuralı, OWASP MCP Top 10'daki yetersiz kimlik doğrulama maddesi MCP07'nin bir bölümünü kapsıyor.

  • #litellm
  • #mcp
  • #security
  • #authentication
  • #cisa

İlgili yazılar