vLLM'de 10 yeni CVE: SSRF, motor çökmeleri, düzeltilen sürümler

vLLM çalıştırıyorsanız ve ona tam güvenmediğiniz birileri erişebiliyorsa, sürümünüzü bugün kontrol edin. GitHub’ın advisory veritabanına 25 Ekim’de vLLM için her biri CVE numaralı on kayıt, 23 Ekim’de de iki kayıt daha eklendi. vLLM projesinin kendi advisory’lerini, GitHub’ın kayıtlarını ve 0.31.0 ile 0.32.0 sürüm notlarını okuduk. Bu yazıda açıkların ne olduğu, hangi sürümün neyi düzelttiği, kimlerin gerçekten risk altında olduğu, yükseltmeden önce neler yapılabileceği ve doğrulayamadıklarımız var. Hiçbirini çalıştırmadık, bir açığın nasıl tetiklendiğine dair teknik ayrıntıyı da bilerek dışarıda bırakıyoruz.

Ne yayımlandı, ne zaman?

Zaten kamuya açık advisory’ler için on CVE kaydı, 25 Ekim’de. GitHub’ın “incelenmemiş” olarak işaretlediği kayıtlar 15:32 UTC’de eklendi ve CVE-2026-116172’den CVE-2026-116181’e kadar numara taşıyor. Her biri 9 Ekim tarihli bir vLLM advisory’sine işaret ediyor. İncelenmiş iki kayıt, CVE-2026-114050 ve CVE-2026-114055, 6 Ekim tarihli advisory’ler için 23 Ekim’de eklendi. Açtığımız vLLM advisory sayfalarında “No known CVE” yazıyor, yayımlayan ve koordinatör olarak aynı GitHub hesabı görünüyor, dışarıdan bildirenler ise advisory başına anılıyor: SSRF için mschwarzl, logprobs çökmesi için mcgrof, çok kipli kwargs sorunu için Chedrian07, video sorunu için tonghuaroot. Yani haber yeni bir ifşadan çok, CVE numaraları ve bunların getirdiği tarayıcı kapsamı.

Hangi sürüm neyi düzeltiyor?

Her açığı düzelten ilk sürüme göre gruplandı. Başka bir şey belirtilmedikçe derecelendirmeler GitHub’ın kayıtlarından.

• 0.24.0 (29 Haziran):
  • İstek kimliği başlığı üzerinden SSRF (CVE-2026-116176, 8,2; vLLM sayfasında High): bir prefill worker P2pNcclConnector çalıştırıyorsa 0.9.2’den 0.24.0’a kadar etkileniyor.
  • Üç Rust gRPC frontend açığı (CVE-2026-116172, -116173, -116174, her biri 5,9): hazırlanmış Generate ya da GenerateStream istekleri motor çekirdeğini sonlandırabiliyor. 0.22.0’dan 0.24.0’a kadar etkileniyor.
  • Dekompresyon bombası sınırını atlayan ses çözme (CVE-2026-116175, 6,5): küçük sıkıştırılmış bir ses dosyası sunucu belleğini tüketebiliyor. 0.19.0’dan 0.24.0’a kadar etkileniyor.
• 0.25.0: Nemotron-VL görüntü işlemcileri Pillow’un dekompresyon bombası korumasını tüm süreç için kapatıyor (CVE-2026-116177, 7,5). Etkilenen aralık kaynaklara göre farklı: vLLM sayfası 0.8.5’e kadar diyor, GitHub kaydı 0.10.2’den 0.25.0’a kadar.
• 0.29.0: kelime dağarcığı dışındaki stop_token_ids motoru çökertebiliyor ya da logits tamponunun dışına yazabiliyor (CVE-2026-116181, 6,5). 0.20.1’den 0.29.0’a kadar etkileniyor.
• 0.30.0: disaggregated /inference/v1/generate endpoint’ine tutarsız çok kipli metadata gönderilmesi motoru çökertiyor (CVE-2026-116178, 5,9). 0.20.0’dan 0.30.0’a kadar etkileniyor.
• 0.31.0:
  • Video kare sayısı sınırının atlanması (CVE-2026-116179, 7,5): büyük bir satır içi video API frontend’inin belleğini tüketebiliyor. 0.18.0’dan 0.31.0’a kadar etkileniyor.
  • İlklenmemiş logprobs belleğinden kiracılar arası çökme (CVE-2026-116180, 7,7): bir KV connector gerektiriyor.
  • Sahte çok kipli UUID’lerin işlemci önbelleklerini senkron dışı bırakması (CVE-2026-114050, 6,5): tüm motoru çökertiyor. 0.31.0 öncesi sürümler etkileniyor.
  • Doğrulanmayan istek başına mm_processor_kwargs (CVE-2026-114055, 7,5): kaynak tüketimine yol açabiliyor. 0.7.3’ten 0.31.0’a kadar etkileniyor.
• 0.32.0 (18 Ekim): 20 Ekim tarihli iki advisory: CUDA assert tetikleyen kelime dağarcığı dışı bir prompt token kimliği ve P2P offloading yolunda ZeroMQ soket tükenmesi (yalnızca 0.26.0). İkisi için de CVE bulamadık.

Kimler gerçekten risk altında?

vLLM’i kontrol etmediği istemcilere sunan herkes, özellikle paylaşımlı kurulumlar. Açıkların çoğu motorun çökmesiyle bitiyor ve logprobs advisory’si, bir çökmenin yalnızca gönderenin değil uçuştaki bütün istekleri düşürdüğünü not ediyor. Ama birkaçı belirli bir kurulum gerektiriyor:

