Geçmiş makale tarihi: 2026-10-14 (açıklama ve güvenliğin yayınlanma tarihi). Kaynaklar kontrol edildi ve bilgiler 2026-10-27 aracılığıyla desteklendi.

Bu makale etkinlik tarihine göre arşivlenmiştir; 14 Ekim sonrasında yayınlanan sürüm ve sürüm güncellemeleri aşağıda yer almaktadır. Hedef Kitle: NGINX Open Source / NGINX Plus web sitesi ve ters proxy işletim ve bakım personeli, güvenlik müdahale personeli, dağıtım bakım sorumlularının yanı sıra NGINX’yi kendi kendine derleyen ve üçüncü taraf modüllerin bakımını yapan mühendisler.

Bu makale, 14 Ekim 2026’da açıklanan ve yoğun bir şekilde düzeltilen beş NGINX temel güvenlik açığına odaklanmakta ve ayrıca Mayıs ile Eylül 2026 arasındaki temsili bellek güvenliği ve istek bütünlüğü güvenlik açıklarına bakmaktadır. İçerik, tetikleme koşullarını, kod düzeyinde nedenleri, etki kapsamını, iyileştirme iş akışını, kısa vadeli hafifletme önlemlerini, resmi yama uygulamasını, eski şubelere destekleri ve üretim doğrulamasını kapsar. S1 gibi referanslar kaynak ekine bağlantı verir. Örnek yapılandırmalar yalnızca dağıtım ve denetim fikirlerini göstermek için kullanılır ve uygulama öncesinde gerçek sürüme, yapılandırma mirasına, bağımlılıklara ve iş kapasitesine göre doğrulanmalıdır.

TL;DR: Öncelikli eylemler

  1. Güvenlik yükseltmelerine öncelik verin. nginx.org Açık Kaynak paketleri için, Stable 1.30 dalını en az 1.30.6’ye ve Mainline 1.31 dalını en az 1.31.7.‘ye güncelleyin Doğrulama tarihinde, 1.31.8 en son sürümdür Mainline sürümü. Bunlar ayrı dal temelleridir; Sayılarını şubeler arasında karşılaştırmayın. S1S2
  2. Dağıtım kurulumlarını tam paket sürümüne göre doğrulayın. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 satıcı desteklerine sahiptir; Debian 13 (trixie) en az 1.26.3-3+deb13u10 gerektirir. Doğrulama sırasında Debian 12 (bookworm) paketi 1.22.1-9+deb12u10 hâlâ etkilenmiş olarak işaretleniyor. Her CVE’yi kontrol edin; Debian 13 tavsiye belgesi, Debian 12’nin sabit olduğunu kanıtlamaz. S13S14S15
  3. Beş yapılandırma kombinasyonunu denetleyin: alias + rewrite + $request_filename, map + normal ifade + değişken değerlendirme, aio + ssi + include virtual, HTTP/3 ile proxy_request_buffering on ve otomatik TLS Oturum Bileti anahtar rotasyonu ile ssl_session_cache shared:.... Bir direktifin varlığı tek başına sömürülebilirliği sağlamaz; istek yolunu ve yapılandırma kapsamını değerlendirin. S1S3S4
  4. Tüm eski süreçleri ve kapsayıcıları değiştirin. nginx -t’yi çalıştırın, ardından hizmeti yeniden başlatın veya yüksek kullanılabilirliğe sahip sürekli dağıtım gerçekleştirin. Eski master/worker işlemlerinden çıkıldığını doğrulayın; nginx -s reload tek başına çalışan ikili programın değiştiğini kanıtlamaz.
  5. Gerçek uç noktaları doğrulayın: Etkinleştirilmişse HTTP/1.1, HTTP/2, HTTP/3, proxy yüklemeler ve API istek gövdeleri, mTLS sertifika kimlik doğrulaması, SSI sayfaları ve erişim günlükleri. Her uç nokta için paket kaynağını, sürümünü, görüntü özetini, çalışan işlemleri ve sonuçları kaydedin.
  6. Hemen yükseltme mümkün değilse geçerli tetikleme koşullarını kaldırın: gereksiz SSI/AIO veya HTTP/3’yi devre dışı bırakın, güvenlik açığı bulunan alias/rewrite/map değişken referanslarını inceleyin ve etkilenenler için geçici ssl_session_tickets off;’yi değerlendirin mTLS hizmetleri. WAF, ASLR, hız sınırları ve yapılandırma değişiklikleri yalnızca bazı koşulları kapsar ve resmi yamaların yerini alamaz. S3S4S8S12

1. Güvenlik Açığı Genel Bakışı ve Risk Değerlendirmesi

NGINX, 14 Ekim 2026’da 1.30.6 (Stable) ve 1.31.7 (Mainline)‘yi piyasaya sürerek beş güvenlik sorununu çözdü. Üçü, yığın taşmalarını veya ücretsiz kullanımı içerir ve F5 CVSS v4.0 9.2 / Kritik puanları aldı. Diğer ikisi HTTP/3 istek bütünlüğünü ve TLS istemci sertifikası kimlik doğrulamasını etkiler. S1S2S3

Derecelendirme sistemlerini ayırt edin: nginx.org, beş sorunun tamamını medium olarak listelerken, F5 CVSS v4.0 ve bazı ulusal güvenlik kurumları, üç bellek sorununu Kritik olarak sınıflandırır. Bu, beşinin de koşulsuz uzaktan kod yürütülmesine izin verdiği anlamına gelmez. Yapılandırma, trafiğe ulaşılabilirlik ve saldırganın kontrolü dışındaki koşullar önemlidir. Bellek bozulması ve güvenilir RCE farklı kanıt düzeyleridir. S1S3S4

CVETeknik sorunlar ve tipik tetikleme koşullarıçekirdek etkiDeğerlendirme ve İmha
CVE-2026-15176alias yol eşleme + rewrite değişiklik URI + değerlendirme $request_filenameYığın arabellek taşması, Worker çökmesi; belirli koşullar altında potansiyel RCEF5 CVSS v4.0 9.2; sorun gidermeye öncelik verin
CVE-2026-93479HTTP/Stream komut dosyası değerlendirmesi, özellikle map normal ifade yakalama ve root dizini, günlük değişkeni çapraz referansıAyrılmış arabelleğin üzerine yazılır ve yığın taşar; belirli koşullar altında potansiyel RCEF5 CVSS v4.0 9.2; önceki onarımlardan sonra gerileme riski var
CVE-2026-97205SSI sanal içerir ve AIO/asenkron çalışma; olağanüstü işlem sayısı taşmasıÜcretsiz Kullanım Sonrası, Worker çökmesi, bellek bozulması; potansiyel RCEF5 CVSS v4.0 9.2; varsayılan olmayan yapılandırma gerektirir
CVE-2026-95101HTTP/3 Bilinmeyen çerçeve arabellekler arasında parçalanmış, proxy istek gövdesi arabelleğe alma etkinDATA olmayan baytların yukarı akış istek gövdesine hatalı şekilde enjekte edilmesi, muhtemelen istek gövdesi boyutu sınırını atlamasıBu güvenlik açığı istek bütünlüğünü etkiler. Kendisi uzaktan kod yürütme (RCE) sağlamaz.
CVE-2026-97629Paylaşılan TLS Oturum Önbelleği, otomatik anahtar yönlendirme ve Worker anahtar yansıtmaOturum Bileti sahteciliği; etkilenen mTLS hizmeti için istemci sertifikası kimlik doğrulamasını atlama meydana gelebilirAPI sertifika kimlik doğrulama türünün iş üzerindeki etkisine özel dikkat gösterilmesi gerekir.

Yukarıdaki CVSS puanı, v4.0 kullanılarak F5 tarafından verilmektedir; aynı güvenlik açığı CVSS 3.1, nginx.org’nin kendi derecelerinde ve dağıtım önem derecelerinde farklı önem derecesi gösterebilir. S1S3S4

1.1 Yalnızca CVE puanları yerine dağıtıma öncelik verin

Dağıtım formuTemel araştırma noktalarıİmha önceliği önerileri
Özelleştirilmiş rewrite, alias ve karmaşık map dahil genel ağ ters proxy’siMayıs’tan Temmuz’a kadar CVE-2026-15176, CVE-2026-93479 ve güvenlik açıklarını yeniden yazma/haritalamaP0: Hemen denetleyin ve güncelleyin
API / İstemci sertifikasını tek veya ana giriş kimlik doğrulaması olarak kullanan yönetim düzlemiCVE-2026-97629’nin Oturum Bileti ve paylaşılan önbellek yapılandırmasıP0: Kimlik doğrulama sınırını hemen onaylayın ve güncelleyin
Harici HTTP/3 yükleme, durum değiştirme arayüzü, API işlem sınıfı sağlayınCVE-2026-95101, özellikle istek gövdesi arka uçta proxy olarak kullanılırP0/P1: İşin önemine göre düzenleyin
SSI Dinamik sayfa veya eşzamansız dosya G/ÇCVE-2026-97205P1: Kombinasyon koşullarını doğrulayın ve mümkün olan en kısa sürede onarın
Yalnızca statik sayfalar + basit HTTP/1.1/2 ters proxyYapılandırmanın ve sürümün hâlâ denetlenmesi gerekiyor ancak bazı CVE koşulları eksik olabilirP1: Acil durum güvenlik yükseltme penceresine dahildir
Kullanımdan kaldırılan Kubernetes Topluluğu ingress-nginx’yi kullanınProje güvenlik bakımını durduruyor ve riskler bu beş CVE ile sınırlı değilBireysel denetleyici geçiş planı yapın

