Tek MP4 Dosyasıyla NGINX Worker'ı Çökert: CVE-2026-32647

İnternete açık milyonlarca sunucunun arkasında sessizce çalışan NGINX, bu sefer kendi medya işleme modülünden bir yara aldı. CVE-2026-32647, CVSS 7.8 puanıyla yüksek (HIGH) olarak derecelendirilen bu zafiyet; sıradan görünen bir MP4 dosyasını, NGINX worker sürecini çökertebilecek ya da uzaktan kod çalıştırma (remote code execution — RCE) kapısı aralayabilecek bir silaha dönüştürüyor. Peki bu açık tam olarak neyi etkiliyor, saldırı yüzeyi ne kadar geniş ve kurumunuzda şu an bu konfigürasyon aktif mi?

🔍 Zafiyet Nedir ve Ne Yapar?

CVE-2026-32647, NGINX’in ngx_http_mp4_module adlı modülünde keşfedilen bir bellek bozulması (buffer over-read / buffer over-write) açığıdır. Bu modül, MP4 video dosyalarını HTTP üzerinden sunmak ve özellikle ?start= parametresiyle video içinde belirli bir konuma atlamak (pseudo-streaming) için kullanılır. Saldırı senaryosu temelde şu şekilde işler:

Saldırgan, özel olarak hazırlanmış (kötü amaçlı) bir MP4 dosyası oluşturur. Bu dosya, atom/box yapısı bozuk ya da bellek hesaplamalarını yanlış yönlendirecek şekilde tasarlanmıştır.
Dosya, mp4 direktifinin aktif olduğu bir NGINX sunucusunda işleme alınır — ya doğrudan bir istek yoluyla ya da sunucunun yerel depolamasına önceden yüklenmiş bir dosya üzerinden.
Modül, dosyayı ayrıştırırken (parse ederken) belleği aşan okuma veya yazma işlemi gerçekleştirir.
En iyi senaryoda NGINX worker süreci çöker (hizmet kesintisi — DoS). En kötü senaryoda ise saldırgan worker sürecinin bellek alanında keyfi kod çalıştırabilir.

⚠️ Burada kritik bir ayrımı netleştirmek gerekiyor: Açığın tetiklenmesi için saldırganın kötü amaçlı MP4 dosyasını NGINX’in işleyeceği bir konuma yerleştirmiş olması şart. Bu durum, istismar çıtasını biraz yükseltse de —özellikle yükleme (upload) özelliği olan platformlar için— bu engeli aşmak sandığınızdan çok daha kolay olabilir.

🎯 Kimin İçin Gerçek Bir Risk?

Önce şunu netleştirmek gerekiyor: Bu zafiyet, varsayılan bir NGINX kurulumunu etkilemiyor. ngx_http_mp4_module modülünün derleme aşamasında dahil edilmiş olması ve yapılandırma dosyasında mp4 direktifinin kullanılıyor olması gerekiyor. Bu iki koşulun bir arada karşılandığı senaryolara bakıldığında karşımıza şu kurumsal profiller çıkıyor:

Video yayın platformları ve medya şirketleri: MP4 pseudo-streaming neredeyse standart konfigürasyon.
Eğitim teknolojisi (EdTech) şirketleri: Kurs videosu sunan platformlar sıklıkla bu modülü kullanır.
CDN önü NGINX proxy’leri: Özellikle kaynak (origin) tarafında MP4 işleme aktifse.
Dosya yükleme özelliği olan uygulamaların önündeki NGINX: Kullanıcı tarafından yüklenen içeriği doğrudan sunan yapılar ciddi risk altında.
NGINX Plus kullanan kurumlar: Ticari sürüm de açıktan etkileniyor; yama önceliği buna göre şekillendirilmeli.

