Yamalanmamış, 9.8 puanlı LMCache açığı, kimliği doğrulanmamış ZeroMQ mesajlarıyla kod çalıştırılmasına izin veriyor

JFrog, 7 Ekim 2026'da, LMCache'in cache sunucusunu etkileyen ve 9.8 olarak derecelendirilmiş kritik bir uzaktan kod yürütme açığı olan CVE-2026-105192'yi duyurdu. LMCache, LLM attention key-value cache'lerini model süreci dışında saklayan bir katmandır; böylece uzun prompt'lar ve yeniden başlatılan motorlar prefill maliyetini iki kez ödemez. dev.to'daki bir yazıya göre, bu sunucuya gönderilen tek bir kimliği doğrulanmamış mesaj, LMCache sürecinin ayrıcalıklarıyla kod çalıştırmak için yeterli; üstelik projenin resmi container imajları bu süreci root olarak çalıştırıyor. Düzeltilmiş bir sürüm yok.

Açık nasıl çalışıyor

LMCache'in çok süreçli modu — dokümantasyonda dağıtık mod olarak da geçiyor — worker süreçlerinin kaydolup KV cache bloklarını paylaşabilmesi için bir ZeroMQ ROUTER socket'i açıyor. Bu socket kimlik doğrulaması gerektirmiyor. Mesajlar msgpack ile kodlanmış olarak geliyor ve sunucu, mesajın argümanlarını hâlâ ayrıştırırken — yani o mesaj tipinin handler'ı hiç çalışmadan önce — extension kodlarından biri, Python'un pickle kütüphanesini çağıran bir deserializer'a veriliyor.

Bu sıralamanın kendisi açığın tamamı. Pickle payload'ları serileştirme açma sırasında çalıştırıldığı için kod, gelen mesajın türünü inceleyen herhangi bir şey devreye girmeden yürüyor. dev.to'nun aktardığına göre JFrog kaydı, varsayılan transport portunu 5555 olarak veriyor ve bu porta gönderilen tek bir ZeroMQ DEALER mesajı yeterli.

Etkilenen aralık, çok süreçli ZMQ transport'unu ve pickle tabanlı extension'ını Ekim 2025'te kullanıma sokan 0.3.9 sürümüyle başlıyor ve güncel stabil sürüm olan 0.5.5'e kadar uzanıyor. 0.5.6 sürüm adayları ve geliştirme dalı da aynı açığı taşıyor.

Dokümante edilmiş dağıtım, açık olan dağıtım

Varsayılan olarak cache sunucusu loopback'e bağlanır; bu da diğer host'lardan erişilemez olmasını sağlar. Ortaya çıkış tek bir ayara bağlı: routable bir adres belirten operatörler — tam olarak çok düğümlü dağıtımların eşlerin cache'lenmiş blokları paylaşabilmesi için yaptığı şey — portu erişilebilir hale getiriyor.

LMCache'in kendi Kubernetes rehberi bilinçli olarak bu yapılandırmaya giriyor. Rehber, düğüm başına bir cache sunucusu çalıştıran, hostNetwork etkin şekilde birden fazla vLLM pod'u tarafından paylaşılan bir DaemonSet tarif ediyor; böylece model pod'ları sunucuya düğümün kendi adresi üzerinden ulaşabiliyor. Her arayüzde dinleyen bir sunucuyla birleşince, cache portu düğüme route edilebilen her şeye açık kalıyor. Aynı sayfa, motor tarafından yönlendirilen yol yüklendiğinde sunucu ile worker'lar arasındaki KV aktarımlarının varsayılan olarak pickle tabanlı bir yol kullandığını da doğruluyor.

dev.to'daki yazı, burada kimsenin bariz bir hata yapmadığını ileri sürüyor; sorun sıralamada. Süreç içi bir buffer olarak başlayan bir performans özelliği paylaşılan bir servise dönüştü, servis bir port edindi ve port, kimlik doğrulaması olmadan geldi.

Ekipler buna rağmen neden kullanıyor

Proje, ekstra süreç ve port için kendi gerekçesini yayımladı. Sekiz H100 GPU üzerinde Qwen3-235B-A22B-Instruct-2507-FP8 ile çok turlu sohbet iş yükü kullanan bir benchmark'ta, ilk token'a kadar geçen ortalama süre süreç içi offloading ile 3.98 saniyeden çok süreçli modda 0.29 saniyeye düştü; ortalama çözümleme (decoding) hızı da saniyede 9.81 tokendan 37.47 tokena çıktı.

Boyutlandırma bu kazanımlarla birlikte ölçekleniyor: Dokümantasyon, işletim sistemi ve model sunucusundan sonra kalan host belleğinin tamamının L1 cache'e verilmesini öneriyor; dokümante edilmiş bir örnek 60GB, bir benchmark çalışması ise 400GB. Bir düğümdeki bu kadar büyük bir havuz, kimse kimlik doğrulamasını tartışmaya başlamadan önce envanter kaydını hak ediyor.

Yamalık yokken izolasyon

JFrog'nun önerisi, sınırları açıkça belirtilmiş ağ işi: çok süreçli sunucuyu routable adreslerden uzak tutun ve portunu loopback'te ya da güvenilir bir cluster ağında tutun. Porta kimlerin erişebildiğini kısıtlayan bir firewall riski azaltır; ancak CVE kaydı bunun riski ortadan kaldırmadığını açıkça belirtiyor, çünkü bağlantı açabilen her host kod çalıştırabilir.

Tespit de çözümsüz. Ne CVE kaydı ne de JFrog'nun duyurusu daha önce ihlal edilmişliğe dair bir gösterge sunuyor; bu yüzden log incelemesi doğrudan socket'ten başlıyor: hangi adresler cache portuna ne zaman bağlandı.

Adlandırılması gereken bir sürüm tuzağı da var. İlgili bir açık olan CVE-2026-105756, vLLM'i etkiliyor ve LMCache çok süreçli connector'ını kullanan dağıtımlarda hatalı biçimlendirilmiş bir cache salt değeri motorun çökmesine neden oluyordu. Bu, vLLM 0.30.0'da düzeltildi. dev.to'nun belirttiği gibi, model sunucusunu yükseltmek bu açığı kapatıyor ama cache sunucusundaki açığı tam olduğu yerde bırakıyor.

Neden önemli

Çıkarım altyapısı çalıştıran herkes için bu duyuru, KV cache'i bir envanter sorusuna dönüştürüyor: hangi cache sunucuları var, hangi modda çalışıyorlar, her biri hangi adrese bağlı, hangi ağlar porta erişebiliyor ve o ağlarda daha neler var. Düzeltilmiş bir sürüm çıkana kadar yerleşim, resmi imajlarda root ayrıcalıklarıyla başlayan, kimlik doğrulaması gerektirmeyen ve 9.8 puanlı bu kod yürütme hatasına karşı savunmanın tamamı. vLLM ile model sunan ekipler düğümlerini bugün kontrol etmeli, çünkü dokümante edilmiş dağıtım yolu, açık olan yol.