• SSRF: yalnızca P2pNcclConnector KV-transfer connector’ını çalıştıran prefill worker’lar. Advisory, böyle bir worker’a erişebilen bir API çağıranın o isteğin prompt metnini barındıran KV-cache’ini dışarı gönderebileceğini ve worker’ı bloke edebileceğini söylüyor.
• Logprobs çökmesi: KV connector olan bir motor, örneğin prefix caching kurulumu. Advisory en olası gerçek dünya durumu olarak vLLM ile LMCache üzerinde değerlendirme iş yüklerini anıyor.
• Rust gRPC üçlüsü ve disaggregated endpoint: yalnızca bu frontend’leri dışarı açtıysanız.
• Çok kipli olanlar: yalnızca çok kipli modellerde ve endpoint’lerde. Bir advisory, vLLM’in API anahtarının isteğe bağlı olduğunu, yani önünde kimlik doğrulama katmanı olmayan bir kurulumun ayrıcalıksız erişilebildiğini not ediyor.

Yalnızca kendi güvendiğiniz servislerin eriştiği bir vLLM örneği daha küçük bir sorun, ama sıfır değil.

Yükseltmenin dışında ne yapabilirsiniz?

0.32.0 veya üstüne yükseltin, ama yaymadan önce sürüm notlarını okuyun. İzlenecek kırıcı değişiklik 0.31.0’da: istek başına mm_processor_kwargs ve media_io_kwargs, sunucu --trust-request-mm-kwargs ile başlatılmadıkça artık reddediliyor. Bunları gönderen istemciler hata almaya başlayacak.

Yükseltene kadar advisory’lerin önerdiği geçici önlemler:

• Logprobs çökmesi: KV connector’ı kaldırın (--kv-transfer-config ayarını silin) ya da vLLM’in önündeki bir geçitte gelen isteklerden prompt_logprobs, logprobs ve echo alanlarını çıkarın.
• İstek başına çok kipli kwargs: API katmanında boş olmayan mm_processor_kwargs değerlerini reddedin, geçersiz kılmayı yalnızca güvenilir istemciler için açık bırakın.
• SSRF: advisory’nin kendi düzeltmesi, kullanıcının verdiği istek kimliklerinin connector’a ulaşmasını engellemek. Okuduğumuz metinde bir yapılandırma çözümü görmedik; dışarıdaki çağıranların erişebildiği her yerden bu connector’ı kaldırmak bariz bir geçici adım, ama bu bizim okumamız.

Henüz bilinmeyenler neler?

• İstismar. Bunlardan hiçbirinin sahada kullanıldığına dair bir bildirim bulamadık ve hiçbir kaynak bunu iddia etmiyor.
• CVE kayıtlarının değişip değişmeyeceği. GitHub 25 Ekim grubunu incelenmemiş olarak işaretliyor, bu yüzden derecelendirmeler ve etkilenen aralıklar revize edilebilir; Nemotron-VL’deki fark bunu zaten düşündürüyor.
• 20 Ekim tarihli iki advisory. Aramamızda henüz CVE çıkmadı.
• Gerçek dünyadaki maruziyet. Kaç kurulumun KV connector ya da Rust frontend çalıştırdığına dair verimiz yok.

Akılda tutulacaklar

Bunlar bizim gözlemlerimiz:

• CVE numaraları düzeltmelerden sonra geldi. SSRF düzeltmesi 29 Haziran’da 0.24.0 ile çıktı, advisory’si 9 Ekim tarihli; hesabımıza göre 102 gün sonra. Güvenlik açıklarını CVE ile izleyen ekipler kayıtlar görünene kadar bunları kaçırmış olabilir; bu hafta taramaları yeniden çalıştırmaya değer.
• Bunların çoğu, paylaşılan bir motorda erişilebilirlik sorunu. Tek bir bozuk istek başka kiracıların işini düşürebiliyor; bu yüzden vLLM’in önündeki istek doğrulaması ve geçit sınırları tek bir yamadan daha değerli.
• Pillow’u ayrıca kontrol edin. vLLM 0.32.0 Pillow alt sınırını 12.3.0’a yükseltti; ama okuduğumuz Pillow advisory’si (GHSA-5x8w-8jj5-q52h, isteğe bağlı olefile paketini gerektiren bir FlashPix çözme açığı) 12.3.0’ı hâlâ etkilenen, 13.0.0’ı düzeltme olarak listeliyor. İmajlarınızda olefile olup olmadığına bakmadık.
• Açıkta duran bir çıkarım sunucusu da başka bir servis gibi. Railway raporumuz ve Brotli yazımız paylaşılan bir bileşenin sessizce risk taşıdığı aynı örüntüyü gösteriyor.

Editoryal inceleme: 25 Ekim 2026 (AI). vLLM projesinin GitHub advisory’leri (SSRF, logprobs çökmesi, çok kipli kwargs ve video kare sayısı sorunlarının sayfaları baştan sona; diğerlerinin başlık ve açılış özetleri okundu), GitHub’ın CVE-2026-116172 - CVE-2026-116181 advisory kayıtları (GitHub API) ve vLLM 0.31.0 ile 0.32.0 sürüm notları üzerinden hazırlandı. vLLM’i çalıştırmadık, hiçbir sorunu yeniden üretmedik ve projeyle iletişime geçmedik. Derecelendirmeler kayıtlarda görünenlerdir ve değişebilir. Kayıtlar ve sayfalar okumamızdan sonra değişmiş olabilir.