P0/P1, kamu ağlarına maruz kalma ve sertifikasyon hassasiyeti için bu makalede verilen işletme ve bakım imha önerileridir. Resmi bir CVSS sınıflandırması değildir ve işletmenin dahili varlık ve değişiklik risk değerlendirmesinin yerini almamalıdır.

1.2 Etki sınırı ve saldırı izinleri

Bu gruptaki temel güvenlik açıkları esas olarak NGINX Veri Düzleminde bulunur: Saldırının giriş noktası istemci bağlantısı ve isteğidir ve asıl etki genellikle Worker sürecinde meydana gelir. Bellek bozulmasına yönelik yararlanılabilir koşullar karşılanırsa, kod yürütme izni genellikle Worker’nin çalışan kullanıcı, kapsayıcı kısıtlamaları, Linux yeteneği, montaj ve ağ izinleri tarafından kısıtlanır; potansiyel RCE, otomatik olarak root ayrıcalıkları veya ana bilgisayar güvenliğinin ihlal edildiği anlamına gelmez. S4

Ancak işlem ayrıcalıklı olmasa bile proxy kimlik bilgilerine, sertifika özel anahtarlarını içeren okunabilir dosyalara, yukarı akış hizmet belirteçlerine, geçici dosyalara, dahili API’ye ve erişilebilir ağlara hâlâ erişebilir. mTLS için kimlik doğrulamayı atlamanın kendisi ciddi bir iş sonucu olabilir ve mutlaka kod yürütmenin eşlik etmesi gerekmez.

2. Sebep analizi

2.1 NGINX’deki hataya açık üç sınırı anlayın

NGINX worker, istek durumunu, eşzamansız işlemleri ve protokol ayrıştırıcılarını koruyan, uzun ömürlü, olaya dayalı bir işlemdir. Bu güvenlik açığı üç mühendislik düzeyindeki kısıtlamaları bünyesinde barındırır:

  1. değişken değerlendirmesi ve bellek boyutu tutarlı olmalıdır: rewrite URI isteğini değiştirdikten sonra, yol eşlemesi şu anda etkin olan location ile tutarlı olmalıdır; Komut dosyası yorumlayıcısı değişken uzunluğunu hesapladığında, yazma alanının gerçek çıktıyı ve ayrılmış alanları kapsaması gerekir.
  2. Asenkron işlemler, talep edilen hafızanın ömrünü uzatmalıdır: Bitmemiş dosya okuma ve yazma, önbellek bekleme veya iş parçacığı görevleri olduğunda, ilgili istek hafıza havuzu önceden serbest bırakılamaz.
  3. protokol durumu ve güvenlik durumu karıştırılamaz veya atlanamaz: HTTP/3 Bilinmeyen çerçeve atlamanın uzunluğu, DATA istek gövde uzunluğu olarak kabul edilemez; TLS İmza doğrulamaya katılan tüm anahtar yuvalarının, oturum bileti rotasyonu sırasında doğru şekilde başlatılması ve senkronize edilmesi gerekir.

Aşağıdaki içerik, tetiklenebilecek arıza mekanizmasını açıklamak için NGINX yukarı akış düzeltme taahhüdüne ve satıcı duyurusuna dayanmaktadır; örnek parça analiz amaçlıdır, üretim ortamını onarmak için doğrudan kullanılabilecek kodun tamamı değildir. S5S6S7S8S9

2.2 CVE-2026-15176: alias ile yeniden yazılan URI arasındaki yol eşlemesi geçersiz.

NGINX’de eşleşen location ve onun alias’si dosya yolunu belirler; rewrite mevcut URI isteğini değiştirebilir. Yeniden yazıldıktan sonra orijinal location eşlemesinde kullanılan varsayımlar artık geçerli olmayabilir.

Etkilenen işlem yolu, ngx_http_map_uri_to_path()’deki alias durumu kontrol edilirken isteğin yeniden yazılıp yazılmadığını yeterince kontrol etmedi. Yapılandırma, yeniden yazmanın ardından $request_filename’yi değerlendirmeye devam ettiğinde, yol, mevcut URI durumuna uymayan varsayımlarla oluşturulabilir ve sonuçta yığın belleğine sınırların dışında bir yazma işlemi tetiklenebilir. S5

Tipik kombinasyon (yalnızca konfigürasyon denetimi için karşı örnek olarak kullanılır; dağıtım önerilmez):

# 仅用于识别风险模式:不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

Tehlike return ile sınırlı değildir: set, if, add_header, log_format, vb. aynı istek sürecinde $request_filename değerlendirmesi tetiklenirse de denetlenmesi gerekir. Örnekteki return yalnızca bu durum yolunun görülmesini kolaylaştırır; tüm üretim konfigürasyonlarının taşma üreteceği sonucunu çıkarmak için kullanılamaz. S5S10

Saldırının sonuçları: Bir isteğin oluşturulması, Worker’nin yeniden başlatılmasına veya hizmet kesintisine neden olabilir; ASLR’nin kapalı olması veya baypas edilebilmesi gibi koşullar altında RCE potansiyeli mevcuttur. Yukarı akış yamasının özü, yalnızca belirli bir arabelleği genişletmek yerine, artık geçerli olmayan alias bağlamında yeniden yazılan URI yol eşlemesini tamamlamayı reddetmektir. S5S10

2.3 CVE-2026-93479: Komut dosyası değerlendirmesinde “ayrılmış alan” ile gerçek değişken uzunluğu arasındaki uyumsuzluk

NGINX’nin HTTP ve Stream modülleri, değişmez dizeleri ve değişken değerleri sonuç dizesinde birleştiren komut dosyası değerlendiricilerine sahiptir. Uygulama örnekleri arasında HTTP belgesi root yolları, erişim günlüğü yolları ve Stream’deki değişken ifadeler yer alır.

map + normal ifadelerin belirli yapılandırmaları, map sonuç değişkeni değerlendirilmeden önce yakalanan değerlerin diğer ifadeler tarafından okunmasına olanak tanır. Ayrılmış uzunluğa sahip komut dosyası yürütme yöntemiyle birleştirildiğinde eski uygulama, len ayrılmış alanı önceden değerlendirilen uzunluk toplayıcısına sayar, böylece sonraki yazma işaretçisi hesaplamaları artık arabellek sınırıyla tutarlı olmaz. Belirli bir değişken değerlendirme sırasında, sonraki dize yazma işlemleri ayrılmış alanın üzerine yazılarak yığın taşmasına neden olabilir. S6

katılımcı unsurlarNeden dikkat etmeye değer?
map’deki normal ifadeYakalama değişkeni değerlendirmesi bağımsız yaşam döngüsüne ve önbelleğe alma davranışına sahip olabilir
$1, $2 vb. gibi anonim yakalamalar.Diğer normal ifadeler veya ifadeler tarafından kolayca üzerine yazılabilir, bu da sahipliğin izlenmesini zorlaştırır
root’deki değişkenlerYol oluşturmayı tetiklerken komut dosyası yürütme ve arabellek rezervasyonu
log_format/Dinamik günlük yoluAynı türde değerlendirme daha sonra talepte tetiklenebilir
stream’deki komut dosyası ifadeleriYukarı akış düzeltmesi aynı zamanda ngx_stream_script_run()’yi de değiştirir. Yalnızca HTTP modülünü inceleyemezsiniz.

Önemli regresyon ilişkisi: Bu güvenlik açığıyla ilgili kod, CVE-2026-42533’yi düzelten önceki değişikliklerle ilgilidir. Debian 13’ün resmi DSA’sı, etkilenen kodun daha önceki bir güvenlik desteği aracılığıyla trixie paketine eklendiğini açıkça belirtiyor. Bu nedenle, “Temmuz ayı map güvenlik açığı yaması yüklendi” ifadesi, Ekim ayı CVE-2026-93479 güvenlik açığının kapsandığı anlamına gelmez; tam güvenlik düzeltme zinciri kontrol edilmelidir. S6S14S17

Buradaki potansiyel RCE riski bellek koruma ortamıyla ilgilidir ve map regex’inin tek başına anonim saldırganlar tarafından istismar edilebileceği iddia edilmemelidir. S11

2.4 CVE-2026-97205: AIO Tamamlanmamış işlem sayısı sarmalaması, Ücretsiz Kullanımdan Sonra Kullanıma neden olur

Bu güvenlik açığı yalnızca “SSI’yi açarsanız UAF elde edersiniz” değildir. Anahtar, ana istek tarafından tutulan eşzamansız işlem referans sayısında yatmaktadır.

NGINX Henüz tamamlanmayan eşzamansız işlemleri izlemek için r->main->blocked’yi kullanın; eski uygulamada bu 8 bit sayımdı; bazı yollar sayıyı artırmadan önce üst sınır kontrolü yapmadı. Aynı ana istek 256 bekleyen işlemi topladığında, sayı 255’ten 0’a kadar sarılabilir. Sonraki işlemler yanlışlıkla isteğin serbest bırakılmasını engelleyen eşzamansız bir işlem olmadığına inanacak ve dolayısıyla görev tarafından hala başvurulan istek bellek havuzunu serbest bırakacaktır. S7

Başarısızlık süreci şu şekilde ayrılabilir:

  1. İlgili eşzamansız G/Ç/iş parçacığı yolu etkinleştirildiğinde, SSI sayfası, include virtual aracılığıyla birden fazla alt istek veya okuma işlemi sunar.
  2. Belirli bir ana isteğin bekleyen işlemleri, sayım alanının temsil ettiği üst sınıra kadar toplanır.
  3. Yanlış bir şekilde “bekleyen işlem yok” olarak ifade edilen 8 bitlik sayım tamamlandı.
  4. Dosya okunurken, önbellek beklerken veya iş parçacığı görevlerinin geri çağrılması sırasında istek bellek havuzu serbest bırakılır.
  5. Sonraki eşzamansız tamamlama geri aramaları, serbest bırakılan belleğe erişerek UAF, Worker çökmelerine veya potansiyel bellek bozulmasına neden olur.