Kendi kurumunuzda hangi NGINX yapılandırmalarının aktif olduğunu tam bilmiyor olabilirsiniz — özellikle merkezi yapılandırma yönetimi yoksa bu kör nokta oldukça tehlikeli. Bu noktada daha önce ele aldığımız Rails Active Storage DoS zafiyeti ile benzer bir örüntü görüyoruz: saldırgan, medya işleme katmanını hedef alıyor ve az bir çabayla servis kesintisi yaratıyor.

⚙️ Etkilenen Konfigürasyon Nasıl Görünür?

Aşağıda tipik bir savunmasız NGINX yapılandırması ve buna karşılık önerilen güvenli alternatif yer alıyor:

# ⚠️ SAVUNMASIZ KONFİGÜRASYON
# mp4 direktifi aktif, modul derlenmiş
server {
    listen 80;
    server_name video.example.com;

    location /videos/ {
        root /var/www/media;
        mp4;                        # <-- Zafiyet tetikleyici direktif
        mp4_buffer_size 1m;
        mp4_max_buffer_size 5m;
    }
}

# -------------------------------------------------

# ✅ GEÇİCİ AZALTMA: mp4 direktifini devre dışı bırak
# MP4 pseudo-streaming'e gerçekten ihtiyacınız yoksa:
server {
    listen 80;
    server_name video.example.com;

    location /videos/ {
        root /var/www/media;
        # mp4;   <-- Yorum satırına alındı veya tamamen silindi
        # Alternatif: Yalnızca güvenilir kaynaklardan gelen dosyaları sun
        add_header Content-Disposition "attachment";
    }
}

# -------------------------------------------------

# 🔧 NGINX'in ngx_http_mp4_module ile derlenip derlenmediğini kontrol et:
nginx -V 2>&1 | grep -o 'with-http_mp4_module'
# Çıktı varsa modül derlenmiş demektir.

# Aktif konfigürasyonlarda mp4 direktifini ara:
grep -rn "^\s*mp4;" /etc/nginx/
# Çıktı varsa zafiyet tetiklenebilir durumdadır.

Bu iki komutun çıktısı, kurumunuzdaki maruziyeti dakikalar içinde ortaya çıkaracaktır. Şimdi çalıştırmanızı şiddetle öneririm.

🛡️ Wazuh ile Tespit: Log İzleme ve Kural Önerisi

Wazuh kullanan ortamlarda bu zafiyetin aktif istismarını veya olası tetikleme girişimlerini tespit etmek için iki katmanlı bir yaklaşım öneriyorum:

1. Katman — NGINX Erişim/Hata Log İzleme: Worker çöküşleri hata loguna düşer; anormal MP4 isteklerini erişim logunda yakalamak mümkün.




  
  
    31108
    worker process.*exited on signal
    CVE-2026-32647 Şüphesi: NGINX worker süreci anormal sonlandı. MP4 modülü istismarı olabilir.
    
      T1499.002
    
    nginx_crash,high_severity
  

  
  
    31108
    .mp4
    start=\d{8,}
    CVE-2026-32647: .mp4 dosyasına anormal start parametresiyle istek — buffer manipulation girişimi olabilir.
    
      T1190
    
    nginx_mp4_suspicious
  

  
  
    100501
    CVE-2026-32647: Aynı kaynaktan yoğun MP4 isteği — DoS girişimi şüphesi.
    
      T1499
    
    nginx_mp4_dos

2. Katman — Dosya Bütünlüğü İzleme (FIM): Eğer ortamınızda kullanıcılar MP4 yükleyebiliyorsa, Wazuh FIM ile yükleme dizinini izleyin. Beklenmedik saatlerde eklenen veya boyutu alışılmışın dışında olan MP4 dosyaları erken uyarı sinyali olabilir.

# /var/ossec/etc/ossec.conf içine eklenecek FIM bloğu

  
    /var/www/media/uploads

📊 MITRE ATT&CK Eşleşmesi

Bu zafiyetin saldırı zincirindeki karşılıkları:

