NGINX'teki kritik HTTP/3 açığını neden ciddiye almalısınız?

Tam olarak ne yamalandı?

17 Haziran 2026'da yayımlanan NGINX 1.31.2 sürümü, birbirinden bağımsız iki hafızayı güvenli kullanma hatasını kapattı. İkisi de aynı puanı (CVSS 9.2) taşıyor ama farklı protokol yollarını ve farklı sürümleri etkiliyor. Etkilenip etkilenmediğinizi anlamak için önce kendi kurulumunuzun tablonun neresine düştüğüne bakın:

# iki kritik açık, tek yama penceresi
CVE-2026-42530  use-after-free · ngx_http_v3_module (HTTP/3 QUIC)
                etkilenen: Open Source 1.31.0–1.31.1
                sonuç: worker crash (DoS) · koşullu RCE

CVE-2026-42055  heap buffer overflow · HTTP/2 proxy + gRPC
                etkilenen: Open Source 1.30.0–1.30.2, 1.31.1
                         NGINX Plus 37.0.0–37.0.1
                sonuç: sürekli DoS

düzeltme       Open Source 1.31.2 / 1.30.3 · Plus 37.0.2.1
vahşi doğada   raporlanan istismar yok (rapor anı itibarıyla)

Dikkat edilmesi gereken bir ayrıntı: bu açıklar yalnızca elle kurduğunuz NGINX'i değil, onu içeren alt ürünleri de etkiliyor. NGINX Ingress Controller, Gateway Fabric ve Instance Manager gibi Kubernetes ve platform bileşenleri de savunmasız sürümler listesinde. Yani "biz NGINX'i doğrudan işletmiyoruz" demek çoğu zaman yanıltıcıdır; bir yerlerde, muhtemelen kümenizin giriş kapısında çalışıyordur.

Use-after-free ve buffer overflow neden bu kadar ciddi?

Her iki açık da klasik hafıza güvenliği hataları ailesinden. Use-after-free, bir programın serbest bıraktığı (artık "benim değil" dediği) bir hafıza bölgesini yanlışlıkla kullanmaya devam etmesidir. CVE-2026-42530'da bunu tetikleyen şey, özel olarak hazırlanmış bir HTTP/3 oturumunun QPACK encoder akışını yeniden açması; araştırmacının deyimiyle bir "lifetime mismatch". Sonuç, NGINX worker sürecinin çökmesi — yani hizmet dışı kalma (DoS). ASLR'nin devre dışı olduğu veya aşılabildiği ortamlarda ise use-after-free, uzaktan kod çalıştırmaya (RCE) kadar tırmanabilir.

Buffer overflow ise bir verinin ayrıldığı hafıza alanından taşmasıdır. CVE-2026-42055'te taşma, HPACK varint encoder'ın ayrılandan fazla (5 bayt) veri yazmasıyla oluşuyor ve sürdürülebilir bir DoS'a kapı açıyor. İkisinin ortak paydası şu: saldırganın oturum açmasına, bir parola bilmesine gerek yok. Sunucunuzla konuşabilen herkes — yani internetteki herhangi biri — tetikleyici trafiği gönderebilir. Kimlik doğrulaması olmadan uzaktan tetiklenebilir bir açığın kritik sayılmasının nedeni tam olarak budur.

"Sadece DoS, RCE değil" diye rahatlamak da yanlış olur. Bir web uygulamasının ön kapısındaki sunucunun tek bir paketle çökebilmesi, birçok işletme için zaten kabul edilemez bir tablodur. Üstelik "koşullu RCE" ihtimali, savunmasız bir sürümü ertelenebilir bir bakım kalemi olmaktan çıkarır.

"Bende HTTP/3 yok, beni ilgilendirmez" demeden önce

HTTP/3 açığının önemli bir tesellisi var: NGINX'te HTTP/3 varsayılan olarak kapalıdır. Tetiklenebilmesi için listen yönergesinde quic ve ayrıca http3 on'ın açıkça tanımlanmış olması gerekir. Bunu hiç etkinleştirmediyseniz, CVE-2026-42530 sizin için pratikte bir tehdit değil. Yeni protokolün ne işe yaradığını ve neden yavaş yavaş yaygınlaştığını HTTP/3 ve QUIC yazımızda ele almıştık.