Resmi düzeltme, istek başlık dosyasına NGX_HTTP_MAX_BLOCKED 250 ekler ve çıktı filtresine, önbellek okumasına ve yukarı akış iş parçacığı yoluna kısıtlamalar ekler; eşiğe ulaşıldığında, senkronize yollara sahip işlemler senkronize olarak tamamlanır ve güvenli bir şekilde işlenemezse, bekleyen görevlerin daha fazla eklenmesi reddedilir. S7

uygulanabilirlik kararı: SSI, AIO, sanal dahil etme, alt talepler ve ilgili asenkron işlemlerin aynı istek zincirinde kombinasyon halinde gerçekleşip gerçekleşmeyeceği değerlendirilmelidir. Bunlar genellikle varsayılan düz statik proxy yapılandırmaları değildir. aio off; veya ssi off; belirli tetikleyici öğeleri kaldırabilir ancak öncelikle iş işlevi bağımlılıkları onaylanmalıdır. S4S7S25

2.5 CVE-2026-95101: HTTP/3 bilinmeyen çerçeve, DATA istek gövdesinin durumuyla karıştırılıyor

HTTP/3 çerçeve ayrıştırıcısının, DATA çerçeveleri (HTTP istek gövdesi işlemesine geçirilmesi gereken) ile atlanması gereken bilinmeyen çerçeveler arasında ayrım yapması gerekir. Bilinmeyen çerçevelerin uzunluğu, ağ arabellekleri arasında parçalanırken de doğru bir şekilde korunmalıdır.

ngx_http_v3_parse_data()’nin eski uygulaması, bilinmeyen çerçeveler atlanırken “atlanacak kalan bayt sayısını” kaydetmek için st->length alanını kullanırken, istek gövdesi filtresi aynı alanı “kalan DATA yük uzunluğu” olarak yorumladı. Bilinmeyen çerçeve birden çok ayrıştırma çağrısını kapsıyorsa, ayrıştırma kesildikten sonraki bayt kümesi yanlışlıkla istek gövdesinin bir parçası olarak algılanabilir. S8

İki tür risk ortaya çıkar:

  • istek gövdesi enjeksiyonu: İstemci tarafından gönderilen DATA olmayan çerçeve yükü, arka uç tarafından fiilen alınan verileri değiştirerek yukarı akış uygulamasına iletilebilir.
  • boyut sınırı atlamaları: client_max_body_size ve diğer kısıtlamalar. Beklenen kontroller DATA yolunda yoğunlaşmıştır ve yanlış dönüştürülen içerik ilgili doğrulamayı atlayabilir.

Yetkili tarafından açıklanan tipik tetikleme senaryosu, ngx_http_v3_module’nin HTTP/3 talebini alması ve proxy_request_buffering on’yi iletmesidir. Proxy istek gövdesi ara belleğe alma, ngx_http_proxy_module’de varsayılan olarak etkindir. Bu nedenle öncelikle HTTP/3’yi etkinleştiren ters proxy kontrol edilmelidir. proxy_request_buffering on; açıkça yazılmadığı için herhangi bir tetikleme koşulunun olmadığını varsaymak uygun değildir. S8S18

Bu güvenlik açığının doğrudan sonucu, NGINX çekirdeğinde doğrudan tamamlanan RCE’nin eşdeğer ifadesi olmayan arka uç istek bütünlüğü ve güvenlik sınırı değişikliğine aittir. Nihai iş etkisi, bu baytların nasıl ayrıştırıldığına ve yukarı yönde nasıl güvenildiğine bağlıdır. S24

2.6 CVE-2026-97629: TLS Bilet rotasyonu üçüncü anahtar yuvasını kaçırıyor

Etkilenen yapılandırmalarda, NGINX, TLS Oturum Bileti anahtarlarını paylaşılan bellek önbelleği aracılığıyla otomatik olarak oluşturabilir ve döndürebilir; böylece birden fazla Worker’nin aynı bilet grubunu işlemesine olanak sağlanır.

İlgili senkronizasyon mantığı, her Worker için 3 anahtar yuvası tahsis eder ve şifre çözme geri araması da bu yuvalardan geçecektir; ancak eski uygulama, her seferinde paylaşılan hafızadan yalnızca 2 anahtar yuvasını kopyalar ve sonuçta üçüncü yuvanın anahtar adı, HMAC anahtarı ve AES’i elde edilir. Anahtar başlatılmamış olarak kalabilir. Bir biletin anahtar tanımlayıcısı bu durumla eşleşirse, imza doğrulama ve şifre çözme için başlatılmamış anahtar malzemesi kullanılabilir, böylece TLS oturumunu oluşturmak için bir yol oluşturulur. S9

Yüksek riskli dağıtım kombinasyonları genellikle şunlardır:

# 仅为排查触发条件所示:共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件,使用自动轮换机制

Bu güvenlik açığının ticari açıdan en ciddi sonucu, ssl_verify_client on;’de istemci sertifikası kimlik doğrulamasını (mTLS) ve diğer yöntemleri kullanan hizmetlerde, sahte kurtarma oturumlarının istemci sertifikası doğrulamasını atlayabilmesidir. Saldırının başarısı aynı zamanda kontrol edilemeyen koşullara da bağlıdır; Yalnızca normal sunucu tarafı HTTPS sertifikası kullanan ve istemci sertifikası kimlik doğrulaması olmayan bir site, “saldırganın tüm web sitesindeki oturum açma bilgilerini atlayabilir” şeklinde yanlış şekilde nitelendirilmemelidir. S9S12

Bu bir TLS oturum kimlik doğrulama durumu sorunudur ve sunucunun TLS özel anahtarının kırık olup olmadığı veya genel CA root sertifikasının etkilenip etkilenmediği ile ilgisi yoktur. S24

2.7 DoS, RCE, kimlik doğrulama atlama ve bilinen açıklardan yararlanma yöntemleri nasıl anlaşılır?

  • DoS: Bellek hatası Worker’nin çökmesine veya toplu olarak yeniden başlatılmasına neden oluyor. Genel olarak kullanılamamaya neden olup olmadığı trafik baskısı, sürecin yeniden başlatılması yeteneği, bağlantı bakım süresi ve yüksek kullanılabilirlik mimarisi ile ilgilidir.
  • potansiyel RCE: Bazı duyurular, ASLR kapatıldığında veya atlandığında kod yürütme olasılığının bulunduğunu belirtir. Bu, komutları istikrarlı ve evrensel olarak yürütebilen halka açık bir saldırı zincirinin açıklandığı anlamına gelmez. S4
  • İstek ekleme/kimlik doğrulamayı atlama: Korunan iş durumunu veya istek içeriğini doğrudan değiştirebilir ve doğrudan kabuğu almadığı için göz ardı edilemez.
  • saldırı girişimlerini keşfetti: Mayıs 2026’daki CVE-2026-42945’de, yaygın kullanım faaliyetlerine ilişkin raporlar var; Bu tarihsel gerçeğin doğrudan, Ekim ayındaki beş CVE’nin tamamının büyük ölçekte başarılı bir şekilde kullanıldığı anlamına gelmemesi gerekir. S23

3. Onarım sürümü ve yama seçimi

3.1 NGINX Open Source resmi yama temeli

yukarı akış şubesiEkim ayında beş güvenlik açığını kapsayan ilk resmi sürüm2026-10-27 itibarıyla öneriler
Stable 1.30.x1.30.6(2026-10-14)En az 1.30.6’yi yükleyin ve sonraki güvenlik sürümlerini takip edin.
Mainline 1.31.x1.31.7(2026-10-14)1.31.8(2026-10-21)
Önceki NGINX Open Source şubesiYalnızca “eski güvenlik açığı yamalarının uygulanmış olması” temel alınarak değerlendirilemezÖnce korunan şubeye geçin; aksi takdirde satıcının CVE-by-CVE esasına göre resmi destek kanıtı sunması gerekir.

Bunlar, nginx.org yukarı akış kaynak kodunun/resmi şubesinin sürüm sonuçlarıdır ve dağıtım satıcısı tarafından sağlanan desteklenen düzeltmelere sahip güvenlik paketini doğrudan reddetmek için kullanılmamalıdır. 1.31.6’nin değeri 1.30.6’den büyük olsa bile ana hat dalının yama taban çizgisinden hâlâ düşüktür. S1S2

3.2 Beş CVE’nin yukarı yönlü etki kapsamı

Aşağıdaki aralıklar, nginx.org güvenlik bülteninin orijinal metnine göre listelenmiştir ve “geçerli çalışan dal” ve “gerçek yapılandırma yolu” ile birlikte anlaşılmalıdır:

CVEYukarı akış etiketleri etkilenen sürümlerResmi olarak etiketlenmiş sabit sürüm
CVE-2026-151760.1.29–1.31.61.30.6+ veya 1.31.7+, ilgili dallarında
CVE-2026-934791.30.0–1.30.5,1.31.2–1.31.6Yukarıdakiyle aynı
CVE-2026-972050.8.11–1.31.6Yukarıdakiyle aynı
CVE-2026-951011.25.0–1.31.6Yukarıdakiyle aynı
CVE-2026-976291.23.2–1.31.6Yukarıdakiyle aynı

CVE-2026-93479’nin belirli tanıtım sürümü sınırları vardır; her eski NGINX sürümü bu gerilemeden etkilenmez. Bu aralıkların dışındaki eski sürümler, önceki map normal ifade güvenlik açığı CVE-2026-42533’den hâlâ etkilenebilir. S1

3.3 Ubuntu: dağıtım destek portları (USN-8955-1)

