MLflow'un webhook endpoint'indeki kimlik doğrulaması eksik SSRF, model registry'lerin arkasındaki iç ağları açığa çıkarıyor

Hata

dev.to'da yayınlanan bir yazıya göre CVE-2026-64849, MLflow'un webhook endpoint'inde eksik bir kimlik doğrulama kontrolü. Kimlik doğrulaması gerektirmesi gereken bir istek anonim olarak kabul ediliyordu ve MLflow sunucusu çağrıcının verdiği her URL'yi getiriyordu. Bu birleşim — kimlik bilgisi olmaması artı sunucu tarafından başlatılan bir istek — klasik bir server-side request forgery vakası. Sorun GHSA-7gwp-5pfp-969j numaralı GitHub advisory'si olarak takip ediliyor, savunmasız pencere 3.15.0 sürümüyle kapanıyor ve NLD bunu 9.3 olarak puanlıyor; dev.to yazarı bu puanı, model artefaktları barındıran bir platformdaki kimlik doğrulamasız bir SSRF için uygun buluyor.

Düzeltmenin iki yönü, tek başına bir allowlist'in neden hiçbir zaman işe yaramayacağını açıklıyor. İlki redirect'ler: ilk istek operatörün güvendiği bir host'u belirtebilir, ancak yanıt isteği başka bir yere yönlendirebilir; dolayısıyla yalnızca ilk adımı inceleyen doğrulama hiçbir şey kanıtlamaz. İkincisi DNS rebinding: bir hostname kontrol sırasında herkese açık bir adrese, istek gerçekten gerçekleştiğinde ise iç adrese çözümlenir. İkisi de iyi bilinen tekniklerdir ve ikisi de iyileştirmeyi bir yapılandırma seçeneği yerine doğrudan istek işleyicisinin içine taşıdı.

Sunucunun erişebilecekleri

Hasarın sınırını webhook değil, MLflow sürecinin giden ağ erişimi belirler. dev.to analizinde belirtildiği gibi, tipik bir dağıtım backend store için veritabanı kimlik bilgileri, artefakt store'u için kimlik bilgileri, çoğu zaman bir registry token'ı ve — Kubernetes altında — varsayılan yolunda mount edilmiş bir service account token'ı taşır. Bu süreçten gelen sahte bir istek dolayısıyla şunlara dokunabilir:

• metadata erişiminin sertleştirilmediği her yerde bulut instance metadata endpoint'i;
• mount edilmiş service account token'ının bir ödül haline geldiği iç Kubernetes API adresleri;
• isteğin kaynağına güvenen artefakt depolama yönetim endpoint'leri;
• dışarıdan erişilebilir olması hiç amaçlanmamış, pod ağına bağlı metrics ve admin portları.

Hiçbir payload ya da exploit zinciri gerekmiyor. Düz bir GET, yanıt gövdesinde imzalı bir URL veya kısa ömürlü bir token döndürebilir ve bu gövde, saldırganın başlattığı webhook çağrısından doğrudan geri akar. dev.to yazarı, savunmacıların bunu küçümsemeye meyilli olduğunu vurguluyor: saldırganın ihtiyacı olan tek bir başarılı yanıt, kutu üzerinde kod çalıştırma değil.

CVE gerektirmeyen komşu bir sorun

Aynı yazı, bu zafiyete hiç bağlı olmayan ilgili bir açığa da değiniyor. MLflow'un model gateway'leri üçüncü taraf AI sağlayıcılarını çağırıyor ve yapılandırmaları API anahtarları taşıyor. Aynı hattın önceki sürümleri, bir api_key alanının bir ortam değişkeni referansı tutabileceği, sunucu tarafında çözümlenebileceği ve çözümlenen değerin yapılandırmada belirtilen api_base'e iletilebileceği davranışa ilişkin düzeltmeler yayınladı. Gateway yapılandırması yazabilen herkes — açık bir tracking server, paylaşımlı bir experiment veya registry yazma hakkı olan ele geçirilmiş bir service account aracılığıyla — hiçbir SSRF olmadan sağlayıcı anahtarlarını sızdırabilir. İki sorunu birlikte okuduğunuzda tek bir özellik ortaya çıkar: MLflow hem gizli bilgileri saklar hem de ona erişebilen herkes adına giden çağrılar yapar.

Operatörler ne yapmalı

dev.to yazısı 3.15.0'a yükseltmeyi ve ardından bu hata sınıfının geri döneceğini varsaymayı öneriyor. Yamanın ötesinde:

• Egress'i kısıtlayın. Sunucunun veritabanına, artefakt store'una ve model sağlayıcılarına ihtiyacı var; metadata servisine ihtiyacı yok. Link-local adreslerin ve allowlist'te olmayan özel aralıkların reddedilmesi, gelecekteki SSRF'lerin değerinin çoğunu ortadan kaldırır.
• Metadata erişimini sertleştirin; örneğin hop limiti bir olan IMDSv2 gerektirin veya workload'un ağ namespace'inde metadata servisini devre dışı bırakın.
• Kimlik bilgilerini döndürün. Tracking server internetten erişilebilir ve yamasız idiyse, veritabanı şifresini, artefakt store anahtarlarını ve registry token'ını açığa çıkmış sayın — uygulama logları zayıf bir güvence sunar, çünkü sahte bir webhook çağrısı meşru bir teslimata benzer.
• Gateway yapılandırmasını, ortam değişkenlerine referans veren api_key değerleri ve beklenmedik yerlere işaret eden api_base değerleri açısından denetleyin, ardından bu sağlayıcı anahtarlarını döndürün.
• Tracking server'ı demo dağıtımlarının yanında bırakmak yerine bir reverse proxy arkasındaki tek oturum açmanın (single sign-on) arkasına koyun.

Açığa çıkan nüfus

CVE'ye yönelik ticari tarama yayından kısa süre sonra başladı ve geniş fingerprinting, dev.to'ya göre açıkta olan MLflow ilgili varlıkları on binlerce düzeyine yerleştirdi. Yazar bunun bir sayım değil üst sınır olduğunu belirtiyor: fingerprint'ler geliştirme instance'larını, dizüstü bilgisayarlarda açık kalan container'ları ve araştırmacı honeypot'larını da sayıyor. Sinyal, kesin rakam değil trenddir.

Neden önemli

Model registry'ler niş araçlar olmaktan çıktı ve erişilebilir instance'ların nüfusu, onları bir girişin arkasına koyma alışkanlığından daha hızlı büyüdü. Birçok ekip için gerçek açık, webhook'un kendisi hiç değildi — model hattının tamamı için kimlik bilgileri tutan bir iç build aracının herkese açık bir adreste yanıt vermesi ve bunu kimsenin belgelememiş olmasıydı. Buradaki kalıcı savunma mimariseldir: egress'i kontrol edin, metadata erişimini sertleştirin ve iç araçların önüne kimlik doğrulaması koyun; çünkü yamalar tek tek hataları giderirken, herhangi bir SSRF'nin değeri sunucunun erişebildiği her şeyle ölçeklenir.