Fakat rahatlamayı burada bırakmak hata olur. İkinci açık, CVE-2026-42055, çok daha yaygın bir yapılandırmayı hedefliyor: NGINX'i bir reverse proxy olarak veya gRPC trafiğini geçirirken kullanmak. Bu, sahadaki NGINX kurulumlarının istisnası değil, ta kendisidir. Dolayısıyla "HTTP/3 kapalı" olması sizi yalnızca iki açıktan birinden korur; ikincisi büyük olasılıkla tam da sizin senaryonuzu tarif ediyor.

Buradan çıkan asıl ders, tek bir CVE'nin ötesinde: hangi protokol özelliklerini gerçekten kullandığınızı bilmek, bir güvenlik lüksü değil temel bir envanter meselesidir. Açık olan her modül — kullanıyor olun ya da olmayın — potansiyel bir saldırı yüzeyidir.

Peki ne yapmalı? Pratik bir çerçeve

Amaç yalnızca bu iki numarayı listeden düşürmek değil, bir sonraki NGINX açığı çıktığında panik yaşamayacağınız bir disiplin kurmak. Sade bir çerçeve:

• Hemen yükseltin — Open Source için 1.31.2 ya da 1.30.3, NGINX Plus için 37.0.2.1. Yükseltmeyi erteleyecekseniz bile, geçici önlem olarak kullanmadığınız quic yönergelerini listen satırlarından kaldırın.
• Envanterinizi çıkarın — NGINX yalnızca sunucularınızda değil; Ingress Controller, Gateway Fabric, Instance Manager, hazır Docker imajları ve üçüncü taraf araçların içinde de yaşar. "Nerede NGINX çalışıyor?" sorusunu net yanıtlayamıyorsanız, ilk işiniz bu.
• Kullanmadığınız modülü kapatın — en az yetki ilkesi yazılıma da geçerli. Aktif etmediğiniz HTTP/3, gRPC gibi özellikleri açık bırakmak, sıfır kazançla saldırı yüzeyini büyütür.
• Yamayı bir sürece bağlayın — kritik açıklar takviminizi sormaz. Sürüm yükseltmesini elle değil, CI/CD hattınızın otomatik bir adımı hâline getirin; imaj yeniden inşası ve dağıtım tek komutla dönebilsin.
• Anormalliği görünür kılın — worker süreçlerinin çökme sıklığı, ani 5xx artışları ve olağan dışı HTTP/3 trafiği erken uyarıdır. Gözlemlenebilirlik olmadan bir DoS denemesini, hizmet kesintisi yaşanana kadar fark edemezsiniz.
• Güvenlik bültenlerini takip edin — NGINX gibi altyapı bileşenlerinin resmi protokol katmanındaki açıkları çoğunlukla önceden duyurulur. Bülten akışını izlemek, açığı manşetten değil kaynağından öğrenmenizi sağlar.

Bu adımların hiçbiri egzotik değil; hepsi klasik güvenlik hijyeninin altyapı katmanına taşınmış hâli. Değişen tek şey, "kullanıcı girdisi" yerine artık sunucunuzun konuştuğu protokolün kendisinin saldırı yüzeyi olması.

Peki geriye ne kalıyor?

Bu iki açık, henüz istismar edilmemiş olmaları ve nispeten dar tetikleme koşulları sayesinde, felaket senaryosundan çok bir tatbikat gibi görülebilir. Ama asıl kıymeti burada: kritik puanlı, kimlik doğrulaması gerektirmeyen, dünyanın en yaygın web sunucusunu etkileyen bir açığa ne kadar hızlı ve düzenli yanıt verebildiğinizi ölçen bir prova. Yamayı saatler içinde mi, yoksa haftalar sonra "acaba biz etkilendik mi?" telaşıyla mı uyguladınız — fark burada.

Yani asıl soru "bu sefer etkilendim mi?" değil. Doğru soru şu: bir sonraki kritik açık yarın açıklandığında, hangi sürümün nerede çalıştığını ne kadar hızlı söyleyebilir ve yamayı ne kadar sürede her yere ulaştırabilirim? Bu soruya rahatça yanıt verebilen bir altyapı, tek tek CVE'lerin ötesinde sizi ayakta tutan şeydir.

Konunun temellerine yakından bakmak isterseniz Bilgi Merkezi · Ağ Temelleri & Protokoller, Web Uygulama Güvenliği ve Gözlemlenebilirlik & Loglama rehberlerine; protokolün kendisini merak ediyorsanız HTTP/3 ve QUIC yazımıza göz atabilirsiniz. Açıkların resmi ayrıntıları için F5'in güvenlik bültenine bakabilirsiniz.