fosstr
Yazı

GPUStack CVE-2026-102895: 9.8'lik kimlik doğrulama atlatması nasıl çalışıyor?

GPUStack'te 127.0.0.1'e güvenen kimlik doğrulama mantığı, uzaktan yönetici erişimine yol açtı. CVE-2026-102895'in teknik detayları, CISA KEV süreci ve yükseltme rehberi.

GPUStack, birden fazla sunucudaki GPU’ları tek bir havuz gibi yönetmek ve üzerinde model servis etmek için kullanılan açık kaynak bir platform. Özellikle kendi donanımında LLM çalıştıran ekipler için pratik: GPU düğümlerini ekliyorsunuz, model indirip dağıtıyorsunuz, API üzerinden erişiyorsunuz.

4 Kasım 2026’da yayınlanan CVE-2026-102895, bu platformda CVSS 9.8’lik bir kimlik doğrulama atlatması tanımlıyor. 9 Kasım’da CISA’nın Known Exploited Vulnerabilities (KEV) kataloğuna eklendi; yani aktif olarak istismar edildiğine dair kanıt var. Bu yazı, açığın teknik mekanizmasını ve savunma tarafında ne yapılması gerektiğini anlatıyor.

Kısa özet

Alan Değer
CVE CVE-2026-102895
CVSS 3.1 9.8 (Critical)
Vektör AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Zayıflık sınıfı CWE-287, CWE-290, CWE-346
Etkilenen sürümler 2.2.0 öncesi
Düzeltme 2.2.0 (tek başına), 2.2.2 (önerilen)
CISA KEV 9 Kasım 2026 eklendi
Federal son tarih 12 Kasım 2026

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

Sorunun kökü, gpustack/api/auth.py içindeki get_current_user fonksiyonunda. GPUStack, force_auth_localhost ayarı kapalıyken (varsayılan) loopback’ten gelen isteği yerleşik yönetici olarak kabul ediyor. Mantık şu: “127.0.0.1’den gelen kişi zaten sunucunun başındadır, ona tekrar şifre sormayalım.”

Bu varsayım, uygulama doğrudan kullanıcıyla konuştuğunda makul. Ama GPUStack çoğu kurulumda bir ters proxy’nin (nginx, Traefik, Caddy) arkasında çalışıyor. Ve istemcinin IP’sini belirleyen client_ip_getter, iki durumda yanlış sonuç veriyor:

  1. Aynı makinedeki ters proxy, isteği 127.0.0.1’den iletiyorsa, GPUStack bunu gerçek istemci sanıyor.
  2. İstemci, X-GPUStack-Real-IP başlığını kendisi gönderip değerini 127.0.0.1 yaparsa, uygulama bu başlığa güveniyor.

Yani uzaktan gelen bir saldırgan, isteğini yerel makineden geliyormuş gibi gösterebiliyor. Kimlik doğrulama atlanıyor ve oturum, yerleşik yönetici olarak açılıyor.

Elde edilen erişim ne kadar geniş?

CVE kaydına göre atlatma sonrası saldırgan şunları yapabiliyor:

  • Kullanıcı ve model tanımlarını değiştirmek,
  • Kalıcı yönetici API anahtarı oluşturmak,
  • Worker ve bulut sağlayıcı sırlarını okumak,
  • POST /v2/inference-backends/from-yaml üzerinden kod çalıştırmak.

Son madde, olayın en kritik kısmı. GPUStack’in “inference backend” mekanizması, YAML tanımıyla özel bir çalışma zamanı veya konteyner başlatmaya izin veriyor. Yönetici yetkisiyle bu uç noktaya erişen biri, pratikte GPU düğümünde kod çalıştırabiliyor. GPUStack düğümleri genellikle model ağırlıklarına, Hugging Face token’larına, bulut kimlik bilgilerine ve iç ağ erişimine sahip; yani tek bir auth bypass’ı, tüm AI altyapısına açılan kapı olabiliyor.

Gerçekten istismar edildi mi?

Evet. GPUStack’in 31 Temmuz 2026’da yayınlanan GHSA-gj9m-f8ph-pmhr duyurusu, açığın 2.1.1 sürümlü bir kurulumda aktif olarak istismar edildiğini söylüyor. Saldırganların özel backend’ler üzerinden ters kabuk (reverse shell) çalıştırdığı belirtiliyor. İstismarı bildiren kişi Javier Sixto (Ulex Innovative Systems).

CISA, 9 Kasım 2026’da açığı KEV kataloğuna ekledi. CISA duyurusunda dört açık birlikte listeleniyor; GPUStack bunlardan biri. Federal kurumlar için verilen son tarih 12 Kasım 2026.