Canonical USN-8955-1 26 Ekim 2026, dört Ubuntu yapısı için güvenlik güncellemesi sağlıyor: S13

Ubuntu versiyonunginx ve aynı kaynak paketinin sabit versiyonuAçıklama
22.04 LTS1.18.0-6ubuntu14.22Bu bir satıcı desteğidir; yukarı akış sürüm numarası hala 1.18.0’yi gösteriyor
24.04 LTS1.24.0-2ubuntu7.19Yukarıdakiyle aynı
26.04 LTS1.28.3-2ubuntu1.12Yukarıdakiyle aynı
26.101.30.4-7ubuntu1.1Yukarıdakiyle aynı

Duyuru, nginx-core, nginx-extras, nginx-full ve nginx-light gibi homolog paketlerin ilgili sabit sürümlerini içerir. Yalnızca nginx -v tarafından gösterilen giriş kısmından düzeltilip düzeltilmeyeceğine dair sonuçlar çıkarmayın. Ubuntu 24.04 ve 1.24.0-2ubuntu7.19 gibi yamalar bu satıcı tarafından eklenmiştir, ancak herhangi bir kaynaktan gelen 1.24.0 doğası gereği güvenli değildir.

Ubuntu ayrıca CVE-2026-95101’nin yalnızca Ubuntu 26.04 / 26.10’yi etkilediğini ve CVE-2026-97629’nin yalnızca Ubuntu 24.04 / 26.04’yi etkilediğini resmi olarak açıkça belirtti. /26.10. İşte Ubuntu’nin diğer dağıtımlara doğrudan tanıtılamayan kendi ambalajı ve işlevsel kapsamı. S13

3.4 Debian: Versiyonlar arasındaki farklar ayrıca kontrol edilmelidir

Debian tavsiye belgesi DSA-6575-1 (2026-10-21) bu beş CVE’yi kapsar ve Debian 13 / trixie için sabit nginx paketini şu şekilde tanımlar:

1.26.3-3+deb13u10

Ancak, bu raporun doğrulandığı tarih itibariyle, Debian 12 / bookworm için 1.22.1-9+deb12u10, Debian Güvenlik Takipçisi tarafından hâlâ savunmasız olarak işaretleniyor. Bu nedenle:

  • Debian 13 Sadece DSA-6575-1’e göre güncelleyin ve kabul edin.
  • Debian 12, mevcut Güvenlik İzleyici veya ELTS satıcısı tarafından sağlanan güvenlik düzeltmelerini tek tek kontrol etmelidir; Duyuruda düzeltme onaylanmadan önce, apt upgrade’nin başarısına göre beş öğenin tamamının düzeltildiğini beyan etmeyin.
  • Debian kaynak paketi, nginx.org sürüm numarasından bağımsız bir yama seti taşıyabilir. Özel derlemeler için, kaynak kodu paketi düzeltme kümesinin tamamını kontrol etmeniz gerekir ve yalnızca tek bir yukarı akış taahhüdünü kopyalayıp tamamlanmış sayamazsınız.

Yukarıdaki ayrım DSA ve CVE izleme kayıtlarına dayanmaktadır. S14S15S16

3.5 NGINX Plus, njs ve Giriş Denetleyicisi

Ürünler/BileşenlerGüvenlik Seçimi ve Doğrulama Önemli Noktaları
NGINX Plus (ticari versiyon)Lütfen F5’ye karşılık gelen Plus şubesinin duyuru ve yükseltme talimatlarına bakın. Doğrulama sırasındaki en son CR PLS.37.2.0.1’dir ve LTS’nin güvenlik yapısı PLS.37.0.7.1’dir; Plus sürümü ve dahil edilen arka bağlantı noktası, Açık Kaynağın 1.30/1.31 eşiğiyle doğrudan değiştirilemez. S19
njs / ngx_http_js_module2026-10-14, njs 1.0.2’yi yayınladı ve CVE-2026-101019 ve CVE-2026-101025’yi düzeltti; njs kullanıyorsanız modülün NGINX ile uyumluluğunu da kontrol etmeniz gerekir. S20
F5 NGINX Giriş Denetleyicisi / Ağ Geçidi YapısıNGINX çekirdeği, ilgili ancak bağımsız bir yazılım dağıtım zinciridir. İlgili güvenlik açıklarını ilgili denetleyiciler, resimler ve sürüm notlarıyla düzeltin. Pod’daki bir NGINX ikili dosyasını değiştiremezsiniz.
Kubernetes Topluluk kubernetes/ingress-nginxProje Mart 2026’da kullanımdan kaldırılacak ve artık yeni güvenlik bakımı sağlanmayacak. Sürüm numarasını F5 NGINX Giriş Denetleyicisi ile karıştırmak yerine, bakımı yapılan bir denetleyiciye veya Gateway API’ye geçiş yapmayı planlamalısınız. S21

3.6 Aslında Hangi Yamayı seçmelisiniz?

Dağıtım formuÖnerilen uygulamalarOnarım kanıtı
nginx.org resmi DEB/RPM paketiYukarı akış şubesinin sabit sürümüne yükseltmenginx -v/-V, paket kaynağı, resmi güvenlik duyurusu
Ubuntu/Debian resmi veri deposuSatıcı güvenlik paketlerini yükleyinTam paket sürümü + satıcı USN/DSA + CVE durumu
RHEL/Alma/Rocky/SUSE/Diğer dağıtımlarBelirli dağıtım güvenlik bültenlerine ve paket sürümlerine göre yükseltmeİlgili satıcı CSAF/duyuru, Ubuntu/Debian sürümü uygulanamaz
Resmi veya özel konteyner görselleriDoğrulanmış onarım görüntüsünü yeniden oluşturun veya çekin ve sürekli olarak değiştirinGörüntü özeti, SBOM oluşturma, bölme/konteyner görüntü kimliğini çalıştırma
Kendi kendine derlenen NGINX, OpenResty, Tengine veya üçüncü taraf modüllerle yamalı sürümlerBakımcının tam güvenlik sürümünün kullanımına öncelik verin; Gerektiğinde hedef kaynak ağacı için gözden geçirilmiş yama desteklerini gerçekleştirinBeş güvenlik açığı düzeltmesi, ABI/modül uyumluluğu, birim ve iş regresyonu

OpenResty ve Tengine farklı sürüm sistemleridir; bu tablo yalnızca doğrulama yöntemini açıklamaktadır. bu, tüm sürümlerinin standart NGINX ile aynı anda etkileneceği veya yukarı akış kod yamasının koşulsuz olarak uygulanamayacağı anlamına gelmez.

4. Resmi onarım süreci

4.1 Harici trafik almanın gerçek örneklerinin envanteri

En azından her giriş için harmanlayın:

  • Etki alanı adı, yük dengeleme/CDN/edge proxy bağlantısı, kaynak site görüntüleme yöntemi ve kullanılan ağ protokolü.
  • NGINX ürünleri (Açık Kaynak, Plus, Giriş vb.), tam sürüm, paket deposu kaynağı, görüntü özeti.
  • nginx -V, bina modüllerini ve derleme parametrelerini görüntüler; njs, Lua, OpenResty ve üçüncü taraf dinamik modüllerin olup olmadığı.
  • Gerçekte çalışan master/worker PID, Servis Birimi/Konteyner/Pod, Çoğaltma ve Worker Node.
  • Gerçek etkili http/stream, server, location, include konfigürasyonları.
  • HTTP/3, mTLS, SSI/AIO, dinamik günlük yolu, karmaşık map ve normal ifade yakalamanın etkinleştirilip etkinleştirilmeyeceği.

Yalnızca varsayılan /etc/nginx/nginx.conf’yi kontrol etmeyin. Üretim ortamı genellikle birden fazla siteyi, TLS’yi ve include aracılığıyla modül yapılandırmalarını yükler. Ayrıca birden çok NGINX yükleme yolu veya birden çok proxy katmanı da olabilir.

4.2 Sürüm ve derleme bilgilerini kontrol edin

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux:查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu:查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系:以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V, komut satırı yolunda bulunan ikili dosyanın yapısını bildirir; çalışan worker’nin onu yüklediğini kanıtlamaz. nginx -v, dağıtımın tam paket sonekini atlayabilir; bu nedenle paket yöneticisini veya tedarik zinciri kayıtlarını da kontrol edin.

4.3 Etkin yapılandırmayı dışa aktarın ve statik taramanın ilk turunu gerçekleştirin

nginx -T yapılandırmayı test edecek ve birleştirilmiş yapılandırmanın dökümünü alacaktır. Çıktı, kimlik doğrulama bilgileri, anahtar yolları, dahili ana bilgisayar adları vb. gibi hassas bilgiler içerebilir. Kontrollü terminalin root izinleri ve özel dosya izinleriyle kaydedilmesi ve orijinal dosyaların genel iş emirlerine gönderilmemesi önerilir:

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

Bu yalnızca aday yolu bulucudur, güvenilir bir CVE otomatik belirleme aracı değildir:

  1. grep, değişkenlerin aynı location’de mi yoksa aynı istek değerlendirme zincirinde mi bulunduğunu belirleyemediği gibi, yapılandırma devralma ilişkisini de çıkaramaz.
  2. proxy_request_buffering on, bazı önbellek ve bilet yapılandırmalarının varsayılan değerleri vardır ve ilgili talimatların yazılmaması, riskin ortadan kalktığı anlamına gelmez.
  3. Ters proxy’ler, CDN, konteyner sepetleri veya denetleyiciler tarafından oluşturulan yapılandırmalar, manuel olarak incelenen dosyalardan farklı olabilir.
  4. NGINX Plus ve dinamik modüllerin özelliklerinin ilgili resmi yönetim araçları kullanılarak doğrulanması gerekebilir.

