Üretimde model sunmak için yaygın kullanılan PyTorch TorchServe, yüksek önemde bir yerel ayrıcalık yükseltme (LPE) kaydıyla gündemde. ABD Ulusal Güvenlik Açığı Veritabanı’nda (NVD) CVE-2026-123974 koduyla izlenen açık, yaklaşık CVSS 7.8 ile derecelendiriliyor. GitHub danışma kaydı GHSA-g2fw-m3ph-hqcq; sınıflandırma CWE-379 (geçici dosya oluşturmada uygunsuz temizlik / güvensiz geçici konum). Özellikle 0.12.0 / commit 62c4d6a1 çevresi anılıyor; bazı kayıtlarda “tüm sürümler” ifadesi de geçiyor.
Daha kritik olan kısım yama tarafı: TorchServe projesi arşivlenmiş durumda ve kalıcı bir yama planı görünmüyor. Yani “bir üst sürüme geçin” cümlesi birçok kurulumda geçerli olmayabilir. Risk azaltma, yapılandırma ve işletim sistemi sertleştirmesine kalıyor.
Açık nasıl çalışıyor?
TEMP ortam değişkeni tanımlı değilse JVM’in java.io.tmpdir değeri çoğu Linux kurulumunda /tmp’ye düşüyor. TorchServe, model .mar arşivlerini /tmp/models/<id>/ altına açıyor. Sorun, dizinin oluşturulma biçiminde: forceMkdir, mevcut dizinin sahipliğini veya izinlerini kontrol etmeden kullanabiliyor.
Yerel bir kullanıcı önceden /tmp/models dizinini oluşturursa (örneğin 0777, sticky bit olmadan) üst dizinin sahibi olur. TorchServe model çıkardığında saldırgan, çıkarılan handler.py gibi bileşenleri rename ile değiştirip kodun TorchServe servis hesabı olarak çalışmasını sağlayabilir. Bu klasik bir yarış (race) şartı değil; dizin önceden sahiplenildiği için sticky bit’li /tmp bile saldırıyı engellemez, çünkü hedef doğrudan /tmp/models.
Neden “yalnızca yerel” olsa da ciddi?
LPE açıkları bazen “zaten makinede olmam gerekir” diye küçümsenir. Paylaşılan çıkarım sunucuları, çok kullanıcılı GPU düğümleri ve CI/CD ajanları için tablo farklı. Aynı makinede düşük yetkili bir kompromis — örneğin başka bir servisten sızmış bir kullanıcı kabuğu — TorchServe’in servis hesabına sıçrama tahtası olabilir. Servis hesabı çoğu zaman model dosyalarına, iç ağ uç noktalarına ve bazen bulut kimlik bilgilerine erişir.
TorchServe’in arşivlenmiş olması riski büyütüyor. Bakımsız çıkarım yığınları, “çalışıyor diye dokunulmayan” üretim bileşenleri olarak yıllarca kalabiliyor. CVE-2026-123974 gibi kayıtlar, bu sessiz borcun faturasını çıkarıyor.
Kimler öncelikli etkilenen?
- /tmp paylaşan çok kullanıcılı Linux sunucularda TorchServe çalıştıran ekipler,
- TEMP veya java.io.tmpdir’i açıkça set etmeden varsayılanla çalışan kurulumlar,
- Model .mar dosyalarını sık sık yeniden yükleyen veya otomatik çıkaran boru hatları,
- Aynı düğümde geliştirici kabukları ile üretim çıkarımının yan yana yaşadığı laboratuvar ve staging ortamları.
Konteynerleşmiş kurulumlar daha güvenli sanılabilir; ancak konteyner /tmp’yi host ile paylaşırsa veya PrivateTmp benzeri izolasyon yoksa aynı sınıf risk yeniden üretilir. “Docker’dayız” tek başına yeterli değil.
Kalıcı yama yoksa ne yapılmalı?
Araştırma ve danışma kayıtlarının işaret ettiği geçici sertleştirme adımları şöyle özetlenebilir:
- TEMP ortam değişkenini veya -Djava.io.tmpdir değerini, servis hesabına ait ve world-writable olmayan bir dizine ayarlayın.
- systemd altında çalışıyorsanız PrivateTmp=yes kullanın; böylece birim kendi geçici alanına izole olur.
- /tmp/models gibi paylaşılan yolların önceden saldırgan tarafından oluşturulup oluşturulmadığını denetleyin; şüpheli sahiplikleri temizleyin.
- Mümkünse TorchServe’i tek kullanıcılı, ağ yüzeyi daraltılmış bir çıkarım düğümüne taşıyın; uzun vadede bakımı süren alternatif sunum katmanlarını değerlendirin.
Geçici dizinler, yapay zekâ yığınlarının kör noktası
Model sunucuları büyük arşivleri hızlı açmak için /tmp’ye yaslanır. Bu pratik, onlarca yıldır bilinen geçici dosya tuzaklarını yapay zekâ altyapısına taşıyor. forceMkdir’in sahiplik kontrolü yapmaması yeni bir sınıf değil; ancak .mar içindeki handler.py gibi doğrudan çalıştırılan bileşenlerle birleşince etki LPE’ye dönüşüyor.
Güvenlik ekipleri için kontrol listesine net bir madde eklenmeli: “Çıkarım süreci geçici dizini kime yazıyor, o dizin world-writable mı, servis hesabı oradan kod mu yüklüyor?” TorchServe CVE-2026-123974, bu sorunun cevabı “/tmp/models ve evet” olduğunda sonucun ne kadar doğrudan olduğunu gösteriyor. Proje arşivliyken tek gerçekçi savunma, yapılandırmayı sertleştirmek ve paylaşılan /tmp varsayımını terk etmek.
Kaynak: ABD Ulusal Güvenlik Açığı Veritabanı (NVD), GitHub güvenlik danışma kaydı, TorchServe güvenlik araştırması
