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
- 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
- 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+deb13u10gerektirir. Doğrulama sırasında Debian 12 (bookworm) paketi1.22.1-9+deb12u10hâlâ etkilenmiş olarak işaretleniyor. Her CVE’yi kontrol edin; Debian 13 tavsiye belgesi, Debian 12’nin sabit olduğunu kanıtlamaz. S13S14S15 - Beş yapılandırma kombinasyonunu denetleyin:
alias + rewrite + $request_filename,map+ normal ifade + değişken değerlendirme,aio + ssi + include virtual, HTTP/3 ileproxy_request_buffering onve otomatik TLS Oturum Bileti anahtar rotasyonu ilessl_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 - 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 reloadtek başına çalışan ikili programın değiştiğini kanıtlamaz. - 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.
- 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/mapdeğişken referanslarını inceleyin ve etkilenenler için geçicissl_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
| CVE | Teknik sorunlar ve tipik tetikleme koşulları | çekirdek etki | Değerlendirme ve İmha |
|---|---|---|---|
| CVE-2026-15176 | alias yol eşleme + rewrite değişiklik URI + değerlendirme $request_filename | Yığın arabellek taşması, Worker çökmesi; belirli koşullar altında potansiyel RCE | F5 CVSS v4.0 9.2; sorun gidermeye öncelik verin |
| CVE-2026-93479 | HTTP/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 RCE | F5 CVSS v4.0 9.2; önceki onarımlardan sonra gerileme riski var |
| CVE-2026-97205 | SSI 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 RCE | F5 CVSS v4.0 9.2; varsayılan olmayan yapılandırma gerektirir |
| CVE-2026-95101 | HTTP/3 Bilinmeyen çerçeve arabellekler arasında parçalanmış, proxy istek gövdesi arabelleğe alma etkin | DATA 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-97629 | Paylaşılan TLS Oturum Önbelleği, otomatik anahtar yönlendirme ve Worker anahtar yansıtma | Oturum Bileti sahteciliği; etkilenen mTLS hizmeti için istemci sertifikası kimlik doğrulamasını atlama meydana gelebilir | API 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 formu | Temel araştırma noktaları | İmha önceliği önerileri |
|---|---|---|
Özelleştirilmiş rewrite, alias ve karmaşık map dahil genel ağ ters proxy’si | Mayıs’tan Temmuz’a kadar CVE-2026-15176, CVE-2026-93479 ve güvenlik açıklarını yeniden yazma/haritalama | P0: Hemen denetleyin ve güncelleyin |
| API / İstemci sertifikasını tek veya ana giriş kimlik doğrulaması olarak kullanan yönetim düzlemi | CVE-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ın | CVE-2026-95101, özellikle istek gövdesi arka uçta proxy olarak kullanılır | P0/P1: İşin önemine göre düzenleyin |
| SSI Dinamik sayfa veya eşzamansız dosya G/Ç | CVE-2026-97205 | P1: 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 proxy | Yapılandırmanın ve sürümün hâlâ denetlenmesi gerekiyor ancak bazı CVE koşulları eksik olabilir | P1: Acil durum güvenlik yükseltme penceresine dahildir |
| Kullanımdan kaldırılan Kubernetes Topluluğu ingress-nginx’yi kullanın | Proje güvenlik bakımını durduruyor ve riskler bu beş CVE ile sınırlı değil | Bireysel 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:
- değişken değerlendirmesi ve bellek boyutu tutarlı olmalıdır:
rewriteURI isteğini değiştirdikten sonra, yol eşlemesi şu anda etkin olanlocationile 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. - 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.
- 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ı unsurlar | Neden dikkat etmeye değer? |
|---|---|
map’deki normal ifade | Yakalama 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şkenler | Yol oluşturmayı tetiklerken komut dosyası yürütme ve arabellek rezervasyonu |
log_format/Dinamik günlük yolu | Aynı türde değerlendirme daha sonra talepte tetiklenebilir |
stream’deki komut dosyası ifadeleri | Yukarı 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:
- İlgili eşzamansız G/Ç/iş parçacığı yolu etkinleştirildiğinde, SSI sayfası,
include virtualaracılığıyla birden fazla alt istek veya okuma işlemi sunar. - Belirli bir ana isteğin bekleyen işlemleri, sayım alanının temsil ettiği üst sınıra kadar toplanır.
- Yanlış bir şekilde “bekleyen işlem yok” olarak ifade edilen 8 bitlik sayım tamamlandı.
- 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.
- 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_sizeve 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ış şubesi | Ekim ayında beş güvenlik açığını kapsayan ilk resmi sürüm | 2026-10-27 itibarıyla öneriler |
|---|---|---|
| Stable 1.30.x | 1.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.x | 1.31.7(2026-10-14) | 1.31.8(2026-10-21) |
| Önceki NGINX Open Source şubesi | Yalnı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:
| CVE | Yukarı akış etiketleri etkilenen sürümler | Resmi olarak etiketlenmiş sabit sürüm |
|---|---|---|
| CVE-2026-15176 | 0.1.29–1.31.6 | 1.30.6+ veya 1.31.7+, ilgili dallarında |
| CVE-2026-93479 | 1.30.0–1.30.5,1.31.2–1.31.6 | Yukarıdakiyle aynı |
| CVE-2026-97205 | 0.8.11–1.31.6 | Yukarıdakiyle aynı |
| CVE-2026-95101 | 1.25.0–1.31.6 | Yukarıdakiyle aynı |
| CVE-2026-97629 | 1.23.2–1.31.6 | Yukarı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 versiyonu | nginx ve aynı kaynak paketinin sabit versiyonu | Açıklama |
|---|---|---|
| 22.04 LTS | 1.18.0-6ubuntu14.22 | Bu bir satıcı desteğidir; yukarı akış sürüm numarası hala 1.18.0’yi gösteriyor |
| 24.04 LTS | 1.24.0-2ubuntu7.19 | Yukarıdakiyle aynı |
| 26.04 LTS | 1.28.3-2ubuntu1.12 | Yukarıdakiyle aynı |
| 26.10 | 1.30.4-7ubuntu1.1 | Yukarı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şenler | Gü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_module | 2026-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-nginx | Proje 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 uygulamalar | Onarım kanıtı |
|---|---|---|
| nginx.org resmi DEB/RPM paketi | Yukarı akış şubesinin sabit sürümüne yükseltme | nginx -v/-V, paket kaynağı, resmi güvenlik duyurusu |
| Ubuntu/Debian resmi veri deposu | Satıcı güvenlik paketlerini yükleyin | Tam paket sürümü + satıcı USN/DSA + CVE durumu |
| RHEL/Alma/Rocky/SUSE/Diğer dağıtımlar | Belirli 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örselleri | Doğrulanmış onarım görüntüsünü yeniden oluşturun veya çekin ve sürekli olarak değiştirin | Gö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ümler | Bakı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ştirin | Beş 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,includekonfigürasyonları. - HTTP/3, mTLS, SSI/AIO, dinamik günlük yolu, karmaşık
mapve 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:
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.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.- Ters proxy’ler, CDN, konteyner sepetleri veya denetleyiciler tarafından oluşturulan yapılandırmalar, manuel olarak incelenen dosyalardan farklı olabilir.
NGINX Plusve 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
aliaseşleme sayfaları doğru mu? - Normal
mapdağı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:
aliaskullanaraklocationile aynı anda URI’yi değiştirecekrewriteişlemini gerçekleştirmemeye çalışın.- URI yeniden yazıldığında ancak doğru konum eşleşmesi henüz tamamlanmadığında
$request_filenamekullanmaktan 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ızlocationkullanın, ancak yalnızcaalias’yirootolarak 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şlemler | Neden 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 et | Neyin doğrulanması gerekiyor? |
|---|---|
| yama kaynağı | Resmi gönderim, eşleşen hedef sürüm, tam yama ve imza doğrulaması |
| Orijinal yama seti | CVE-2026-42533, dağıtım destek portu vb. gibi geçmiş değişikliklerle çelişmez. |
| kod yolu | HTTP + Stream komut dosyası, AIO/iş parçacığı, HTTP/3, OpenSSL Bilet’in tümü kapsanmaktadır |
| Derlenmiş uyumlu | OpenSSL, PCRE, modül ABI, dinamik modül ve bağlantı bağımlılıkları tutarlıdır |
| fonksiyonel regresyon | alias 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-42945 | Stable 1.30.1 / Mainline 1.31.0, 13 Mayıs | rewrite 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-9256 | Stable 1.30.2 / Mainline 1.31.1, 22 Mayıs | rewrite’de örtüşen normal ifade yakalama ve uzunluk tahmini taşmaya neden oluyor |
| CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, 17 Haziran | HTTP/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-42530 | Mainline 1.31.2, 17 Haziran | HTTP/3 Ücretsiz Kullanım Sonrası; resmi marka etkilenen aralık 1.31.0–1.31.1 |
| CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 15 Temmuz | map + 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-60005 | Stable 1.30.4 / Mainline 1.31.3, 15 Temmuz | ngx_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-56434 | Stable 1.30.4 / Mainline 1.31.3, 15 Temmuz | SSI, UAF ile ilgilidir; Ekim ayındaki AIO sayma güvenlik açığıyla aynı root nedeni değil |
| CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, 15 Eylül | HTTP/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ı duyurdu | Satı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ümler | Riskli 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 şubeler | Desteklenen 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çar | Aş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-samlkullanı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:
| Proje | Yeterlilik 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ın | Yukarı 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ştirildi | PID/başlangıç zamanı, sürekli dağıtım durumu, çalışan görüntü |
| Yapılandırma denetimi | Yü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/mTLS | Güvenilir sertifikalar geçer; geçersiz veya eksik sertifikalar reddedilir; oturumun sürdürülmesi kimlik doğrulamayı atlamaz | Negatif/pozitif yetkilendirme testi, kontrollü TLS test sonuçları |
| HTTP/3 istek gövdesi | Sabit yolu etkinleştir; yukarı akış istek gövdesi ve azaltma doğru davranıyor | HTTP/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 izleme | Belirgin bir istisna yok 5xx, SIGSEGV, işlem tekrar tekrar çıkıyor | Değişikliklerden önceki ve sonraki hizmet göstergeleri ve günlükler |
| Geri alma stratejisi | Geri alma gerekliyse öncelikle maruz kalmayı sınırlayın ve güvenlik sınırlarını koruyun | Sipariş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ı belirleyin | Yü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
- https://nginx.org/en/docs/http/ngx_http_proxy_module.html
- https://nginx.org/en/docs/http/ngx_http_core_module.html
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ı
- https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
- https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/
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