4.4 Düzeltmeyi güvenilir kanallar aracılığıyla dağıtın

Debian/Ubuntu (resmi dağıtım deposu):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包;
# 先确认 Candidate 属于修复版本,再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

Bu komut dizisi, henüz mevcut olmayan yoktan güvenlik düzeltmeleri oluşturamaz. Özellikle Debian 12 için, yükseltilmiş paket güvenlik izleme sistemi tarafından hâlâ savunmasız görülüyorsa satıcının ek onarımı, izolasyonu veya geçiş önlemleri gerekir. S13S14S15

nginx.org resmi paketi:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

Kendi kendine derlenen OpenResty, Tengine veya NGINX Plus kullanıyorsanız, ilgili bakımcı tarafından desteklenen düzeltme sürümünü kullanın ve nginx.org, dağıtım ve üçüncü taraf depo paketlerini karıştırmayın. Orijinal ikili dosyalar/görüntüler, yapılandırmalar, imzalar ve geri alma dağıtım bildirimleri korunmalıdır.

Containers/Kubernetes: değişmez görüntüyü güncelleyin, özetini kaydedin ve tüm eski kopyaları aşamalı bir sunumla değiştirin. kubectl rollout status yalnızca dağıtım denetleyicisinin tamamlandığını doğrular; ayrıca görüntü özetlerini, giriş yönlendirmesini ve sağlıksız kopyaları da doğrulayın.

4.5 Yapılandırmayı doğrulayın ve eski Worker’yi değiştirin

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

nginx -s reload’yi yeni bir ikili programın çalıştığının kanıtı olarak görmeyin: sıradan yapılandırma yeniden yüklemeleri, eski master’nin yürütülebilir dosyasını değiştirmeden yeni çalışanları başlatmasına olanak tanır. NGINX, özel bir çevrimiçi ikili yükseltme prosedürünü destekler, ancak ek adımlar ve doğrulama gerektirir. Yerleşik bir prosedür olmadan, yüksek kullanılabilirliğe sahip bir trafik anahtarı ve ardından hizmetin yeniden başlatılmasını kullanın veya yedek kapsayıcıları dağıtın. S22

NGINX’yi systemd yuvası, kapsayıcı giriş komut dosyası veya birden fazla kurulum aracılığıyla yönetiyorsanız systemctl restart nginx’nin tüm örnekleri kapsadığını doğrudan varsaymak yerine gerçek başlatma hedefini ve işlem yolunu kontrol etmelisiniz.

4.6 Gerçek dış girişten iş regresyonunu kabul edin ve yapın

En azından aşağıdakilerin gerçekleştirilmesi önerilir:

  • Normal HTTPS, yeniden yazılan yollar, statik kaynaklar ve alias eşleme sayfaları doğru mu?
  • Normal map dağıtımı, değişken root yolu, erişim günlüğü yolu, SNI/sertifika yönlendirmesi ve Stream proxy’si doğru mu?
  • Normal yüklemeler, parçalı yüklemeler, API istekleri ve HTTP/3 (etkinleştirildiğinde) için yukarı akış birim sınırları hâlâ beklendiği gibi mi?
  • mTLS: Yasal sertifika istekleri başarılı olmalıdır; eksik, süresi dolmuş veya yetkisiz sertifikalar yine de reddedilmeli ve TLS’nin devam ettirilmesi/yeniden bağlanması izinleri yanlışlıkla değiştirmemelidir.
  • SSI sayfasının ve eşzamansız dosya erişiminin normal olup olmadığı; hata günlüğü, bellek referansları için herhangi bir anormal istek veya tekrarlanan Worker çökmesi göstermez.
  • Trafik geçişinden sonra eski sürüm işleminden ve eski imaj replikasından çıkılmış olması gerekir.

Testler kendi ortamında veya yetkili ortamda yapılmalıdır. Normal istek duman testi tek başına bellek güvenlik açığının giderildiğini kanıtlayamaz; sonuçta tedarikçinin sabit sürümü, kaynak kodu yaması ve çalışma zamanı testi, kabul için ortaklaşa kabul edilmelidir.

5. Hemen yükseltmenin mümkün olmadığı durumlarda azaltıcı önlemler

Bu bölüm bir yama değişimi değil, bir risk azaltma seçeneğidir. Tüm geçici yapılandırma değişiklikleri yedeklenmeli, nginx -t yürütülmeli, toplu olarak yayınlanmalı ve gerekirse hızlı bir şekilde geri alınmalıdır. S3S4

5.1 Harici maruziyete göre trafik önceliğini kontrol edin

Zamanında yükseltilemeyen hizmetlerin saldırı yüzeyini azaltmaya öncelik verin: yönetim yüzeyinde ve dahili API Güvenilir kaynak erişim kontrolü, yukarı akış ağ yalıtımı veya kısa süreli çevrimdışı ekleme; yüksek riskli girişlere bağlantı, talep gövdesi ve hız limitleri ekleyin; kaynak kimlik doğrulamasının istek işleme zincirinden önce girişle ilgili NGINX’de gerçekleştiğinden emin olun. Güvenlik açıklarının çoğunun NGINX’de yer aldığına dikkat edilmelidir. Veri düzleminin içinde, geleneksel WAF Kuralları özel yapılandırma tetikleme koşullarını doğru bir şekilde belirleyemeyebilir.

5.2 alias / rewrite: yeniden yazdıktan sonra $request_filename’yi değerlendirmekten kaçının

Aşağıdakileri kontrol etmeniz ve ayarlamanız önerilir:

  • alias kullanarak location ile aynı anda URI’yi değiştirecek rewrite işlemini gerçekleştirmemeye çalışın.
  • URI yeniden yazıldığında ancak doğru konum eşleşmesi henüz tamamlanmadığında $request_filename kullanmaktan kaçının.
  • return, set, if, add_header’deki dolaylı değişken referanslarını kontrol edin, erişim günlüğü biçimini kullanın ve dosyaları ekleyin.
  • İş izin verdiğinde temiz root/try_files/bağımsız location kullanın, ancak yalnızca alias’yi root olarak değiştirin. Ayrıca tek tek doğrulanması gereken dosya yolu anlamını da değiştirebilir.

Mevcut yapılandırmanın üzerine yazmak için ortak “güvenli yeniden yazma şablonunu” doğrudan İnternet’e kopyalamayın. Farklı location önekleri ve yeniden yazma hedefleri, tamamen farklı anlamlara sahip yol birleştirmeyle sonuçlanır. S5

5.3 map/Regex: Yakalama değişken durum karışımını azaltın

$1 gibi anonim yakalamaların zaman içinde farklı normal ifade değerlendirme yollarında yeniden kullanılmasına izin vermek yerine, adlandırılmış yakalamalara öncelik verilmesi ve yayılma kapsamlarının sınırlandırılması önerilir. Örneğin:

# 演示具名捕获的结构,实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

Bu kod parçası yalnızca denetlenmesi daha kolay olan değişken sahiplik yapısını göstermektedir; tüm CVE-2026-93479 tetikleme yollarını bağımsız olarak ortadan kaldırdığının kanıtlandığı anlamına gelmez. Özellikle, yakalama değişkenlerine önceden başka root veya log_format tarafından başvurulup başvurulmadığını ve volatile, dinamik yollar ve birbirine bağlı değerlendirme zincirlerinin olup olmadığını inceleyin. F5/CERT, kısa vadeli bir çözüm olarak adlandırılmış yakalamanın kullanılmasını ve kullanım kapsamının karşılık gelen düzenli eşleştirme yapılandırmasıyla sınırlandırılmasını önerir. S3S6

5.4 AIO + SSI: Gereksiz işlev kombinasyonlarını kapatın

SSI veya eşzamansız dosya G/Ç gerektirmeyen sunucular/yollar için şunu kullanın:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

Güvenlik açığını tetikleyen koşullar açısından bakıldığında, ikisinden birinin kapatılması genellikle açıklanan spesifik zincirin ortadan kaldırılması için yeterlidir; Aynı anda kapanma yalnızca işletmenin bu yeteneğe güvenmediği senaryolar için geçerlidir. include virtual, alt istekleri, önbelleği ve iş parçacığı havuzu davranışını kontrol edin; ters proxy yükü yüksek olduğunda AIO’nin kapatılması gecikmeyi ve G/Ç performansını değiştirebilir. S7

5.5 HTTP/3 Vücut enjeksiyonunu talep edin: gerekirse girişi geçici olarak kapatın

HTTP/3’yi içeren quic dinleyicisini devre dışı bırakın, HTTP/3’yi duyuran Alt-Svc yanıt başlığını iptal edin ve kenar katmanı/yük dengeleyicinin hala QUIC isteklerini doğrudan onarılmamış NGINX’ye gönderip göndermediğini kontrol edin:

# 示意:保留 HTTPS/TCP;暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建,可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;(仅限宣传 h3 的那项)
    # 其余证书、server_name、location 等配置保持不变
}

Yukarıdakiler yalnızca değişiklik farkının bir açıklamasıdır, tek tek etkinleştirilebilecek tam bir sunucu yapılandırması değildir. HTTP/2’nin ayar sözdizimi NGINX sürümüyle ilgilidir; HTTP/2’yi saklamanız gerekiyorsa, http2 on;’yi veya ilgili sürüme göre mevcut geçerli sözdizimini kullanmalı ve nginx -t ile kontrol etmelisiniz. bölümün tamamını bu bölümle değiştirmek yerine, dağıtımdan önce mevcut sunucu yapılandırmasıyla birleştirilmelidir. ayrıca UDP 443 güvenlik duvarını, HTTP/3 sonlandırma konumunu ve CDN/ön proxy’nin istemci geri dönüş yolunu da kontrol eder.