T1190 — Exploit Public-Facing Application (Halka Açık Uygulamayı İstismar Etme): Saldırganın NGINX’e doğrudan istek göndererek modülü tetiklemesi.
T1499.002 — Service Exhaustion Flood: Worker çöküşü yoluyla hizmet kesintisi yaratılması.
T1059 — Command and Scripting Interpreter: Başarılı RCE senaryosunda geçerli; saldırganın worker sürecinin yetkisiyle komut çalıştırması.
T1055 — Process Injection: Bellek bozulması yoluyla worker sürecine kod enjekte edilmesi (ileri seviye senaryo).

✅ Ne Yapmalısınız? — Aksiyon Listesi

Önceliklendirme önerimle birlikte adım adım:

Hemen envanter çıkarın: nginx -V 2>&1 | grep with-http_mp4_module komutuyla tüm NGINX örneklerinde modülün derlenip derlenmediğini kontrol edin. Bu, bir Ansible playbook’u veya basit bir SSH döngüsüyle tüm altyapıda dakikalar içinde yapılabilir.
Konfigürasyonu tarayın: grep -rn "^\s*mp4;" /etc/nginx/ ile aktif mp4 direktifini tespit edin. Modül derlenmiş olsa bile direktif kullanılmıyorsa risk yok — ama bunu doğrulamanız şart.
F5 Networks ve NGINX’in yayınladığı resmi yamayı uygulayın: NGINX Open Source ve NGINX Plus için yamalar yayınlandı. NGINX güvenlik danışma sayfasını takip edin. End of Technical Support (EoTS) durumundaki sürümler değerlendirilmiyor — bu sürümlerdeyseniz yükseltme aciliyet kazandı.
Yama öncesi geçici önlem: MP4 pseudo-streaming özelliğine gerçekten ihtiyaç duymayan sunucularda mp4 direktifini konfigürasyondan kaldırın veya yorum satırına alın. Bu, yeniden derleme gerektirmez ve hemen uygulanabilir.
Yükleme noktalarını gözden geçirin: Kullanıcıların MP4 dosyası yükleyebildiği uygulamalarda dosya türü doğrulamasını (sadece uzantı değil, gerçek MIME ve dosya imzası kontrolü) gözden geçirin. Kötü amaçlı bir MP4’ü sunucuya ulaştırmanın önündeki engellerden biri bu kontrol noktasıdır.
Wazuh kurallarını devreye alın: Yukarıdaki kural bloğunu test ortamınızda doğrulayıp üretim ortamına taşıyın. Worker çöküşleri için uyarı eşiğini düşük tutun — bu tür çöküşler normalde son derece nadir görülür, alarm değeri yüksektir.

Son Söz: “Sadece Medya Sunucu” Yanılgısı

Kurumsal ortamlarda sıklıkla karşılaştığım bir değerlendirme hatası şu: “Bu sadece video sunucu, kritik veri yok.” Oysa NGINX worker süreci, aynı sunucudaki diğer location bloklarına, arka planda çalışan servislere ve ağ segmentine erişim imkânı tanıyabilir. Bir worker’ın ele geçirilmesi; veri sızıntısı değil, yanal hareket (lateral movement) kapısı anlamına gelebilir. Bu açıkla bağlantılı saldırı senaryoları aklıma NGINX’i proxy olarak kullanan API ağ geçitlerini de getiriyor — bu noktada sunucu taraflı RCE zincirlemesi örneklerine bakmakta fayda var.

🛡️ Güvenlik açığı, nadiren “sadece şunu etkiler” dediğimiz yerde kalır. Bugün MP4 modülü, yarın başka bir katman. Sistematik konfigürasyon yönetimi ve merkezi log izleme olmadan bu tür açıkları zamanında yakalamak giderek zorlaşıyor.

Orijinal kaynak: https://nvd.nist.gov/vuln/detail/CVE-2026-32647

Securtr