Bu son tarih yalnızca ABD federal sivil kurumları için bağlayıcı. Ama KEV’e girmek, açığın teorik değil, sahada kullanıldığının işareti. EPSS skorunun düşük görünmesi (yazı sırasında yaklaşık %0,6) yanıltmasın; EPSS bir olasılık tahmini, KEV ise gözlemlenmiş istismar.

Hangi kurulumlar risk altında?

Risk, üç koşulun birlikte oluşmasına bağlı:

  1. GPUStack sürümü 2.2.0’dan eski,
  2. force_auth_localhost kapalı (varsayılan),
  3. API’ye güvenilmeyen bir ağdan erişilebiliyor; ya aynı makinede ters proxy var ya da uygulama X-GPUStack-Real-IP başlığına güveniyor.

Kurulum yalnızca iç ağda, VPN arkasında ve ters proxy olmadan çalışıyorsa risk daha düşük. Ama “iç ağ” tek başına güvenlik değil; yanlış yapılandırılmış bir proxy veya başlık yönlendirmesi kapıyı açabilir. Ayrıca aynı sunucuda çalışan başka bir uygulamanın ele geçirilmesi, loopback’e istek atmasına yetebilir.

Düzeltme ve yükseltme

İlk düzeltme 2.2.0 sürümünde (18 Haziran 2026) yayınlandı. Ancak aynı dönemde başka bir kimlik doğrulama sorunu daha vardı: CVE-2026-102894, 0.7.1’den 2.2.2’ye kadar olan sürümleri etkiliyor. Bu yüzden önerilen hedef 2.2.2 (24 Temmuz 2026).

# Docker ile çalıştırıyorsanız imajı güncelleyin
docker pull gpustack/gpustack:v2.2.2

# Helm kullanıyorsanız chart sürümünü ve image tag'ini kontrol edin
helm list -A | grep gpustack

Yükseltmeden sonra şunları doğrulayın:

  • force_auth_localhost ayarının açık olduğundan emin olun. Varsayılana güvenmeyin; kurulumunuzda açıkça true yapın.
  • Ters proxy, istemciden gelen X-GPUStack-Real-IP başlığını silin veya yalnızca kendi eklediği değeri geçirin. Başlığı körü körüne iletmeyin.
  • Yönetici API anahtarlarını gözden geçirin; tanımadığınız anahtar varsa iptal edin.
  • Worker ve bulut sağlayıcı kimlik bilgilerini döndürün (rotate). Açık istismar edilmişse bu sırlar ele geçmiş olabilir.
  • Denetim kayıtlarında POST /v2/inference-backends/from-yaml çağrılarını ve beklenmeyen kullanıcı/model değişikliklerini arayın.

Hemen yükseltemiyorsanız

Geçici önlemler, yamayı ertelemek için makul; kalıcı çözüm değil:

  • GPUStack API’sini doğrudan internete açmayın. VPN veya kimlik doğrulamalı bir edge proxy arkasında tutun.
  • Ters proxy’de X-GPUStack-Real-IP başlığını temizleyin.
  • force_auth_localhost ayarını true yapın; loopback istisnası kapansın.
  • Aynı makinede çalışan diğer servisleri ayrı bir kullanıcı/konteyner olarak izole edin.
  • GPU düğümlerinden dış ağa giden trafiği kısıtlayın; ters kabuk ve veri sızdırma hareketini zorlaştırın.

Daha geniş ders

GPUStack olayı, “iç ağda zaten” varsayımının ne kadar kırılgan olduğunu gösteriyor. Loopback’e güvenmek, özellikle ters proxy’li kurulumlarda sık görülen bir hata. Aynı desen yalnızca GPUStack’te değil, birçok self-hosted uygulamada var: X-Forwarded-For veya X-Real-IP başlığına doğrulamadan güvenmek.

AI altyapısı söz konusu olduğunda risk daha da büyüyor; çünkü bu sistemlerde model ağırlıkları, bulut kimlik bilgileri ve GPU kapasitesi bir arada. Bir auth bypass’ı yalnızca veri sızdırmıyor, aynı zamanda saldırganın sizin pahalı GPU’larınızda istediği işi çalıştırmasına da izin veriyor.

Kısacası: GPUStack kullanıyorsanız sürümü 2.2.2’ye çıkarın, force_auth_localhost ayarını açık tutun ve proxy başlıklarına güvenmeyi bırakın. CISA’nın 12 Kasım tarihi ABD federal kurumları için; ama aktif istismar herkes için geçerli.