Diğer bir kısa vadeli azaltma türü, etkilenen proxy yolunda proxy_request_buffering off; kullanmaktır, ancak bu, yukarı akış istek gövdesi akışının, hata yeniden denemelerinin ve bazı yükleme iş akışlarının davranışını değiştirecektir; yalnızca yeterli sayıda test yapıldıktan ve yönergenin etkilenen HTTP/3 proxy yoluna ulaştığı onaylandıktan sonra kullanılabilir. S8S18

5.6 TLS Oturum Bileti: Öncelikli koruma mTLS Kimlik doğrulama sınırı

Yükseltme mümkün değilse ve örnek, paylaşılan oturum önbelleği + otomatik bilet anahtarı rotasyonuna dayanıyorsa şunları değerlendirin:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

Bu, TLS Oturum Bileti mekanizmasını kapatarak bu güvenlik açığında açıklanan bilet sahteciliği yolunu ortadan kaldırabilir; ancak oturumu sürdürme performansını etkileyebilir. “Güvenlik açıklarını önlemek” için mTLS istemci sertifikası doğrulamasını kapatamazsınız; bu, doğrudan orijinal kimlik doğrulama sınırını silecektir. S9S12

Açık ssl_session_ticket_key dosyaları ve güvenli rotasyon, profesyonel TLS yönetim süreçleri tarafından otomatik olarak oluşturulan koşulları atlatmak için de kullanılabilir, ancak anahtar saklama, tam düğüm dağıtımı, rotasyon ve eski bilet yaşam döngülerinin hepsinin dikkatli bir şekilde denetlenmesi gerekir. Uzun vadeli yeniden kullanılabilir bir anahtarın sıradan web yapılandırmasında veya geçici acil durumlar için komut dosyalarında sabit kodlanması önerilmez. mTLS kullanan kritik hizmetler ayrıca TLS oturum sürdürme davranışı ve geçerli bir istemci sertifikası olmayan isteklerin reddedilmesi açısından da izlenmelidir. S12

5.7 İşletim sisteminin rolü ve sınır koruması

# Linux:常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR, root olmayan çalışanlar, salt okunur konteyner dosya sistemleri, minimum dosya izinleri ve ağ yalıtımı, olası RCE’nin etkisini azaltabilir. ASLR, yığın taşmalarını veya UAF’yi düzeltmez ve çalışanların çökmeyeceğini garanti edemez. WAF, hız sınırları ve istek gövde boyutu sınırları, TLS Bilet anahtarı senkronizasyonunu düzeltmez. S4

5.8 Yaygın yanlış anlama: Bu işlemler onarımı tamamlamak için yeterli değil

Ortak işlemlerNeden yetersiz?
“nginx -v nispeten yeni görünüyor”Ait olduğu şube, yayın sürümünün tam destekli paket sürümü ve çevrimiçi süreç kontrol edilmez.
“İntranetlerden yalnızca biri yükseltildi”Eski Worker/eski kapsayıcı/eski CDN kaynak örneği hâlâ istek alıyor
”Site PHP/dinamik etiketleri kullanmıyor”Kusur, NGINX çekirdek yolunda veya protokol ayrıştırmasında meydana geliyor ve PHP yürütülmesine bağlı değil.
”WAF/Cloudflare’yi açmak yeterli”WAF’nin tüm NGINX yapılandırmaya bağlı bellek kusurlarını veya TLS yeniden başlatma kusurlarını engellediği kanıtlanamaz
”ASLR zaten açıldı”Sadece zorluk azaltma avantajından yararlanıyorum; İstek enjeksiyonlu DoS hala mümkün
”HTTP/3 genel ağa açık değil, dolayısıyla yükseltmeye hiç gerek yok”Diğer dört CVE’nin hâlâ bağımsız değerlendirmeye ihtiyacı vardır; ve gizli kökenlere doğrudan bağlantılar olabilir
”Temmuz ayının map güvenlik açığı düzeltildi”Ekim CVE-2026-93479, sonraki komut dosyası değerlendirme regresyon sorunlarını içeriyor
”Önbelleğe almayı devre dışı bırakmak tüm sorunları çözer”Yalnızca bazı TLS önbellek veya AIO senaryolarını etkiler ve takma adı, komut dosyasını, HTTP/3’yi kapsamaz

6. Resmi Yama uygulama fikirleri ve inceleme noktaları

Bu bölümde Ekim 2026 yukarı akış NGINX düzeltmeleri anlatılmaktadır. Parçacıklar, yama incelemesine yönelik temsili değişiklikleri göstermektedir; bunlar eksiksiz, bağımsız olarak derlenebilir düzeltmeler değildir. Özel derlemeler için tüm taahhütleri, çevreleyen kodu ve testleri inceleyin ve tam olarak desteklenen bir sürümü tercih edin. S5S6S7S8S9

6.1 CVE-2026-15176: URI, alias yol eşleme reddetme koşullarını içerecek şekilde yeniden yazıldı

Yukarı akış taahhüdü ngx_http_map_uri_to_path()’yi src/http/ngx_http_core_module.c’de değiştirdi:

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

inceleme odağı: URI değiştiğinde dosya sistemi yolu hesaplanmaya devam edilemez ancak alias’nin karşılık gelen konum semantiği artık güvenilir değildir. Bu, durum öncesi kısıtlamaya yönelik bir iyileştirmedir. URI isteğinin geçersiz karakterler içerip içermediğinin kontrol edilmesi basit bir işlem değildir. S5

6.2 CVE-2026-93479: Çıkış veri uzunluğu ile ayrılmış uzunluk arasında doğru ayrım yapın

Yukarı akış taahhüdü src/http/ngx_http_script.c ve src/stream/ngx_stream_script.c’yi aynı anda günceller. Temel niyet şu şekilde özetlenebilir:

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

Burada, pool açıklayıcı bir parametre adıdır: gerçek HTTP ve Stream ayırma ifadeleri farklıdır. Değişiklik, önce komut dosyası çıktı uzunluğunu hesaplar, ardından çıktının ayrılmış alanın üzerine yazmaması için ayrılmış uzunluğu son ayırmaya ekler. S6

Denetleme ve yedekleme sırasında, HTTP/Stream’nin ilgili değerlendiricisinin de kapsanması gerekir; yalnızca map yapılandırma sözdizimi dosyasının kontrol edilmesi hatanın giderildiğini kanıtlayamaz.

6.3 CVE-2026-97205: 8 bit asenkron işlem sayımı için güvenlik eşiğini ayarlayın

src/http/ngx_http_request.h’de yukarı akış eklendi:

#define NGX_HTTP_MAX_BLOCKED 250

Eşzamansız dosya okuma, önbellek bekleme, çıktı filtreleme ve iş parçacığı işlemine de benzer girişler ekleyin:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径,或者拒绝新的异步操作 */
}

inceleme odağı: r->main->blocked’yi ekleyecek tüm gerçek kod yollarının kapsanması gerekir. Başlık dosyasına yalnızca eşik sabitini yazamazsınız. Backport’un ayrıca görevlerin doğrudan reddedilmesi nedeniyle kilitlenme veya referans sızıntısına neden olmayacağından emin olmak için eşzamanlı geri dönüş, eşzamansız geri arama ve hata geri dönüşünün tam koordinasyonunu kontrol etmesi gerekir. S7

6.4 CVE-2026-95101: Bilinmeyen çerçeveler için skip durumunu ayrı olarak koruyun

Yukarı akış, skip alanını HTTP/3 ayrıştırıcı durum yapısına ekler ve durum ayırma işlemini gerçekleştirir:

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

Önemli olan “bilinmeyen HTTP/3 çerçevelerini devre dışı bırakmak” değil, birden fazla okumada atlanan bayt sayısının ve DATA yük uzunluğunun her zaman bağımsız durumlar tarafından yönetilmesini sağlamaktır. İncelemeler, bilinmeyen çerçeve çapraz arabellek parçalamasına ve client_max_body_size’nin nihai tutarlılığına odaklanmalıdır. S8

6.5 CVE-2026-97629: TLS anahtar yuvası dizisinin tamamını senkronize edin

Yukarı yöndeki değişiklikler src/event/ngx_event_openssl.c konumunda bulunur:

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

Orijinal görüntü üç anahtar yuvası içeriyordu ancak yalnızca ilk ikisi kopyalandı. Bunun yerine, Worker oylama anahtarı kümesinin paylaşılan bellekle tutarlı olduğundan emin olmak için dizi öğelerinin gerçek sayısına göre senkronizasyon yapın. İncelerken memcpy uzunluk değişikliğini yalnızca bir kez kontrol etmek yerine dizi tahsisi, başlatma, paylaşımlı kilit ve döndürme mantığının tutarlı olduğunu da doğrulayın. S9

6.6 Neden yalnızca dağınık yama parçalarının uygulanması önerilmez?

Bu beş değişiklik sırasıyla src/http, src/stream, src/http/v3 ve src/event’yi kapsar ve eski sürümler güvenlik destek bağlantılarına ve resmi olmayan uzantılara sahip olabilir. Destekleme aşağıdaki kontrol matrisini oluşturmalıdır:

Nesneyi kontrol etNeyin doğrulanması gerekiyor?
yama kaynağıResmi gönderim, eşleşen hedef sürüm, tam yama ve imza doğrulaması
Orijinal yama setiCVE-2026-42533, dağıtım destek portu vb. gibi geçmiş değişikliklerle çelişmez.
kod yoluHTTP + Stream komut dosyası, AIO/iş parçacığı, HTTP/3, OpenSSL Bilet’in tümü kapsanmaktadır
Derlenmiş uyumluOpenSSL, PCRE, modül ABI, dinamik modül ve bağlantı bağımlılıkları tutarlıdır
fonksiyonel regresyonalias yeniden yazma, dinamik günlük, SSI/AIO, HTTP/3 yükleme, mTLS oturum sürdürme
çalışma zamanıTüm Worker/Pod’lar yeni doğrulanmış yapıları çalıştırır, eski görüntüler kalmaz

