· kaynak dev.to (home feed)
LiteLLM proxy'deki kritik açık, düşük yetkili kullanıcıların admin ve RCE'ye yükselmesine izin veriyor
LiteLLM'ın proxy'sindeki CVSS 9.9 puanlı bir güvenlik açığı, kimliği doğrulanmış herhangi bir düşük yetkili kullanıcının sahte bir admin oturum token'ı üretip uzaktan kod çalıştırmasına olanak tanıyor. Etkilenen tüm dallar için yamalı sürümler yayınlandı.

LiteLLM proxy'de kritik güvenlik açığı
CVE-2026-114612 olarak takip edilen ve CVSS v3.1 ölçeğinde 10 üzerinden 9.9 puan alan bir güvenlik açığı, LiteLLM proxy sunucusundaki kimliği doğrulanmış herhangi bir düşük yetkili hesabın tam yönetici kontrolünü ele geçirmesine ve ardından sunucuda komut çalıştırmasına olanak tanıyor. dev.to'da yayınlanan bir güvenlik raporuna göre 1.87.0'dan 1.104.0-rc.1'e kadar tüm sürümler ile Chainguard'ın LiteLLM container imajları etkileniyor.
BerriAI tarafından geliştirilen ve birçok AI yığınında büyük dil modeli API'lerinin önünde duran açık kaynak proxy LiteLLM, bu nedenle güvenilmeyen bir kullanıcının en temel bir iç hesaba bile sahip olduğu her yerde riske açık durumda.
Token karışıklığı nasıl işliyor
Rapor, hatanın tek bir AES-256-GCM şifreleme bağlamı ve anahtar türetme yolunun birbiriyle ilgisiz iki özellik tarafından paylaşılmasına dayandığını ortaya koyuyor: metadata alanlarında saklanan secret'ların şifrelenmesi ve web arayüzü ile CLI'yı doğrulayan kısa ömürlü oturum token'larının üretilmesi. İki amaç da ciphertext'e Associated Authenticated Data olarak bağlanmadığı için proxy, şifrelenmiş bir metadata blob'u ile şifrelenmiş bir yönetici oturumunu ayırt edemiyor — ikisi de aynı anahtar ve aynı yapı ile mühürleniyor.
Bu simetri, sıradan bir API çağrısını bir şifreleme oracle'ına dönüştürüyor. İç kullanıcı kimlik bilgilerine sahip bir saldırgan, proxy'den bir API anahtarı üretmesini isterken, kullanıcı tarafından yazılabilir bir şifreli alanın içine (raporda örnek olarak Langfuse secret anahtarı yuvası gösteriliyor) admin oturumunu taklit eden elle hazırlanmış bir JSON gizliyor. Proxy bu yükü şifreleyip ciphertext'i geri veriyor. Saldırgan bu dizgiyi daha sonra bir HTTP Bearer token olarak yeniden gönderiyor ve proxy bunu geçerli bir yönetici girişi olarak kabul ediyor. Rapora göre buradan uzaktan komut çalıştırmaya, Model Context Protocol'ün stdio transport'u üzerinden ulaşmak mümkün.
Sorun CWE-269, CWE-345 ve CWE-441 altında kayıtlı. İstismar bariz şekilde pratik: projenin kendi uçtan uca regresyon testi, anahtar üretim uç noktasından kullanıcı listeleme uç noktasına yeniden oynatmaya kadar tüm zinciri gerçekleştiriyor. Rapor tarihinde EPSS yüzde 0.24'tü ve açık henüz CISA'nın Known Exploited Vulnerabilities kataloğunda listelenmemişti.
Her dalda düzeltme mevcut
1d5fdc8 numaralı yama commit'i, oturum token'larına özel bir mühürlü biçim getiriyor: artık token amacı AAD olarak kodlanarak şifreleniyor ve litellm_login_ önekiyle donatılıyor; şifre çözme işlemi bu önek olmayan her şeyi reddediyor, böylece metadata saklama için üretilmiş bir ciphertext artık oturum açma amacıyla kullanılamıyor. Düzeltme tüm bakım dallarına geri taşındı ve 1.100.4, 1.101.3, 1.102.2, 1.103.1 ile 1.104.0-rc.2 yamalı sürümleri ortaya çıktı. Rapor ayrıca GitHub Security Advisory GHSA-7hp6-4w63-5g45 kaydına ve CVE'nin NVD kaydına da değiniyor.
Sıkılaştırma ve temizlik adımları
Hemen yükseltme yapamayan ekipler için rapor, geçici önlemler öneriyor: v2:gcm: veya litellm_enc:: önekleri içeren Authorization header'larını reddeden WAF ya da reverse-proxy kuralları, üretimde MCP stdio transport'unun devre dışı bırakılması (böylece admin erişimi sunucuda komut çalıştırmaya dönüşemez) ve eski 1.87.0 ile 1.90.x dağıtımlarında deneysel UI girişinin kapatılması.
Yamalama sonrasında operatörlere, ortamlardaki tüm LiteLLM proxy ve container imajlarının envanterini çıkarmaları, metadata.logging[].callback_vars içinde beklenmedik JSON taşıyan API anahtarları için LiteLLM_VerificationToken tablosunu denetlemeleri (bu, birinin saldırıyı hazırladığının işaretidir) ve güvenilmeyen kullanıcıların yamalanmamış bir örnek üzerinde iç erişimi olduğu her yerde hem proxy MASTER_KEY hem de LITELLM_SALT_KEY anahtarlarını döndürmeleri tavsiye ediliyor.
Neden önemli
Bu, yeni bir istismar ilkesine ihtiyaç duyulan egzotik bir zero-day değil — bir kuruluşun kullandığı her model sağlayıcı kimlik bilgisini tutan bir ağ geçidinin tam kontrolünü tek bir HTTP header'ına dönüştüren düşük yetkili bir hesap. Temeldeki hata, hiçbir bağlam bağlaması olmadan bir anahtarı ve şifreyi iki amaç için yeniden kullanmak; bu, diğer self-hosted altyapı projelerinin de taşıyabileceği klasik bir alan ayrımı (domain separation) başarısızlığı ve bu yüzden LiteLLM ekosisteminin ötesinde incelenmeye değer. Ayrıca kavram kanıtı resmî bir regresyon testi olarak geliyor, bu yüzden güncel EPSS puanı düşük olsa da onu tekrarlamak için gereken çaba minimal. Zamanında yamalamak ucuz; alternatifi ise ağ geçidinin hiç dokunduğu tüm secret'ları döndürmek.
- #security
- #litellm
- #ai-gateway
- #vulnerability
- #encryption
İlgili yazılar
- MLflow'un webhook endpoint'indeki kimlik doğrulaması eksik SSRF, model registry'lerin arkasındaki iç ağları açığa çıkarıyor
- CVE-2026-109869: uzak sunucular, yetim kalan undici stream üzerinden Node.js fetch'i çökertebiliyor
- CBP verilerine göre ABD sınırında telefon ve dizüstü bilgisayar aramaları bu yıl yüzde 32 arttı