Kendi dil modellerini sunucuda barındıran ekipler için bu haftanın en acil uyarılarından biri LMDeploy’dan geldi. InternLM’in çıkarım (inference) ve ağırlık güncelleme çerçevesinde bulunan açık, CVE-2026-119706 koduyla izleniyor ve CVSS ölçeğinde 9.8 puanla kritik seviyede. GitHub güvenlik danışma kaydına göre etkilenen sürüm aralığı 0.9.0 ile 0.18.0 arası; hem TurboMind hem de PyTorch arka uçları kapsama giriyor. Kasım başı itibarıyla kalıcı pickle engeli için açılan PR #4964 henüz birleşmiş değil; yani tehdit yamasız kabul ediliyor.
Açığın özü tehlikeli derecede basit: /update_weights HTTP uç noktası, istek gövdesindeki serialized_named_tensors alanından gelen base64 kodlu veriyi çözüp Python’un ForkingPickler.loads işleviyle yükliyor. Pickle, serileştirilmiş nesneleri geri yüklerken keyfi kod çalıştırabilir. Kimlik doğrulama zorunlu olmadığında bu, internetten gelen tek bir istekle sunucuda uzaktan kod çalıştırma (RCE) demektir. Zayıflık sınıfı CWE-502 (güvenli olmayan deserileştirme) altında yer alıyor.
LMDeploy neden yaygın kullanılıyor?
LMDeploy, büyük dil modellerini yüksek performansla sunmak için kullanılan açık kaynak bir araç seti. Özellikle GPU’lu sunucularda model ağırlıklarını yüklemek, güncellemek ve API üzerinden çıkarım hizmeti vermek için tercih ediliyor. TurboMind arka ucu hız odaklı üretim senaryolarında, PyTorch arka ucu ise esneklik ve araştırma kurulumlarında öne çıkıyor. Bu da açığın yalnızca “deneysel bir demo”yu değil, gerçek model API’lerini etkileyebileceği anlamına geliyor. Bir araştırma kümesinde veya şirket içi LLM servisinde unutulmuş bir /update_weights yolu, tüm makineyi riske atabilir.
/update_weights neden bu kadar tehlikeli?
Ağırlık güncelleme uç noktası, çalışan bir modele yeni tensörler enjekte etmek için tasarlanmış. Güvenli bir tasarımda bu işlem sıkı kimlik doğrulama, imzalı artefaktlar ve güvenilir iç ağ ile sınırlanır. LMDeploy’daki sorunlu akışta ise istemci base64 pickle gönderiyor; sunucu bunu doğrudan loads ile açıyor. Saldırgan, pickle içine zararlı bir nesne gömdüğünde deserileştirme anında kendi kodu çalışıyor.
Durumu daha da ağırlaştıran varsayılanlar var. Danışma kaydına göre api_server varsayılan olarak 0.0.0.0 üzerinde dinliyor, yani tüm ağ arayüzlerinden bağlantı kabul edebiliyor; api_keys=None olduğunda da kimlik doğrulama fiilen kapalı. Sonuç: İnternete açık bırakılmış bir LMDeploy örneği, parola sormadan kritik RCE’ye yataklık edebilir. CVSS 9.8 puanı da büyük ölçüde bu “kimlik doğrulamasız + ağdan erişilebilir + kod çalıştırma” üçlüsünden geliyor.
Saldırgan ne kazanır?
Kimlik doğrulamasız RCE, model API’sini “yanlış yanıt ürettirme” seviyesinde bırakmaz. Saldırgan sunucu sürecinin yetkileriyle:
- Sistemde istediği komutu çalıştırabilir,
- Model ağırlıklarını, yapılandırmayı ve ortam değişkenlerindeki sırları okuyabilir,
- Kripto madenciliği, arka kapı veya yanal hareket için kalıcılık kurabilir,
- Aynı makinedeki diğer hizmetlere veya bulut meta veri uçlarına uzanabilir.
GPU’lu makinelerin maliyeti ve üzerindeki modellerin değeri düşünüldüğünde, bu tür uç noktalar tarama botlarının da radarına hızla girer. “İç ağdayız” varsayımı, yanlışlıkla 0.0.0.0 ve kimlik doğrulamasız API ile birleştiğinde geçersizleşir. Özellikle konteyner veya bulut GPU örneklerinde varsayılan portların dışarı açılması sık görülen bir yapılandırma hatasıdır.
Yama durumu ve geçici önlemler
Kalıcı düzeltme olarak pickle tabanlı yüklemeyi engelleyen veya güvenli bir formata geçiren değişiklik PR #4964 ile takip ediliyor; Kasım başı itibarıyla PR açık ve birleşmiş değil. Bu yüzden işletmeler yama beklerken riski azaltmak zorunda. InternLM LMDeploy projesi ve güvenlik danışma kaydıyla uyumlu pratik adımlar:
- /update_weights uç noktasına dışarıdan erişimi hemen kesin; güvenlik duvarı veya ters vekil ile yalnızca güvenilir iç kaynaklara açın.
- api_keys değerini zorunlu kılın; None veya boş bırakılmış kurulumları kabul etmeyin.
- api_server’ı mümkünse yalnızca localhost veya özel bir iç IP’de dinletin; 0.0.0.0 varsayılanını gözden geçirin.
- Web sunucusu ve uygulama loglarında /update_weights isteklerini izleyin; beklenmeyen base64 gövdeleri alarm nedenidir.
- 0.9.0–0.18.0 aralığındaki sürümleri envantere yazın; PR birleşip sürüm çıkınca gecikmeden yükseltin.
Pickle + HTTP = tekrarlayan kritik desen
Python ekosisteminde pickle’ın HTTP üzerinden kabul edilmesi, yıllardır kritik RCE’lerin klasik kalıplarından biri. Yapay zekâ altyapısında tensör ve checkpoint taşırken pickle hâlâ “hızlı ve kolay” göründüğü için benzer uç noktalar yeniden ortaya çıkıyor. LMDeploy örneği, model sunucularının da web uygulamaları gibi tehdit modeline alınması gerektiğini gösteriyor: Kimlik doğrulama, ağ maruziyeti ve güvenli serileştirme formatı varsayılan olmalı; “zaten içerdeyiz” varsayımı belgeye yazılmamalı.
Kendi modellerini barındıran ekipler için özet net: CVE-2026-119706 yamasız ve kritik. /update_weights’i kilitleyin, api_keys zorunlu tutun, ağı daraltın ve PR #4964 sonrası resmi sürümü izleyin. Aksi halde model API’niz, internete açık bir uzaktan kod çalıştırma kapısına dönüşebilir. Kritik puanlı ve yamasız bir açıkta “yarın bakarız” yaklaşımı, tarayıcıların bugün bakmasıyla aynı kapıya çıkar.
Envanter ve izleme neden acil?
CVE-2026-119706’nın yamasız olması, geçici kontrolleri “isteğe bağlı” olmaktan çıkarıyor. GPU’lu çıkarım sunucuları tarama botları için yüksek değerli hedefler; /update_weights gibi seyrek kullanılan yönetim uçları ise çoğu zaman ters vekil kurallarında unutuluyor. Ekiplerin önce hangi LMDeploy sürümünün nerede çalıştığını bilmesi, ardından bu ucu ağdan düşürmesi ve api_keys zorunluluğunu doğrulaması gerekiyor. PR #4964 birleşene kadar izleme de şart: Beklenmeyen ağırlık güncelleme istekleri, başarılı bir sömürüden önce gelen keşif trafiğinin işareti olabilir.
Kaynak: GitHub güvenlik danışma kaydı, InternLM LMDeploy projesi