Kendi sürümlerini sürdüren ekipler için, her CVE için denetlenebilir yama kimliklerini, paket sürümlerini, derleme günlüklerini ve regresyon raporlarını saklamanız önerilir; olağan çalıştırma ve bakım için en güvenli çözüm, satıcının eksiksiz güvenlik güncellemelerini yüklemektir.

7. Tarihsel güvenlik açığının geriye doğru izlenmesi, eski şubeler ve diğer ürünler

7.1 NGINX Mayıs’tan Eylül 2026’ya kadar eş zamanlı onaylanmaya değer temel güvenlik açığı

Uzun süredir güncellenmeyen birçok NGINX bulut sunucusu yalnızca Ekim ayındaki yeni sorundan etkilenmekle kalmıyor. Aşağıdakiler yakın gelecekteki temsili onarım düğümleridir: S1S2

CVEİlk düzeltme sürümüDenetim gerektiren temel riskler ve koşullar
CVE-2026-42945Stable 1.30.1 / Mainline 1.31.0, 13 Mayısrewrite Anonim normal ifade yakalama ve değiştirme mantığı yığın taşmasını tetikler, potansiyel RCE; vahşi saldırı girişimlerine dair kamuya açık raporlar var
CVE-2026-9256Stable 1.30.2 / Mainline 1.31.1, 22 Mayısrewrite’de örtüşen normal ifade yakalama ve uzunluk tahmini taşmaya neden oluyor
CVE-2026-42055Stable 1.30.3 / Mainline 1.31.2, 17 HaziranHTTP/2 Yukarı akışa veya gRPC’ye özel yapılandırma, büyük istek başlığı koşulu arabellek taşmasını tetikler
CVE-2026-42530Mainline 1.31.2, 17 HaziranHTTP/3 Ücretsiz Kullanım Sonrası; resmi marka etkilenen aralık 1.31.0–1.31.1
CVE-2026-42533Stable 1.30.4 / Mainline 1.31.3, 15 Temmuzmap + normal ifade yakalama değişkeni değerlendirmesi yığın taşmasına neden oluyor ve sonraki yamalar Ekim ayında CVE-2026-93479 ile regresyon korelasyonuna sahip
CVE-2026-60005Stable 1.30.4 / Mainline 1.31.3, 15 Temmuzngx_http_slice_module Belirli değişken ve önbellek güncelleme koşulları altında bellek içeriği sızdırıldı
CVE-2026-56434Stable 1.30.4 / Mainline 1.31.3, 15 TemmuzSSI, UAF ile ilgilidir; Ekim ayındaki AIO sayma güvenlik açığıyla aynı root nedeni değil
CVE-2026-90439Stable 1.30.5 / Mainline 1.31.6, 15 EylülHTTP/3 + belirli OpenSSL sürüm kombinasyonunun sınırlı yığın taşması, çoğunlukla kilitlenme/sınırlı bellek bozulması olarak kendini gösterir

2026 yılında duyurulan NGINX Core, HTTP/2, charset ve SMTP gibi diğer güvenlik açıklarının da resmi güvenlik bültenlerine göre araştırılması gerekir; Bu tablo bilinçli olarak mevcut NGINX halka açık ters proxy dağıtımlarıyla en alakalı olan ve bellek güvenliği veya istek bütünlüğü etkilerine sahip tipik olaylara odaklanmaktadır. 2026’daki tüm CVE’ler değildir. Liste. S1

Neden CVE-2026-42945’ye özellikle dikkat etmelisiniz?

Bu rewrite güvenlik açığına yönelik, Mayıs ayında, yaygın kullanım faaliyetlerini ve genel yararlanma kodu bilgilerini kaydeden devlet kurumlarından güvenlik bültenleri bulunmaktadır. Bu nedenle, Mayıs ayından bu yana uzun süredir yama uygulanmayan ve genel ağda açık karmaşık düzenli ifade yeniden yazma işlemlerinin yapıldığı örnekler için, onarımın tamamlanmasının yanı sıra, anormal Worker çökmesi, erişim günlükleri ve o andaki şüpheli değişiklikler de ayrıca incelenmelidir. S23

“Bir saldırı girişiminde bulunuldu” ifadesi, saldırganın her hedefte komutları güvenilir bir şekilde yürüttüğünü otomatik olarak kanıtlamaz; Olay müdahalesi söz konusu olduğunda, uzlaşma göstergeleri ve süreç çökmeleri, ayrıcalık artışının veya kalıcılığının gerçek kanıtlarından ayrı olarak araştırılmalıdır.

7.2 Eski sürümler ve dağıtım destek portları için iyileştirme

NGINX Farklı şubelerin kendi destek döngüleri ve farklı güvenlik açığı tanıtım süreleri vardır. Beş yeni yama, inceleme yapılmadan tüm erken kaynak ağaçlara dağıtılamaz.

sahneÖnerilen strateji
Sürüm sürümü tam güvenlik yamalarını duyurduSatıcı paketlerini kullanın ve tam paket sürümlerini belgeleyin; uyumsuz yukarı akışlı çıplak ikili dosyalar ile değiştirmekten kaçının
Debian 12 ve henüz bu gruptaki tüm CVE’lerin kapsamına girmeyen diğer etkilenen sürümlerRiskli iş emirlerini gönderin, dış maruziyeti sınırlandırın ve tedarikçi/ELTS durumunu kontrol edin; Gerektiğinde doğrulanabilir bir bakım serbest bırakma zincirini taşıyın veya kullanın
Yukarı yöndeki desteği sonlandıran tarihi şubelerDesteklenen sürümlere geçişe öncelik verin; Kısa vadeli yedekleme gerekliyse bakımcılar bağımlılıkları ve yama uyumluluğunu değerlendirecek ve eksiksiz testler yazacaktır.
NGINX çatalıyla birlikte gelir (OpenResty, Tengine, özelleştirilmiş ağ geçidi)Öncelikle karşılık gelen kod yolunun eklenip eklenmediğini belirleyin ve ardından çatal sorumlusunun güvenlik bildirimini kullanın. Yukarı akış sürümüne doğrudan eşdeğer olamaz.
Güvenlik yamaları iş işlevselliğinde değişikliklere yol açarAşamalı sunumları, sürümler arasında trafik geçişini ve yapılandırma uyarlamasını benimseyin; Genel ağın sabitlenmemiş sürümünü izolasyon olmadan geri yüklemek uygun değildir.

7.3 njs, Ingress ve NGINX Core için ayrı iyileştirme

  • njs: NGINX ana programına ek olarak NGINX JavaScript modülünün sürümünü de kontrol etmeniz gerekir. njs 1.0.2, Ekim 2026 XML ayrıştırma belleği tükenmesini ve varlık referans öznitelikleriyle XML doğrulama tutarsızlığı sorununu düzeltir. nginx-saml kullanılarak XML imza doğrulamasıyla ilişkili dağıtımlar için, eklenti senaryolarına yönelik resmi njs talimatlarını da okumalısınız. S20
  • F5 NGINX Plus / NGINX Giriş Denetleyicisi: Ayrıca denetleyici ve Gateway Fabric’in her biri ek güvenlik bültenlerine, farklı paketleme sürümlerine ve benzersiz politika güvenlik açıklarına sahip olabilir. Bir katmanın yükseltilmesi, başka bir katmanın otomatik olarak güncellenmesi anlamına gelmez. S19
  • Kubernetes Topluluğu ingress-nginx: Kubernetes yetkilileri, kontrolörün Mart 2026’da bakımı durdurduğunu ve deposunun F5 kontrol cihazıyla karıştırılamayacağını zaten duyurdu. Etkilenen işletmeler, yeni bir güvenlik sürümü beklemek yerine sorunsuz geçiş planlamalı ve Giriş ek açıklamalarını ve Gateway API anlam farklılıklarını doğrulamalıdır. S21

8. Kabul kriterleri ve takip muayeneleri

Değişiklik iş emirleri için kabul koşulları olarak aşağıdaki listenin kullanılması tavsiye edilir:

ProjeYeterlilik standartlarıSaklanabilecek deliller
Varlık ve portal kapsamıCDN’yi atlayabilen tüm harici ve doğrudan bağlı bulut sunucularının envanteri çıkarıldı.Alan adı, LB, IP, Pod/konteyner listesi
Paket kaynağı ve onarım kapsamıGeçerli tüm CVE’leri kapsayacak şekilde onaylanmış sürümleri kullanınYukarı akış güvenlik danışmanlığı, USN/DSA, paket sürümü, görüntü özeti
eski süreç çıkışlarıTüm eski master/worker/konteynerler değiştirildiPID/başlangıç zamanı, sürekli dağıtım durumu, çalışan görüntü
Yapılandırma denetimiYüksek riskli kombinasyonlar ortadan kaldırıldı veya yamalarla kaplandı ve miras ilişkileri doğrulandınginx -T’nin düzeltilmiş özeti ve denetim kaydı
TLS/mTLSGüvenilir sertifikalar geçer; geçersiz veya eksik sertifikalar reddedilir; oturumun sürdürülmesi kimlik doğrulamayı atlamazNegatif/pozitif yetkilendirme testi, kontrollü TLS test sonuçları
HTTP/3 istek gövdesiSabit yolu etkinleştir; yukarı akış istek gövdesi ve azaltma doğru davranıyorHTTP/3, proxy yükleme, ses sınırı regresyon testi
SSI/AIOİşlev gereksinimleri karşılıyor, Worker’de anormal bir iptal yokİş regresyonu, çökme ve hata oranı izleme
İşletme ve bakım izlemeBelirgin bir istisna yok 5xx, SIGSEGV, işlem tekrar tekrar çıkıyorDeğişikliklerden önceki ve sonraki hizmet göstergeleri ve günlükler
Geri alma stratejisiGeri alma gerekliyse öncelikle maruz kalmayı sınırlayın ve güvenlik sınırlarını koruyunSiparişleri, Acil Durum Akışlarını ve Karantina Planlarını Değiştirme
sonraki yaşam döngüsüGüvenlik bülteni aboneliklerini, kapsayıcı güncelleme sıklığını ve şube geçiş planlarını belirleyinYükseltme defteri, sorumlu kişi ve bir sonraki denetim tarihi

8.1 Günlüklerde ve çalışma durumunda neye odaklanmalısınız?

Uzun süredir maruz kalan worker process exited on signal 、 SIGSEGV, istek hatası ani artışları, anormal kaynak erişimi toplama, beklenmeyen TLS Oturum sürdürme/kimlik doğrulama başarısı ve anormal arka uç istek gövdesi davranışına maruz kalan sunuculardaki anormallikleri giderin. Bu göstergeler yalnızca soruşturma ipuçları olarak kullanılabilir ve belirli bir CVE’nin istismar edildiğini doğrudan kanıtlamak için yeterli kanıt değildir. ;İlgili logların olmaması bir saldırının olmadığını kanıtlamaz.

8.2 Önerilen nihai risk sonuç metni

Üretim ortamına ilişkin kabul raporunda aşağıdaki kesin ifade kullanılmalıdır:

NGINX harici servis girişi ve yazılım paketi kaynağı belirlendi. Geçerli tüm örnekler yukarı akış resmi güvenlik sürümüne yükseltildi veya sürüm sağlayıcısı tarafından onaylanan destek tamamlandı; eski Worker ve eski kaplar değiştirildi. Takma ad/yeniden yazma/harita, AIO/SSI, HTTP/3 istek gövdesi ve TLS Oturum Bileti/mTLS ile ilgili yapılandırmalar denetlenmiş ve işlevsel, kimlik doğrulama ve istek bütünlüğü regresyon testlerinden geçmiştir. Yükseltmeyi henüz tamamlamamış örnekler için ek olarak risk alanlarını, tazminat önlemlerini, sorumlu kişileri ve tamamlama son tarihlerini kaydedin.

Debian 12 veya diğer sürümlere yönelik yama hâlâ eksikse, kabul formunun tamamının “tamamlandı” olarak değerlendirilmesi uygun değildir; çözülmemiş CVE, karşılık gelen bir tetikleme konfigürasyonunun olup olmadığı, izolasyon durumu ve son yükseltme rotası açıkça kaydedilmelidir.


Ek: Alıntılanan kaynaklar ve bağlantılar

Açıklama: Metindeki [Sx] numaraları bu bölüme aynı şekilde karşılık gelir. Aşağıda, yukarı yönlü proje güvenlik duyurularına, kod taahhütlerine, tedarikçi sürüm duyurularına ve ulusal güvenlik teşkilatı bilgilerine öncelik verilmektedir. Belirtilen güvenlik açıklarının ciddiyeti, veren her kuruluşun derecelendirme kriterlerine göre açıklanmaktadır; veri doğrulama tarihi 27 Ekim 2026’dır.

S1 — NGINX Open Source Resmi Güvenlik Bülteni

Ekim ayındaki beş CVE’nin yukarı yönde etkilenen sürümlerini, düzeltme dallarını ve resmi önem düzeylerini içerir ve ayrıca 2026’ya kadar olan geçmiş güvenlik açıklarını da kapsar.

S2 — NGINX resmi sürüm yayın kaydı

2026-10-14’nin 1.30.6 / 1.31.7’sini, 2026-10-21’nin 1.31.8’sini ve Mayıs’tan Eylül’e kadar kritik güvenlik sürümü kilometre taşlarını onaylayın.

S3 - Singapur Siber Güvenlik Ajansı: F5 NGINX Üç Kritik güvenlik açığı

CVSS v4.0 9.2 puanlarının açıklaması, gerekli yapılandırma koşulları ve CVE-2026-15176, CVE-2026-93479 ve CVE-2026-97205 için geçici azaltma önerileri.

S4 - NHS İngiltere: F5 NGINX Yüksek risk tavsiyesi

Bellek güvenliği sorunlarının DoS / olası RCE etkisini ve ASLR’nin kapatılması veya atlanması gibi kısıtlamaları açıklar.

S5 — Resmi kaynak taahhüdü: CVE-2026-15176

ngx_http_map_uri_to_path()’deki alias ve r->uri_changed’nin durum kontrolüne karşılık gelir.

S6 — Resmi kaynak taahhüdü: CVE-2026-93479

HTTP/Stream komut dosyası uzunluğuna ve ayrılmış arabellek ayırma mantığına karşılık gelir.

S7 - Resmi kaynak taahhüdü: CVE-2026-97205

r->main->blocked sayım eşiği NGX_HTTP_MAX_BLOCKED 250’ye ve eşzamansız yol geri dönüşüne karşılık gelir.

S8 — Resmi kaynak taahhüdü: CVE-2026-95101

HTTP/3 bilinmeyen çerçeve kalan uzunluğuna ve DATA istek gövdesi uzunluğuna karşılık gelen durum ayrımı.

S9 — Resmi kaynak taahhüdü: CVE-2026-97629

TLS Oturum Bileti rotasyonu sırasında senkronizasyon sırasında tüm anahtar yuvalarına karşılık gelir.

S10 — F5: CVE-2026-15176 Satıcının Duyurusu

alias, rewrite, $request_filename gibi tetikleyici faktörleri ve erişim günlüklerini listeleyin.

S11 — F5: CVE-2026-93479 Satıcı Duyurusu

Harita normal ifade yakalamasını, root yolunu ve günlük değişkeni değerlendirme koşullarını listeleyin.

S12 — NGINX resmi TLS/SSL modül belgeleri

Açıklama ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key ve istemci sertifikası kimlik doğrulaması ve diğer talimatlar.

S13 — Güvenlik danışmanlığı: Ubuntu USN-8955-1 (2026-10-26)

Ubuntu 22.04 / 24.04 / 26.04 / 26.10. yazılım paketinin sabit sürümünü ve dağıtım kapsamını sağlayın

S14 — Güvenlik danışmanlığı: Debian DSA-6575-1 (2026-10-21)

Debian 13 / trixie için güvenlik düzeltme paketi 1.26.3-3+deb13u10’yi onaylayın ve CVE-2026-93479 için arka bağlantı noktası ilişkilendirmesini kaydedin.

S15 — Güvenlik açığı takibi: Debian Security Tracker: CVE-2026-15176

Debian 12 / bookworm ve Debian 13 / trixie dağıtım düzeltme durumunu doğrulamak için kullanılır. Bu durum gelecekteki güvenlik güncellemeleriyle değişebilir.

S16 — Güvenlik açığı takibi: Debian Security Tracker: CVE-2026-95101

Farklı Debian dallarındaki HTTP/3 güvenlik açığının güvenlik durumuna ilişkin ek doğrulama.

S17 — Güvenlik danışmanlığı: Red Hat: CVE-2026-93479

Ekim regresyonundaki güvenlik açığı ile Temmuz CVE-2026-42533 düzeltmesi arasındaki korelasyona ilişkin ek anlayış.

S18 — NGINX resmi ters proxy modülü belgesi

proxy_request_buffering, client_max_body_size, alias, aio vb. gibi yapılandırmaların anlamlarını ve varsayılan değerlerini sorgulayın.

S19 — NGINX Plus Resmi Sürüm Notları

Plus CR/LTS dallarını, sürümlerini, yamalarını ve yükseltme uyumluluğu hatırlatıcılarını listeleyin.

S20 — NGINX JavaScript / njs Resmi Güvenlik Bülteni

Ekim 2026 njs 1.0.2 ve ilgili XML doğrulama, bellek tükenmesi sorunlarını içerir.

S21 — Kubernetes: Topluluk ingress-nginx resmi kullanımdan kaldırma talimatları

Projenin yeni sürümleri ve güvenlik düzeltmelerini Mart 2026’da durdurduğunu ve bakımı yapılan denetleyicinin veya Gateway API’nin taşınmasının önerildiğini unutmayın.

S22 — NGINX resmi servis kontrolü ve çevrimiçi ikili yükseltme talimatları

İşlem değiştirme kabulü için yapılandırma yeniden yükleme, yeniden başlatma ve çevrimiçi yürütülebilir dosya yükseltme yöntemlerini ayırt edin.

S23 - Devlet Güvenlik Bildirimi: Mayıs 2026 NGINX yeniden yazma güvenlik açığı

CVE-2026-42945 için geçmiş risk geçmişi ve güvenlik güncellemesi önerileri sağlayın; Doğadaki istismarla ilgili kararlar, kurumun o sırada yaptığı duyuruya ve olayla ilgili daha fazla kanıta dayanmalıdır.

S24 — F5: CVE-2026-95101 ve CVE-2026-97629 Satıcı Duyuruları

Sırasıyla HTTP/3 talep gövdesi enjeksiyonu ve otomatik TLS Bilet anahtarı rotasyonu risklerini kapsar.

S25 — F5: CVE-2026-97205 Satıcının Duyurusu

Açıklama SSI/AIO tetikleyici koşullar ve olası bellek bozulması riskleri.

NGINX güvenlik güncellemesi: yapılandırma kontrolleri, yükseltmeler ve doğrulama