Kerentanan NGINX: penyebab, perbaikan, dan verifikasi produksi

Tanggal artikel bersejarah: 2026-10-14 (tanggal pengungkapan dan rilis keamanan). Sumber diperiksa dan informasi ditambah melalui 2026-10-27.

Artikel ini diarsipkan berdasarkan tanggal acara; versi dan pembaruan rilis yang dirilis setelah 14 Oktober disertakan di bawah. Audiens: Situs web NGINX Open Source / NGINX Plus dan personel operasi dan pemeliharaan proksi terbalik, personel respons keamanan, pengelola distribusi, serta teknisi yang mengkompilasi sendiri NGINX dan memelihara modul pihak ketiga.

Artikel ini berfokus pada lima kerentanan inti NGINX yang diungkapkan dan diperbaiki secara intensif pada 14 Oktober 2026, dan juga melihat kembali kerentanan keamanan memori dan integritas permintaan yang representatif dari Mei hingga September 2026. Kontennya mencakup kondisi pemicu, penyebab tingkat kode, cakupan dampak, alur kerja remediasi, langkah-langkah mitigasi jangka pendek, implementasi patch resmi, backport ke cabang lama, dan verifikasi produksi. Referensi seperti tautan S1 ke lampiran sumber. Contoh konfigurasi hanya digunakan untuk mengilustrasikan gagasan penerapan dan audit, dan harus diverifikasi berdasarkan versi sebenarnya, warisan konfigurasi, ketergantungan, dan kapasitas bisnis sebelum penerapan.

TL;DR: Tindakan prioritas

1. Prioritaskan peningkatan keamanan. Untuk paket Sumber Terbuka nginx.org, perbarui cabang Stable 1.30 menjadi setidaknya 1.30.6 dan cabang Mainline 1.31 menjadi setidaknya 1.31.7. Pada tanggal verifikasi, 1.31.8 adalah yang terbaru Rilis Mainline. Ini adalah garis dasar cabang yang terpisah; jangan membandingkan jumlah mereka antar cabang. S1S2
2. Verifikasi instalasi distribusi berdasarkan versi paket lengkap. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 memiliki backport vendor; Debian 13 (trixie) memerlukan setidaknya 1.26.3-3+deb13u10. Saat verifikasi, paket Debian 12 (bookworm) 1.22.1-9+deb12u10 masih ditandai terpengaruh. Periksa setiap CVE; penasehat Debian 13 tidak menetapkan bahwa Debian 12 sudah diperbaiki. S13S14S15
3. Audit lima kombinasi konfigurasi: alias + rewrite + $request_filename, map + regex + evaluasi variabel, aio + ssi + include virtual, HTTP/3 dengan proxy_request_buffering on, dan ssl_session_cache shared:... dengan rotasi kunci Tiket Sesi TLS otomatis. Kehadiran arahan saja tidak menciptakan kemampuan untuk dieksploitasi; menilai jalur permintaan dan cakupan konfigurasi. S1S3S4
4. Ganti semua proses dan container lama. Jalankan nginx -t, lalu mulai ulang layanan atau lakukan penerapan bergulir dengan ketersediaan tinggi. Konfirmasikan bahwa proses master/worker lama telah keluar; nginx -s reload saja tidak membuktikan bahwa biner yang berjalan telah berubah.
5. Verifikasi titik akhir aktual: HTTP/1.1, HTTP/2, HTTP/3 jika diaktifkan, unggahan proksi dan badan permintaan API, autentikasi sertifikat mTLS, halaman SSI, dan log akses. Catat asal paket, versi, intisari gambar, proses yang berjalan, dan hasil untuk setiap titik akhir.
6. Jika peningkatan segera tidak memungkinkan, hapus kondisi pemicu yang berlaku: nonaktifkan SSI/AIO atau HTTP/3 yang rentan, tinjau referensi variabel alias/rewrite/map yang rentan, dan nilai ssl_session_tickets off; sementara untuk yang terpengaruh Layanan mTLS. WAF, ASLR, batas kecepatan dan perubahan konfigurasi hanya mencakup beberapa kondisi dan tidak dapat menggantikan patch resmi. S3S4S8S12

1. Tinjauan Kerentanan dan Penilaian Risiko

NGINX merilis 1.30.6 (Stable) dan 1.31.7 (Mainline) pada 14 Oktober 2026, memperbaiki lima masalah keamanan. Tiga melibatkan heap overflow atau penggunaan setelah bebas dan menerima skor F5 CVSS v4.0 dari 9.2 / Kritis. Dua lainnya mempengaruhi integritas permintaan HTTP/3 dan otentikasi sertifikat klien TLS. S1S2S3

Bedakan sistem pemeringkatan: nginx.org mencantumkan kelima masalah sebagai medium, sedangkan F5 CVSS v4.0 dan beberapa badan keamanan nasional mengklasifikasikan tiga masalah memori sebagai Kritis. Ini tidak berarti bahwa kelimanya mengizinkan eksekusi kode jarak jauh tanpa syarat. Konfigurasi, jangkauan lalu lintas, dan kondisi di luar kendali penyerang penting. Kerusakan memori dan RCE yang andal adalah tingkat bukti yang berbeda. S1S3S4

CVE	Masalah teknis dan kondisi pemicu yang umum	dampak inti	Evaluasi dan Pembuangan
CVE-2026-15176	alias pemetaan jalur + rewrite perubahan URI + evaluasi $request_filename	Tumpukan buffer meluap, Worker mogok; potensi RCE dalam kondisi tertentu	F5 CVSS v4.0 9.2; memprioritaskan pemecahan masalah
CVE-2026-93479	Evaluasi skrip HTTP/Stream, khususnya penangkapan regex map dan direktori root, referensi silang variabel log	Buffer yang dicadangkan ditimpa dan heap meluap; potensi RCE dalam kondisi tertentu	F5 CVSS v4.0 9.2; adalah risiko regresi setelah perbaikan sebelumnya
CVE-2026-97205	SSI termasuk virtual dan AIO/operasi asinkron; jumlah operasi yang luar biasa meluap	Gunakan-Setelah-Gratis, kerusakan Worker, kerusakan memori; potensi RCE	F5 CVSS v4.0 9.2; memerlukan konfigurasi non-default
CVE-2026-95101	HTTP/3 Bingkai tidak dikenal terfragmentasi di seluruh buffer, buffering badan permintaan proxy diaktifkan	Salah memasukkan byte non-DATA ke badan permintaan upstream, mungkin melewati batas ukuran badan permintaan	Kerentanan ini mempengaruhi integritas permintaan. Itu sendiri tidak menyediakan eksekusi kode jarak jauh (RCE).
CVE-2026-97629	Cache Sesi TLS Bersama, rotasi kunci otomatis, dan pencerminan kunci Worker	pemalsuan Tiket Sesi; bypass otentikasi sertifikat klien mungkin terjadi untuk layanan mTLS yang terpengaruh	Perhatian khusus perlu diberikan pada dampak bisnis dari otentikasi sertifikat jenis API

Skor CVSS di atas diberikan oleh F5 menggunakan v4.0; kerentanan yang sama mungkin menunjukkan tingkat keparahan yang berbeda pada nilai CVSS 3.1, nginx.org sendiri dan peringkat tingkat keparahan distribusi. S1S3S4

1.1 Prioritaskan paparan penerapan daripada skor CVE saja

Formulir penempatan	Poin-poin investigasi utama	Rekomendasi prioritas pembuangan
Proksi balik jaringan publik, termasuk rewrite yang disesuaikan, alias, dan map yang kompleks	CVE-2026-15176, CVE-2026-93479 dan menulis ulang/memetakan kerentanan dari Mei hingga Juli	P0: Audit dan perbarui segera
API / Bidang manajemen menggunakan sertifikat klien sebagai satu-satunya atau otentikasi pintu masuk utama	Tiket Sesi dan konfigurasi cache bersama CVE-2026-97629	P0: Segera konfirmasi batas otentikasi dan perbarui
Menyediakan unggahan HTTP/3 eksternal, antarmuka perubahan status, kelas transaksi API	CVE-2026-95101, terutama badan permintaan diproksi ke backend	P0/P1: Susun sesuai kepentingan bisnis
SSI Halaman dinamis atau I/O file asinkron	CVE-2026-97205	P1: Konfirmasikan kondisi kombinasi dan perbaiki sesegera mungkin
Hanya halaman statis + proksi terbalik HTTP/1.1/2 sederhana	Konfigurasi dan versi masih perlu diaudit, namun beberapa ketentuan CVE mungkin tidak ada	P1: Termasuk dalam jendela peningkatan keamanan darurat
Gunakan Komunitas Kubernetes yang sudah pensiun ingress-nginx	Proyek ini menghentikan pemeliharaan keamanan, dan risikonya tidak terbatas pada lima CVE ini	Buat rencana migrasi pengontrol individual

P0/P1 adalah saran pembuangan operasi dan pemeliharaan yang diberikan dalam artikel ini untuk paparan jaringan publik dan sensitivitas sertifikasi. Ini bukan klasifikasi resmi CVSS, juga tidak boleh menggantikan aset internal perusahaan dan mengubah penilaian risiko.

1.2 Batas dampak dan izin serangan

Kerentanan inti dalam kumpulan ini sebagian besar terletak di Bidang Data NGINX: titik masuk serangan adalah koneksi dan permintaan klien, dan dampak sebenarnya biasanya terjadi dalam proses Worker. Jika kondisi kerusakan memori yang dapat dieksploitasi terpenuhi, izin eksekusi kode umumnya dibatasi oleh pengguna yang sedang berjalan, batasan kontainer, kemampuan Linux, pemasangan dan izin jaringan Worker; potensi RCE tidak secara otomatis menyiratkan hak istimewa root atau kompromi host. S4

Namun meskipun prosesnya tidak memiliki hak istimewa, proses tersebut mungkin masih memiliki akses ke kredensial proxy, file yang dapat dibaca yang berisi kunci privat sertifikat, token layanan upstream, file sementara, API internal, dan jaringan yang dapat dijangkau. Untuk mTLS, pengabaian autentikasi itu sendiri dapat menimbulkan konsekuensi bisnis yang serius, dan tidak harus disertai dengan eksekusi kode.

2. Analisis penyebab

2.1 Memahami tiga batasan rawan kesalahan di NGINX

NGINX worker adalah proses berbasis peristiwa yang berumur panjang yang mempertahankan status permintaan, operasi asinkron, dan pengurai protokol. Kerentanan ini mencakup kendala pada tiga tingkat teknis:

1. evaluasi variabel dan ukuran memori harus konsisten: rewrite Setelah mengubah permintaan URI, pemetaan jalur harus konsisten dengan location yang saat ini efektif; ketika penerjemah skrip menghitung panjang variabel, ruang tulis harus mencakup keluaran aktual dan area yang dicadangkan.
2. Operasi asinkron harus memperpanjang siklus hidup memori yang diminta: Ketika ada pembacaan dan penulisan file yang belum selesai, menunggu cache, atau tugas thread, kumpulan memori permintaan yang relevan tidak dapat dilepaskan terlebih dahulu.
3. status protokol dan status keamanan tidak dapat dicampur atau dihilangkan: HTTP/3 Panjang lompatan bingkai yang tidak diketahui tidak dapat dianggap sebagai panjang isi permintaan DATA; TLS Semua slot kunci yang berpartisipasi dalam verifikasi tanda tangan harus diinisialisasi dan disinkronkan dengan benar selama rotasi tiket sesi.

Konten berikut didasarkan pada perbaikan hulu NGINX dan pengumuman vendor untuk menjelaskan mekanisme kegagalan yang dapat dipicu; contoh fragmen untuk analisis, bukan kode lengkap yang dapat langsung digunakan untuk memperbaiki lingkungan produksi. S5S6S7S8S9

2.2 CVE-2026-15176: Pemetaan jalur antara alias dan URI yang ditulis ulang tidak valid.

Di NGINX, location yang cocok dan alias menentukan jalur file; rewrite dapat mengubah permintaan saat ini URI. Setelah penulisan ulang, asumsi yang digunakan oleh pemetaan location asli mungkin tidak lagi berlaku.

Jalur pemrosesan yang terpengaruh tidak cukup memeriksa apakah permintaan telah ditulis ulang saat memeriksa status alias di ngx_http_map_uri_to_path(). Ketika konfigurasi terus mengevaluasi $request_filename setelah penulisan ulang, jalur mungkin dibuat dengan asumsi yang tidak sesuai dengan status URI saat ini, yang pada akhirnya memicu penulisan di luar batas ke memori heap. S5

Kombinasi umum (hanya digunakan sebagai contoh tandingan untuk audit konfigurasi, penerapan tidak disarankan):

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

Bahayanya tidak terbatas pada return: set, if, add_header, log_format, dll. juga perlu diaudit jika evaluasi $request_filename dipicu dalam proses permintaan yang sama. return pada contoh hanya membuat jalur status ini mudah dilihat, tidak dapat digunakan untuk menyimpulkan bahwa semua konfigurasi produksi akan menghasilkan overflow. S5S10

Konsekuensi serangan: Membuat permintaan dapat menyebabkan Worker dimulai ulang atau gangguan layanan; dalam kondisi seperti ASLR ditutup atau dapat dilewati, terdapat potensi RCE. Inti dari patch upstream adalah menolak untuk menyelesaikan pemetaan jalur URI yang ditulis ulang dalam konteks alias yang tidak lagi valid, daripada sekadar memperluas buffer tertentu. S5S10

2.3 CVE-2026-93479: Ketidakcocokan antara “ruang yang dipesan” dan panjang variabel sebenarnya dalam evaluasi skrip

Modul HTTP dan Stream dari NGINX memiliki evaluator skrip yang menggabungkan string literal dan nilai variabel ke dalam string hasil. Contoh aplikasi mencakup jalur dokumen HTTP root, jalur log akses, dan ekspresi variabel di Stream.

Konfigurasi tertentu dari map + ekspresi reguler memungkinkan nilai yang diambil dibaca oleh ekspresi lain sebelum variabel hasil map dievaluasi. Dikombinasikan dengan metode eksekusi skrip dengan panjang yang dicadangkan, implementasi lama akan menghitung ruang cadangan len ke dalam akumulator panjang yang dievaluasi terlebih dahulu, sehingga penghitungan penunjuk tulis selanjutnya tidak lagi konsisten dengan batas buffer. Dalam urutan evaluasi variabel tertentu, penulisan string berikutnya dapat menimpa area yang dicadangkan, menyebabkan heap overflow. S6

elemen partisipatif	Mengapa perlu diperhatikan
regex di map	Evaluasi variabel capture mungkin memiliki siklus hidup independen dan perilaku caching
Pengambilan anonim seperti $1, $2, dll.	Mudah ditimpa oleh ekspresi reguler atau ekspresi lainnya, sehingga sulit untuk melacak kepemilikannya
Variabel dalam root	Eksekusi skrip dan reservasi buffer saat memicu pembuatan jalur
log_format/jalur log dinamis	Jenis evaluasi yang sama mungkin dipicu nanti dalam permintaan
Ekspresi skrip di stream	Perbaikan hulu juga mengubah ngx_stream_script_run(). Anda tidak bisa hanya meninjau modul HTTP.

Hubungan regresi penting: Kode yang terkait dengan kerentanan ini terkait dengan perubahan sebelumnya yang memperbaiki CVE-2026-42533. DSA resmi untuk Debian 13 dengan jelas menyatakan bahwa kode yang terpengaruh dimasukkan ke dalam paket trixie melalui backport keamanan sebelumnya. Oleh karena itu, “Patch kerentanan map bulan Juli telah diinstal” tidak berarti bahwa CVE-2026-93479 bulan Oktober telah tercakup; rantai perbaikan keamanan penuh harus diperiksa. S6S14S17

Potensi risiko RCE di sini terkait dengan lingkungan perlindungan memori, dan tidak boleh diklaim bahwa regex map saja akan dapat dieksploitasi oleh penyerang anonim. S11

2.4 CVE-2026-97205: AIO Penutupan jumlah operasi yang belum selesai menyebabkan Penggunaan-Setelah-Bebas

Kerentanan ini bukan sekadar “aktifkan SSI dan Anda akan mendapatkan UAF”. Kuncinya terletak pada jumlah referensi operasi asinkron yang dimiliki oleh permintaan utama.

NGINX Gunakan r->main->blocked untuk melacak pemrosesan asinkron yang belum selesai, dalam implementasi lama hitungannya 8-bit; beberapa jalur tidak melakukan pemeriksaan batas atas sebelum menambah hitungan. Ketika permintaan utama yang sama mengumpulkan 256 operasi yang belum terselesaikan, penghitungannya mungkin berkisar dari 255 hingga 0. Proses selanjutnya akan secara keliru percaya bahwa tidak ada operasi asinkron yang mencegah pelepasan permintaan, sehingga melepaskan kumpulan memori permintaan yang masih direferensikan oleh tugas. S7

Proses kegagalan dapat dibagi menjadi:

1. Dengan mengaktifkan jalur I/O/thread asinkron terkait, halaman SSI memperkenalkan beberapa subpermintaan atau operasi baca melalui include virtual.
2. Operasi luar biasa dari permintaan utama tertentu diakumulasikan hingga batas atas yang diwakili oleh bidang hitungan.
3. Hitungan 8-bit membungkus, salah dinyatakan sebagai “tidak ada operasi yang tertunda”.
4. Kumpulan memori permintaan dilepaskan, sementara pembacaan file, tunggu cache, atau panggilan balik tugas thread masih menyimpan referensi ke sana.
5. Callback penyelesaian asinkron berikutnya mengakses memori yang dilepaskan, mengakibatkan UAF, Worker mogok, atau potensi kerusakan memori.

Perbaikan resmi menambahkan NGX_HTTP_MAX_BLOCKED 250 ke file header permintaan, dan menambahkan batasan pada filter output, pembacaan cache, dan jalur thread upstream; ketika ambang batas tercapai, operasi dengan jalur yang disinkronkan diselesaikan secara serempak, dan jika tidak dapat diproses dengan aman, penambahan lebih lanjut dari tugas yang tertunda akan ditolak. S7

penilaian penerapan: Harus dievaluasi apakah SSI, AIO, penyertaan virtual, subpermintaan, dan operasi asinkron terkait dapat terjadi dalam kombinasi dalam rantai permintaan yang sama. Ini biasanya bukan konfigurasi proksi statis biasa. aio off; atau ssi off; dapat menghapus elemen pemicu tertentu, namun dependensi fungsi bisnis harus dikonfirmasi terlebih dahulu. S4S7S25

2.5 CVE-2026-95101: HTTP/3 bingkai yang tidak diketahui bingung dengan status badan permintaan DATA

Pengurai bingkai HTTP/3 harus membedakan antara bingkai DATA (yang perlu diteruskan ke pemrosesan badan permintaan HTTP) dan bingkai tidak dikenal yang harus dilewati. Panjang frame yang tidak diketahui juga harus dipertahankan secara akurat saat melakukan fragmentasi di seluruh buffer jaringan.

Implementasi lama ngx_http_v3_parse_data() menggunakan bidang st->length untuk menyimpan “sisa jumlah byte yang harus dilewati” ketika melewatkan bingkai yang tidak diketahui, sedangkan filter badan permintaan menafsirkan bidang yang sama dengan “sisa panjang muatan DATA”. Jika frame yang tidak diketahui menjangkau beberapa panggilan parse, kumpulan byte berikutnya setelah parsing diinterupsi mungkin disalahartikan sebagai bagian dari isi permintaan. S8

Dua jenis risiko muncul:

• injeksi badan permintaan: Muatan bingkai non-DATA yang dikirimkan oleh klien dapat ditransmisikan ke aplikasi hulu, mengubah data yang sebenarnya diterima oleh backend.
• melewati batas ukuran: client_max_body_size dan batasan lainnya. Pemeriksaan yang diharapkan terkonsentrasi pada jalur DATA, dan konten yang dikonversi secara salah dapat melewati verifikasi terkait.

Skenario pemicu umum yang dijelaskan oleh pejabat tersebut adalah ketika ngx_http_v3_module menerima permintaan HTTP/3 dan meneruskan proxy_request_buffering on. Buffer badan permintaan proxy diaktifkan secara default di ngx_http_proxy_module. Oleh karena itu, reverse proxy yang mengaktifkan HTTP/3 harus diperiksa terlebih dahulu. Tidaklah tepat untuk berasumsi bahwa tidak ada kondisi pemicu hanya karena proxy_request_buffering on; tidak ditulis secara eksplisit. S8S18

Konsekuensi langsung dari kerentanan ini adalah perubahan integritas permintaan backend dan batas keamanan, yang bukan merupakan ekspresi setara dari RCE yang diselesaikan secara langsung di inti NGINX. Dampak bisnis utamanya bergantung pada cara byte ini diurai dan dipercaya di bagian hulu. S24

2.6 CVE-2026-97629: TLS Rotasi tiket meleset dari slot kunci ketiga

Dalam konfigurasi yang terpengaruh, NGINX dapat secara otomatis membuat dan memutar kunci Tiket Sesi TLS melalui cache memori bersama, memungkinkan beberapa Worker memproses kumpulan tiket yang sama.

Logika sinkronisasi yang relevan mengalokasikan 3 slot kunci untuk setiap Worker, dan callback dekripsi juga akan melintasi slot ini; tetapi implementasi lama hanya menyalin 2 slot kunci dari memori bersama setiap kali, sehingga menghasilkan nama kunci, kunci HMAC, dan AES dari slot ketiga. Kuncinya mungkin masih belum diinisialisasi. Jika pengidentifikasi kunci tiket cocok dengan status ini, materi kunci yang tidak diinisialisasi dapat digunakan untuk verifikasi dan dekripsi tanda tangan, sehingga membentuk jalur untuk membentuk sesi TLS. S9

Kombinasi penerapan berisiko tinggi biasanya:

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

Konsekuensi bisnis paling serius dari kerentanan ini adalah pada layanan yang menggunakan otentikasi sertifikat klien (mTLS) di ssl_verify_client on; dan cara lainnya, sesi pemulihan palsu dapat melewati verifikasi sertifikat klien. Keberhasilan serangan juga bergantung pada kondisi yang tidak terkendali; situs yang hanya menggunakan sertifikat HTTPS sisi server biasa dan tidak ada autentikasi sertifikat klien tidak boleh disalahartikan sebagai “penyerang dapat melewati seluruh login situs web”. S9S12

Ini adalah masalah status autentikasi sesi TLS dan tidak ada hubungannya dengan apakah kunci pribadi TLS server diretas atau apakah sertifikat CA root publik terpengaruh. S24

2.7 Bagaimana memahami DoS, RCE, bypass otentikasi dan eksploitasi yang diketahui

• DoS: Kesalahan memori menyebabkan Worker mogok atau reboot secara besar-besaran. Apakah hal ini menyebabkan ketidaktersediaan secara keseluruhan terkait dengan tekanan lalu lintas, kemampuan memulai ulang proses, waktu pemeliharaan koneksi, dan arsitektur ketersediaan tinggi.
• potensi RCE: Beberapa pengumuman menunjukkan bahwa ada kemungkinan eksekusi kode ketika ASLR ditutup atau dilewati. Ini tidak berarti bahwa rantai serangan publik yang dapat menjalankan perintah secara stabil dan universal telah terungkap. S4
• Meminta bypass injeksi/autentikasi: Ini dapat secara langsung mengubah status bisnis yang dilindungi atau meminta konten, dan tidak dapat diabaikan hanya karena tidak mendapatkan shell secara langsung.
• telah menemukan upaya serangan: CVE-2026-42945 pada bulan Mei 2026 memiliki laporan aktivitas eksploitasi di alam liar; kita tidak boleh secara langsung menyimpulkan bahwa fakta sejarah ini berarti bahwa kelima CVE pada bulan Oktober telah berhasil dieksploitasi dalam skala besar. S23

3. Perbaikan versi dan pemilihan patch

3.1 NGINX Open Source garis dasar patch resmi

cabang hulu	Versi resmi pertama mencakup lima kerentanan pada bulan Oktober	Rekomendasi pada 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Instal setidaknya 1.30.6, dan tindak lanjuti dengan versi keamanan berikutnya.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
Cabang NGINX Open Source sebelumnya	Hal ini tidak dapat dinilai hanya berdasarkan “patch kerentanan lama telah diterapkan”	Bermigrasi ke cabang yang dikelola terlebih dahulu; jika tidak, vendor diharuskan memberikan bukti formal dukungan berdasarkan CVE-by-CVE.

Ini adalah kesimpulan versi dari kode sumber hulu/cabang resmi nginx.org, dan tidak boleh digunakan untuk secara langsung menolak paket keamanan dengan perbaikan backport yang disediakan oleh vendor distribusi. Bahkan jika nilai 1.31.6 lebih besar dari 1.30.6, nilai tersebut masih lebih rendah dari garis dasar patch cabang jalur utama. S1S2

3.2 Cakupan dampak hulu dari lima CVE

Rentang berikut dicantumkan sesuai dengan teks asli buletin keamanan nginx.org dan perlu dipahami sehubungan dengan “cabang yang berjalan saat ini” dan “jalur konfigurasi sebenarnya”:

CVE	Tag upstream mempengaruhi versi	Versi tetap yang diberi label resmi
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ atau 1.31.7+, di cabangnya masing-masing
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	Sama seperti di atas
CVE-2026-97205	0.8.11–1.31.6	Sama seperti di atas
CVE-2026-95101	1.25.0–1.31.6	Sama seperti di atas
CVE-2026-97629	1.23.2–1.31.6	Sama seperti di atas

CVE-2026-93479 memiliki batasan versi pengenalan yang spesifik; tidak semua versi NGINX lama terpengaruh oleh regresi ini. Versi lama di luar rentang tersebut mungkin masih terpengaruh oleh kerentanan regex map yang lebih lama, CVE-2026-42533. S1

3.3 Ubuntu: backport distribusi (USN-8955-1)

Canonical USN-8955-1 26 Oktober 2026 menyediakan pembaruan keamanan untuk empat build Ubuntu: S13

Versi Ubuntu	nginx dan versi tetap paket sumber yang sama	Deskripsi
22.04 LTS	1.18.0-6ubuntu14.22	Ini adalah backport vendor; nomor versi upstream masih menunjukkan 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	Sama seperti di atas
26.04 LTS	1.28.3-2ubuntu1.12	Sama seperti di atas
26.10	1.30.4-7ubuntu1.1	Sama seperti di atas

Pengumuman tersebut berisi versi tetap yang sesuai dari paket homolog seperti nginx-core, nginx-extras, nginx-full, dan nginx-light. Jangan menarik kesimpulan apakah akan memperbaikinya dari bagian upstream hanya ditunjukkan oleh nginx -v. seperti Ubuntu 24.04 dan 1.24.0-2ubuntu7.19 telah ditambal oleh vendor ini, namun 1.24.0 dari sumber mana pun pada dasarnya tidak aman.

Ubuntu secara resmi juga ditandai dengan jelas bahwa CVE-2026-95101 hanya memengaruhi Ubuntu 26.04 / 26.10, dan CVE-2026-97629 hanya memengaruhi Ubuntu 24.04 / 26.04 /26.10. Berikut adalah kemasan dan cakupan fungsi Ubuntu sendiri, yang tidak dapat langsung dipromosikan ke distribusi lain. S13

3.4 Debian: Perbedaan antar versi harus diperiksa secara terpisah

Penasihat Debian DSA-6575-1 (2026-10-21) mencakup lima CVE ini dan mengidentifikasi paket nginx tetap untuk Debian 13 / trixie sebagai:

1.26.3-3+deb13u10

Namun, pada saat verifikasi laporan ini, 1.22.1-9+deb12u10 untuk Debian 12 / bookworm masih ditandai sebagai rentan oleh Debian Security Tracker. Oleh karena itu:

• Debian 13 Cukup perbarui dan terima sesuai dengan DSA-6575-1.
• Debian 12 harus memeriksa perbaikan keamanan yang disediakan oleh Pelacak Keamanan saat ini atau vendor ELTS satu per satu; sebelum perbaikan dikonfirmasi dalam pengumuman, jangan menyatakan bahwa kelima item telah diperbaiki berdasarkan keberhasilan apt upgrade.
• Paket sumber Debian mungkin membawa set patch yang tidak bergantung pada nomor versi nginx.org. Untuk build kustom, Anda perlu memeriksa set perbaikan paket kode sumber lengkap, dan Anda tidak bisa hanya menyalin satu penerapan upstream dan menganggapnya selesai.

Perbedaan di atas didasarkan pada rekam jejak DSA dan CVE. S14S15S16

3.5 NGINX Plus, njs dan Pengontrol Ingress

Produk/Komponen	Poin Penting Seleksi Keamanan dan Verifikasi
NGINX Plus (versi komersial)	Silakan lihat pengumuman dan instruksi peningkatan cabang Plus yang sesuai dengan F5. CR terbaru pada saat verifikasi adalah PLS.37.2.0.1, dan build keamanan LTS adalah PLS.37.0.7.1; versi Plus dan backport yang disertakan tidak dapat langsung digantikan oleh ambang batas 1.30/1.31 Sumber Terbuka. S19
njs / ngx_http_js_module	2026-10-14 merilis njs 1.0.2 dan memperbaiki CVE-2026-101019 dan CVE-2026-101025; jika Anda menggunakan njs, Anda juga harus memeriksa kompatibilitas modul dengan NGINX. S20
F5 NGINX Pengontrol Ingress / Gateway Fabric	Inti NGINX adalah rantai distribusi perangkat lunak yang terkait namun independen. Perbaiki kerentanan yang relevan dengan pengontrol, gambar, dan catatan rilisnya masing-masing. Anda tidak bisa begitu saja mengganti biner NGINX di Pod.
Kubernetes Komunitas kubernetes/ingress-nginx	Proyek ini dinonaktifkan pada bulan Maret 2026 dan tidak lagi menyediakan pemeliharaan keamanan baru. Anda harus merencanakan untuk bermigrasi ke pengontrol yang dikelola atau Gateway API daripada salah mengira nomor rilisnya sebagai Pengontrol Ingress F5 NGINX. S21

3.6 Patch mana yang sebaiknya Anda pilih?

Formulir penempatan	Praktik yang direkomendasikan	Bukti perbaikan
Paket DEB/RPM resmi nginx.org	Tingkatkan ke versi tetap dari cabang hulu	nginx -v/-V, sumber paket, pengumuman keamanan resmi
Repositori resmi Ubuntu/Debian	Instal paket keamanan vendor	Versi paket lengkap + status vendor USN/DSA + CVE
RHEL/Alma/Rocky/SUSE/Distribusi lainnya	Tingkatkan versi sesuai dengan buletin keamanan distribusi dan versi paket tertentu	CSAF/pengumuman vendor terkait, versi Ubuntu/Debian tidak dapat diterapkan
Gambar kontainer resmi atau khusus	Bangun kembali atau tarik gambar perbaikan yang terverifikasi dan gantikan secara bergilir	Intisari gambar, buat SBOM, jalankan ID gambar pod/kontainer
NGINX, OpenResty, Tengine yang dikompilasi sendiri atau versi yang dipatch dengan modul pihak ketiga	Memprioritaskan penggunaan versi keamanan penuh pengelola; melakukan tinjauan backport patch untuk pohon sumber target bila diperlukan	Lima perbaikan kerentanan, kompatibilitas ABI/modul, regresi unit dan bisnis

OpenResty dan Tengine adalah sistem rilis yang berbeda; tabel ini hanya menjelaskan metode verifikasi. tidak berarti bahwa semua versinya terpengaruh secara bersamaan dengan NGINX standar, dan patch kode upstream juga tidak dapat diterapkan tanpa syarat.

4. Proses perbaikan formal

4.1 Inventarisasi kejadian aktual penerimaan lalu lintas eksternal

Susun untuk setiap entri setidaknya:

• Nama domain, penyeimbangan beban/CDN/tautan proksi tepi, metode pemaparan situs asal, dan protokol jaringan yang digunakan.
• Produk NGINX (Open Source, Plus, Ingress, dll.), versi lengkap, sumber repositori paket, intisari gambar.
• nginx -V menampilkan modul bangunan dan parameter kompilasi; apakah ada modul dinamis njs, Lua, OpenResty, dan pihak ketiga.
• PID master/worker yang berjalan nyata, Unit Layanan/Container/Pod, Replika, dan Node Worker.
• Konfigurasi http/stream, server, location, include yang sebenarnya efektif.
• Apakah akan mengaktifkan HTTP/3, mTLS, SSI/AIO, jalur log dinamis, map kompleks, dan pengambilan regex.

Jangan hanya mencentang /etc/nginx/nginx.conf default. Lingkungan produksi sering kali memuat banyak situs, TLS, dan konfigurasi modul melalui include. Mungkin juga terdapat beberapa jalur instalasi NGINX atau beberapa lapisan proksi.

4.2 Periksa versi dan informasi kompilasi

# 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 melaporkan pembuatan biner yang ditemukan di jalur baris perintah; itu tidak membuktikan bahwa worker yang sedang berjalan telah memuatnya. nginx -v mungkin menghilangkan akhiran paket lengkap distribusi, jadi periksa juga manajer paket atau catatan rantai pasokan.

4.3 Ekspor konfigurasi efektif dan lakukan penyaringan statis putaran pertama

nginx -T akan menguji konfigurasi dan membuang konfigurasi gabungan. Outputnya mungkin berisi informasi sensitif seperti kredensial autentikasi, jalur kunci, nama host internal, dll. Disarankan untuk menyimpan terminal yang dikontrol dengan izin root dan izin file pribadi, dan jangan memposting file asli ke perintah pekerjaan umum:

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

Ini hanyalah pencari jalur kandidat, bukan alat penentuan otomatis CVE yang andal:

1. grep tidak dapat menentukan apakah variabel berada di location yang sama atau rantai evaluasi permintaan yang sama, juga tidak dapat menyimpulkan hubungan pewarisan konfigurasi.
2. proxy_request_buffering on, beberapa konfigurasi cache dan tiket memiliki nilai default, dan tidak menulis instruksi yang sesuai tidak berarti risikonya hilang.
3. Konfigurasi yang dihasilkan oleh proxy terbalik, CDN, sidecar kontainer, atau pengontrol mungkin berbeda dari file yang diperiksa secara manual.
4. Karakteristik NGINX Plus dan modul dinamis mungkin perlu dikonfirmasi menggunakan alat manajemen resminya masing-masing.

4.4 Menyebarkan perbaikan melalui saluran tepercaya

Debian/Ubuntu (repositori distribusi resmi):

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

Serangkaian perintah ini tidak dapat menghasilkan perbaikan keamanan yang belum tersedia. Khusus untuk Debian 12, jika paket yang ditingkatkan masih dianggap rentan oleh sistem pelacakan keamanan, diperlukan tindakan perbaikan, isolasi, atau migrasi vendor tambahan. S13S14S15

Paket resmi nginx.org:

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

Jika menggunakan OpenResty, Tengine, atau NGINX Plus yang dikompilasi sendiri, gunakan versi perbaikan yang didukung oleh pengelola terkait dan jangan mencampur nginx.org, distribusi, dan paket repositori pihak ketiga. Biner/gambar asli, konfigurasi, tanda tangan, dan manifes penerapan rollback harus dipertahankan.

Kontainer/Kubernetes: perbarui gambar yang tidak dapat diubah, rekam intisarinya, dan ganti semua replika lama dengan peluncuran bertahap. kubectl rollout status hanya mengonfirmasi bahwa pengontrol penerapan telah selesai; juga memverifikasi ringkasan gambar, perutean masuk, dan replika yang tidak sehat.

4.5 Verifikasi konfigurasi dan ganti Worker yang lama

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'

Jangan perlakukan nginx -s reload sebagai bukti bahwa biner baru sedang berjalan: pemuatan ulang konfigurasi biasa biarkan master yang lama memulai pekerja baru tanpa mengganti file yang dapat dieksekusi. NGINX mendukung prosedur peningkatan biner online khusus, tetapi memerlukan langkah dan verifikasi tambahan. Tanpa prosedur yang ditetapkan, gunakan saklar lalu lintas ketersediaan tinggi yang diikuti dengan memulai ulang layanan, atau luncurkan kontainer pengganti. S22

Jika Anda mengelola NGINX melalui soket systemd, skrip entri kontainer, atau beberapa instalasi, Anda harus memeriksa target peluncuran aktual dan jalur proses alih-alih berasumsi langsung bahwa systemctl restart nginx mencakup semua instans.

4.6 Menerima dan melakukan regresi bisnis dari pintu masuk eksternal nyata

Disarankan untuk melakukan setidaknya:

• Apakah HTTPS normal, rute yang ditulis ulang, sumber daya statis, dan halaman pemetaan alias sudah benar.
• Apakah distribusi map reguler, jalur variabel root, jalur log akses, perutean SNI/sertifikat, dan proksi Stream benar.
• Apakah unggahan normal, unggahan terpotong, permintaan API dan batas volume upstream untuk HTTP/3 (bila diaktifkan) masih sesuai yang diharapkan.
• mTLS: Permintaan sertifikat yang sah akan berhasil; sertifikat yang hilang, kedaluwarsa, atau tidak sah tetap harus ditolak, dan dimulainya kembali/koneksi ulang TLS tidak boleh mengubah izin secara tidak sengaja.
• Apakah halaman SSI dan akses file asinkron normal; log kesalahan tidak menunjukkan permintaan referensi memori yang tidak normal atau kerusakan Worker yang berulang.
• Setelah peralihan lalu lintas, proses versi lama dan replika gambar lama seharusnya sudah keluar.

Pengujian harus dilakukan di lingkungan sendiri atau yang berwenang. Tes asap permintaan normal tidak dapat membuktikan sendiri bahwa kerentanan memori telah diperbaiki; pada akhirnya, versi tetap pemasok, patch kode sumber, dan pengujian runtime harus diterima bersama untuk diterima.

5. Langkah-langkah mitigasi ketika peningkatan segera tidak memungkinkan

Bagian ini adalah opsi pengurangan risiko, bukan pengganti patch. Semua perubahan konfigurasi sementara harus dicadangkan, dijalankan nginx -t, dirilis secara batch, dan segera dibatalkan jika perlu. S3S4

5.1 Kontrol prioritas lalu lintas berdasarkan paparan eksternal

Prioritaskan pengurangan permukaan serangan layanan yang tidak dapat ditingkatkan tepat waktu: pada permukaan manajemen dan internal API Tambahkan kontrol akses sumber tepercaya, isolasi jaringan hulu, atau offline jangka pendek; menambahkan koneksi, badan permintaan, dan batasan tarif ke pintu masuk berisiko tinggi; memastikan bahwa otentikasi sumber terjadi pada NGINX terkait entri sebelum rantai pemrosesan permintaan. Perlu dicatat bahwa sebagian besar kerentanan itu sendiri terletak di NGINX Di dalam bidang data, Aturan WAF tradisional mungkin tidak secara akurat menentukan kondisi pemicu konfigurasi khusus.

5.2 alias / rewrite: hindari mengevaluasi $request_filename setelah menulis ulang

Disarankan untuk memeriksa dan menyesuaikan:

• Usahakan untuk tidak menjalankan rewrite yang akan mengubah URI secara bersamaan dengan location menggunakan alias.
• Hindari penggunaan $request_filename ketika URI telah ditulis ulang tetapi pencocokan posisi yang benar belum selesai.
• Periksa referensi variabel tidak langsung di return, set, if, add_header, format log akses, dan sertakan file.
• Gunakan root/try_files/location yang jelas bila izin usaha, namun hanya mengubah alias menjadi root. Ini juga dapat mengubah semantik jalur file, yang harus diverifikasi satu per satu.

Jangan langsung menyalin “template penulisan ulang aman” yang umum di Internet untuk menimpa konfigurasi yang ada. Awalan location dan target penulisan ulang yang berbeda menghasilkan penyambungan jalur dengan arti yang sangat berbeda. S5

5.3 map/Regex: Mengurangi pencampuran status variabel penangkapan

Disarankan untuk memprioritaskan pengambilan bernama dan membatasi cakupan propagasinya, daripada mengizinkan pengambilan anonim seperti $1 untuk digunakan kembali di jalur evaluasi regex yang berbeda seiring waktu. Misalnya:

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

Cuplikan ini hanya menunjukkan struktur kepemilikan variabel yang lebih mudah diaudit; tidak berarti telah terbukti secara independen menghilangkan semua jalur pemicu CVE-2026-93479. Secara khusus, tinjau apakah variabel tangkapan direferensikan sebelumnya oleh root atau log_format, dan apakah terdapat volatile, jalur dinamis, dan rantai evaluasi yang saling bergantung. F5/CERT merekomendasikan penggunaan tangkapan bernama dan membatasi cakupan penggunaan ke konfigurasi pencocokan reguler yang sesuai sebagai bantuan jangka pendek. S3S6

5.4 AIO + SSI: Mematikan kombinasi fungsi yang tidak diperlukan

Untuk server/jalur yang tidak memerlukan SSI atau I/O file asinkron, gunakan:

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

Dari perspektif kondisi pemicu kerentanan, menutup salah satu dari keduanya biasanya cukup untuk menghilangkan rantai spesifik yang dijelaskan; penutupan pada saat yang sama hanya berlaku untuk skenario di mana bisnis tidak bergantung pada kemampuan ini. Periksa include virtual, subpermintaan, cache, dan perilaku kumpulan thread; ketika beban proksi terbalik tinggi, mematikan AIO dapat mengubah latensi dan kinerja I/O. S7

5.5 HTTP/3 Minta injeksi tubuh: tutup sementara pintu masuk jika perlu

Nonaktifkan pendengar quic yang melibatkan HTTP/3, batalkan header respons Alt-Svc yang mengumumkan HTTP/3, dan periksa apakah lapisan tepi/penyeimbang beban masih mengirimkan permintaan QUIC langsung ke NGINX yang belum diperbaiki:

# 示意：保留 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 等配置保持不变
}

Di atas hanyalah gambaran perbedaan perubahan, bukan konfigurasi server lengkap yang dapat diaktifkan satu per satu. Sintaks pengaturan HTTP/2 terkait dengan versi NGINX; jika Anda perlu mempertahankan HTTP/2, Anda harus menggunakan http2 on; atau sintaks valid yang ada sesuai dengan versi yang sesuai, dan periksa dengan nginx -t. harus digabungkan dengan konfigurasi server yang ada sebelum penerapan, alih-alih mengganti seluruh bagian dengan bagian ini. juga memeriksa firewall UDP 443, lokasi penghentian HTTP/3 dan jalur fallback klien dari CDN/proxy depan.

Jenis mitigasi jangka pendek lainnya adalah dengan menggunakan proxy_request_buffering off; pada jalur proksi yang terpengaruh, namun hal ini akan mengubah perilaku streaming badan permintaan hulu, percobaan ulang yang gagal, dan beberapa alur kerja unggahan; hanya dapat digunakan setelah pengujian dan konfirmasi yang memadai bahwa arahan tersebut mengenai jalur proksi HTTP/3 yang terpengaruh. S8S18

5.6 TLS Tiket Sesi: Perlindungan prioritas mTLS Batas autentikasi

Jika peningkatan tidak memungkinkan dan instance bergantung pada cache sesi bersama + rotasi kunci tiket otomatis, evaluasi:

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

Hal ini dapat mematikan mekanisme Tiket Sesi TLS, sehingga menghapus jalur pemalsuan tiket yang dijelaskan dalam kerentanan ini; namun, hal ini dapat memengaruhi kinerja dimulainya kembali sesi. Anda tidak bisa begitu saja mematikan verifikasi sertifikat klien mTLS untuk “menghindari kerentanan”, karena hal itu akan langsung menghapus batas autentikasi asli. S9S12

File ssl_session_ticket_key yang eksplisit dan rotasi aman juga dapat digunakan oleh proses manajemen TLS profesional untuk menghindari kondisi yang dihasilkan secara otomatis, namun penyimpanan kunci, distribusi node penuh, rotasi, dan siklus hidup tiket lama semuanya perlu diaudit dengan cermat. Tidak disarankan untuk melakukan hardcode pada kunci jangka panjang yang dapat digunakan kembali dalam konfigurasi web biasa atau skrip untuk keadaan darurat sementara. Layanan penting yang menggunakan mTLS juga harus dipantau untuk perilaku dimulainya kembali sesi TLS dan penolakan permintaan tanpa sertifikat klien yang valid. S12

5.7 Peran sistem operasi dan perlindungan perbatasan

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

ASLR, pekerja non-root, sistem file kontainer hanya baca, izin file minimal, dan isolasi jaringan dapat mengurangi dampak potensi RCE. ASLR tidak memperbaiki heap overflow atau UAF dan tidak dapat menjamin bahwa pekerja tidak akan crash. WAF, batas tarif, dan batas ukuran badan permintaan tidak memperbaiki sinkronisasi kunci Tiket TLS. S4

5.8 Kesalahpahaman umum: Operasi ini tidak cukup untuk menyelesaikan perbaikan

Operasi umum	Mengapa itu tidak cukup?
“nginx -v terlihat relatif baru”	Cabang tempatnya, versi paket lengkap yang di-backport dari versi rilis, dan proses online tidak dicentang.
“Hanya satu intranet yang ditingkatkan”	Instans asal Worker/kontainer lama/CDN lama masih menerima permintaan
”Situs tidak menggunakan PHP/tag dinamis”	Cacat terjadi pada jalur inti NGINX atau penguraian protokol dan tidak bergantung pada eksekusi PHP.
”Membuka WAF/Cloudflare sudah cukup”	WAF tidak dapat dibuktikan memblokir semua kelemahan memori yang bergantung pada konfigurasi NGINX atau kelemahan dimulainya kembali TLS
”Sudah dibuka ASLR”	Hanya memanfaatkan mitigasi kesulitan; DoS dengan injeksi permintaan masih dimungkinkan
”HTTP/3 tidak terekspos ke jaringan publik, jadi tidak perlu upgrade sama sekali”	Empat CVE lainnya masih memerlukan evaluasi independen; dan mungkin ada hubungan langsung dengan asal usul yang tersembunyi
”Kerentanan map bulan Juli telah diperbaiki”	Oktober CVE-2026-93479 melibatkan masalah regresi evaluasi skrip berikutnya
”Menonaktifkan cache menyelesaikan semua masalah”	Hanya memengaruhi beberapa cache TLS atau skenario AIO, dan tidak mencakup alias, skrip, HTTP/3

6. Ide implementasi Patch Resmi dan poin tinjauan

Bagian ini mengikuti perbaikan NGINX upstream Oktober 2026. Cuplikan ini menggambarkan perubahan yang representatif untuk tinjauan patch; perbaikan tersebut tidak lengkap dan dapat dikompilasi secara independen. Untuk build kustom, tinjau penerapan penuh, kode dan pengujian seputarnya, dan pilih rilis lengkap yang didukung. S5S6S7S8S9

6.1 CVE-2026-15176: URI telah ditulis ulang untuk menyertakan kondisi penolakan pemetaan jalur alias

Komit upstream memodifikasi ngx_http_map_uri_to_path() di src/http/ngx_http_core_module.c:

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

fokus tinjauan: Jalur sistem file tidak dapat dilanjutkan untuk dihitung ketika URI telah berubah tetapi semantik lokasi yang sesuai dari alias tidak lagi dapat diandalkan. Ini merupakan peningkatan dari batasan pra-negara. Ini bukan pemeriksaan sederhana apakah permintaan URI berisi karakter ilegal. S5

6.2 CVE-2026-93479: Membedakan dengan benar antara panjang data keluaran dan panjang cadangan

Komit upstream memperbarui src/http/ngx_http_script.c dan src/stream/ngx_stream_script.c secara bersamaan. Niat inti dapat diringkas sebagai:

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

Di sini, pool adalah nama parameter ilustratif: ekspresi alokasi HTTP dan Stream sebenarnya berbeda. Perubahan tersebut menghitung panjang keluaran skrip terlebih dahulu, kemudian menambahkan panjang yang dicadangkan ke alokasi akhir sehingga keluaran tidak menimpa ruang yang dicadangkan. S6

Saat mengaudit dan melakukan backporting, evaluator HTTP/Stream yang sesuai juga harus dicakup; hanya memeriksa file sintaks konfigurasi map tidak dapat membuktikan bahwa cacat telah diperbaiki.

6.3 CVE-2026-97205: Tetapkan ambang batas keamanan untuk jumlah operasi asinkron 8-bit

Hulu ditambahkan pada src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

Dan tambahkan entri serupa ke pembacaan file asinkron, tunggu cache, pemfilteran keluaran, dan operasi thread:

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

fokus tinjauan: Semua jalur kode aktual yang akan menambahkan r->main->blocked harus tercakup. Anda tidak bisa begitu saja menulis konstanta ambang batas di file header. Backport juga perlu memeriksa koordinasi lengkap dari fallback sinkron, panggilan balik asinkron, dan pengembalian kesalahan untuk memastikan bahwa kebuntuan atau kebocoran referensi tidak akan disebabkan oleh penolakan tugas secara langsung. S7

6.4 CVE-2026-95101: Pertahankan status skip secara terpisah untuk frame yang tidak dikenal

Upstream menambahkan bidang skip dalam struktur status parser HTTP/3 dan melakukan pemisahan status:

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);

Kuncinya bukan untuk “menonaktifkan frame HTTP/3 yang tidak diketahui”, tetapi untuk memastikan bahwa pada beberapa pembacaan, jumlah byte yang dilewati dan panjang payload DATA selalu dikelola oleh negara independen. Peninjauan harus fokus pada sharding lintas buffer frame yang tidak diketahui, dan konsistensi akhir client_max_body_size. S8

6.5 CVE-2026-97629: Sinkronisasi susunan slot kunci TLS yang lengkap

Perubahan hulu terletak di src/event/ngx_event_openssl.c:

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

Gambar asli berisi tiga slot kunci, tetapi hanya dua slot pertama yang disalin. Sebaliknya, sinkronisasikan berdasarkan jumlah sebenarnya elemen array untuk memastikan bahwa kumpulan kunci pemungutan suara Worker konsisten dengan memori bersama. Saat meninjau, konfirmasikan juga bahwa alokasi array, inisialisasi, kunci bersama, dan logika rotasi konsisten, daripada hanya memeriksa modifikasi panjang memcpy satu kali. S9

6.6 Mengapa tidak disarankan untuk menerapkan fragmen patch yang tersebar saja?

Kelima modifikasi ini masing-masing mencakup src/http, src/stream, src/http/v3, dan src/event, dan versi yang lebih lama mungkin memiliki backport keamanan dan ekstensi tidak resmi. Backporting harus membentuk matriks pemeriksaan berikut:

Periksa objek	Apa yang harus dikonfirmasi
sumber tambalan	Pengajuan resmi, versi target yang cocok, patch lengkap dan verifikasi tanda tangan
Set tambalan asli	Tidak bertentangan dengan modifikasi historis seperti CVE-2026-42533, backport distribusi, dll.
jalur kode	Skrip HTTP + Stream, AIO/thread, HTTP/3, Tiket OpenSSL semuanya tercakup
Dikompilasi kompatibel	OpenSSL, PCRE, modul ABI, modul dinamis, dan dependensi tautan konsisten
regresi fungsional	alias penulisan ulang, log dinamis, SSI/AIO, unggahan HTTP/3, dimulainya kembali sesi mTLS
waktu proses	Semua Worker/Pod menjalankan build terverifikasi baru, tidak ada image lama yang tersisa

Untuk tim yang mengelola rilis mereka sendiri, disarankan untuk menyimpan ID patch, versi paket, log build, dan laporan regresi yang dapat diaudit untuk setiap CVE; untuk pengoperasian dan pemeliharaan biasa, solusi paling aman adalah menginstal pembaruan keamanan lengkap dari vendor.

7. Riwayat kerentanan kemunduran, cabang lama dan produk lainnya

Kerentanan inti 7.1 NGINX layak untuk dikonfirmasi secara simultan dari Mei hingga September 2026

Banyak instance NGINX yang sudah lama tidak diperbarui tidak hanya terpengaruh oleh masalah baru di bulan Oktober. Berikut ini adalah node perbaikan representatif dalam waktu dekat: S1S2

CVE	Rilis perbaikan pertama	Risiko dan kondisi utama yang memerlukan audit
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, 13 Mei	rewrite Penangkapan regex anonim dan logika penggantian memicu heap overflow, potensi RCE; ada laporan publik tentang upaya serangan di alam liar
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, 22 Mei	Pengambilan regex yang tumpang tindih dan estimasi panjang di rewrite menyebabkan overflow
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, 17 Juni	HTTP/2 Konfigurasi khusus untuk upstream atau gRPC, kondisi header permintaan besar memicu buffer overflow
CVE-2026-42530	Mainline 1.31.2, 17 Juni	HTTP/3 Penggunaan Setelah Gratis; tanda resmi mempengaruhi kisaran 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, 15 Juli	map + evaluasi variabel penangkapan regex menyebabkan heap overflow, dan patch berikutnya memiliki korelasi regresi dengan CVE-2026-93479 pada bulan Oktober
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, 15 Juli	ngx_http_slice_module Konten memori bocor dalam kondisi pembaruan variabel dan cache tertentu
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, 15 Juli	SSI terkait dengan UAF; bukan penyebab root yang sama dengan kerentanan penghitungan AIO di bulan Oktober
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, 15 September	Heap overflow terbatas dari HTTP/3 + kombinasi versi OpenSSL tertentu, terutama diwujudkan sebagai kerusakan/kerusakan memori terbatas

Kerentanan lain seperti NGINX Core, HTTP/2, charset, dan SMTP yang diumumkan pada tahun 2026 juga harus diselidiki menurut buletin keamanan resmi; tabel ini sengaja berfokus pada peristiwa umum yang paling relevan dengan penerapan proksi terbalik NGINX yang dapat dilihat publik saat ini dan memiliki implikasi keamanan memori atau integritas permintaan. tidak semua CVE pada tahun 2026. Daftar. S1

Mengapa memberi perhatian khusus pada CVE-2026-42945

Terdapat buletin keamanan dari lembaga pemerintah yang mencatat aktivitas eksploitasi di alam liar dan informasi kode eksploitasi publik untuk kerentanan rewrite ini pada bulan Mei. Oleh karena itu, untuk instance yang sudah lama tidak ditambal dari bulan Mei hingga saat ini dan memiliki penulisan ulang ekspresi reguler kompleks yang terbuka di jaringan publik, selain menyelesaikan perbaikan, kerusakan Worker yang tidak normal, log akses, dan perubahan mencurigakan pada saat itu juga harus ditinjau. S23

“Terjadi upaya serangan” tidak secara otomatis membuktikan bahwa penyerang telah menjalankan perintah dengan andal pada setiap target; ketika respons terhadap insiden dilibatkan, indikator-indikator kompromi dan kegagalan proses harus diselidiki secara terpisah dari bukti nyata mengenai peningkatan atau kegigihan hak istimewa.

7.2 Remediasi untuk versi lama dan backport distribusi

NGINX Cabang yang berbeda memiliki siklus dukungannya sendiri dan waktu pengenalan kerentanan yang berbeda. Lima patch baru tidak dapat diluncurkan ke semua pohon sumber awal tanpa peninjauan.

adegan	Strategi yang direkomendasikan
Versi rilis telah mengumumkan patch keamanan lengkap	Gunakan paket vendor dan dokumentasikan versi paket lengkap; hindari mengganti dengan biner kosong hulu yang tidak kompatibel
Debian 12 dan rilis lain yang terpengaruh yang belum tercakup oleh semua CVE dalam batch ini	Mengirimkan perintah kerja berisiko, membatasi paparan eksternal, dan memeriksa status pemasok/ELTS; bermigrasi atau menggunakan rantai rilis pemeliharaan yang dapat diverifikasi bila diperlukan
Cabang-cabang bersejarah yang telah mengakhiri dukungan hulu	Prioritaskan migrasi ke versi yang didukung; jika backporting jangka pendek diperlukan, pengelola akan mengevaluasi ketergantungan dan kompatibilitas patch, dan menulis pengujian lengkap.
Dilengkapi dengan garpu NGINX (OpenResty, Tengine, gateway khusus)	Pertama-tama tentukan apakah jalur kode yang sesuai disertakan, lalu gunakan pernyataan keamanan pengelola fork. Itu tidak bisa secara langsung setara dengan versi upstream.
Patch keamanan menyebabkan perubahan pada fungsi bisnis	Mengadopsi peluncuran bertahap, peralihan lalu lintas antar versi, dan adaptasi konfigurasi; tidaklah tepat untuk memulihkan versi jaringan publik yang tidak diperbaiki tanpa isolasi.

7.3 Remediasi terpisah untuk njs, Ingress, dan NGINX Core

• njs: Selain program utama NGINX, Anda juga perlu memeriksa versi modul JavaScript NGINX itu sendiri. njs 1.0.2 memperbaiki kehabisan memori penguraian XML Oktober 2026 dan masalah inkonsistensi validasi XML dengan atribut referensi entitas. Untuk penerapan yang terkait dengan verifikasi tanda tangan XML menggunakan nginx-saml, Anda harus membaca lebih lanjut instruksi resmi njs untuk skenario plugin. S20
• F5 NGINX Plus / NGINX Ingress Controller: Selain itu, pengontrol dan Gateway Fabric masing-masing mungkin memiliki buletin keamanan tambahan, versi kemasan berbeda, dan kerentanan kebijakan unik. Mengupgrade satu lapisan tidak berarti memperbarui lapisan lainnya secara otomatis. S19
• Komunitas Kubernetes ingress-nginx: Pejabat Kubernetes telah mengumumkan bahwa pengontrol menghentikan pemeliharaan pada bulan Maret 2026, dan gudangnya tidak dapat disamakan dengan pengontrol F5. Bisnis yang terkena dampak harus merencanakan migrasi yang lancar dan memverifikasi anotasi Ingress dan perbedaan semantik Gateway API daripada menunggu versi keamanan baru. S21

8. Kriteria penerimaan dan pemeriksaan lanjutan

Direkomendasikan agar daftar berikut digunakan sebagai syarat penerimaan perubahan perintah kerja:

Proyek	Standar kualifikasi	Bukti yang bisa disimpan
Cakupan aset dan portal	Semua instans eksternal dan terhubung langsung yang dapat melewati CDN telah diinventarisasi.	Nama domain, LB, IP, daftar Pod/kontainer
Sumber paket dan cakupan perbaikan	Gunakan versi yang dikonfirmasi untuk mencakup semua CVE yang berlaku	Penasihat keamanan hulu, USN/DSA, versi paket, intisari gambar
proses lama keluar	Semua master/worker/kontainer lama telah diganti	PID/waktu mulai, status penerapan bergulir, gambar yang sedang berjalan
Audit konfigurasi	Kombinasi yang berisiko tinggi telah dihilangkan atau ditutupi oleh patch, dan hubungan warisan telah diverifikasi	ringkasan yang disunting dan catatan audit nginx -T
TLS/mTLS	Lulus sertifikat tepercaya; sertifikat yang tidak sah atau hilang ditolak; dimulainya kembali sesi tidak melewati otentikasi	Tes otorisasi negatif/positif, hasil tes TLS terkontrol
Badan permintaan HTTP/3	Aktifkan jalur diperbaiki; badan permintaan hulu dan pembatasan berperilaku dengan benar	HTTP/3, unggahan proxy, uji regresi batas volume
SSI/AIO	Fungsinya memenuhi persyaratan, Worker tidak memiliki pembatalan abnormal	Regresi bisnis, pemantauan tingkat kerusakan dan kesalahan
Pemantauan operasi dan pemeliharaan	Tidak ada pengecualian yang jelas 5xx, SIGSEGV, proses keluar berulang kali	Indikator dan log layanan sebelum dan sesudah perubahan
Strategi pengembalian	Jika rollback diperlukan, pertama-tama batasi paparan dan pertahankan batas keamanan	Ubah Perintah, Arus Darurat, dan Rencana Karantina
siklus hidup selanjutnya	Tentukan langganan buletin keamanan, frekuensi pembaruan kontainer, dan rencana migrasi cabang	Tingkatkan buku besar, orang yang bertanggung jawab, dan tanggal audit berikutnya

8.1 Apa yang harus Anda fokuskan dalam log dan status berjalan?

Memecahkan masalah ketidaknormalan pada server yang telah lama terekspos worker process exited on signal 、 SIGSEGV , lonjakan kegagalan permintaan, agregasi akses sumber yang tidak normal, keberhasilan dimulainya kembali/otentikasi sesi TLS yang tidak terduga, dan perilaku isi permintaan backend yang tidak normal. Indikator-indikator ini hanya dapat digunakan sebagai petunjuk investigasi dan bukan merupakan bukti yang cukup untuk membuktikan secara langsung bahwa CVE tertentu telah dieksploitasi. ;Kurangnya log yang relevan tidak membuktikan bahwa belum terjadi serangan.

8.2 Kata-kata kesimpulan risiko akhir yang direkomendasikan

Laporan penerimaan untuk lingkungan produksi harus menggunakan ekspresi tepat berikut:

Pintu masuk layanan eksternal NGINX dan sumber paket perangkat lunak telah diidentifikasi. Semua instance yang berlaku telah ditingkatkan ke versi keamanan resmi upstream, atau backport yang dikonfirmasi oleh vendor rilis telah selesai; Worker lama dan container lama telah diganti. Alias/rewrite/map, AIO/SSI, isi permintaan HTTP/3 dan konfigurasi terkait Tiket Sesi TLS/mTLS telah diaudit dan lulus uji fungsional, autentikasi, dan regresi integritas permintaan. Untuk instansi yang belum menyelesaikan peningkatan, daftarkan juga area paparan, tindakan kompensasi, penanggung jawab, dan tenggat waktu penyelesaian.

Jika patch untuk Debian 12 atau rilis lainnya masih belum lengkap, tidak pantas untuk menilai seluruh formulir penerimaan sebagai “selesai”; CVE yang belum terselesaikan, apakah ada konfigurasi pemicu yang sesuai, status isolasi dan rute peningkatan akhir harus dicatat dengan jelas.

---

Lampiran: Sumber dan tautan yang dikutip

Deskripsi: Angka [Sx] dalam teks sama dengan bagian ini. Hal berikut ini memberikan prioritas pada pengumuman keamanan proyek hulu, penerapan kode, pengumuman rilis pemasok, dan informasi badan keamanan nasional. Tingkat keparahan kerentanan yang dikutip dijelaskan sesuai dengan kriteria pemeringkatan masing-masing organisasi penerbit; tanggal verifikasi data adalah 27 Oktober 2026.

S1 — Buletin Keamanan Resmi NGINX Open Source

• https://nginx.org/en/security_advisories.html

Berisi versi hulu yang terpengaruh, cabang perbaikan, dan tingkat keparahan resmi dari lima CVE bulan Oktober, dan juga mencakup riwayat kerentanan hingga tahun 2026.

S2 — Catatan rilis versi resmi NGINX

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

Konfirmasikan 1.30.6 / 1.31.7 dari 2026-10-14, 1.31.8 dari 2026-10-21, dan pencapaian rilis keamanan penting dari Mei hingga September.

S3 - Badan Keamanan Siber Singapura: F5 NGINX Tiga Kerentanan Kritis

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

Deskripsi skor CVSS v4.0 9.2, kondisi konfigurasi yang diperlukan, dan rekomendasi mitigasi sementara untuk CVE-2026-15176, CVE-2026-93479, dan CVE-2026-97205.

S4 - NHS Inggris: F5 NGINX Penasihat risiko tinggi

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

Menjelaskan dampak DoS / potensi RCE dari masalah keamanan memori, dan batasan seperti ASLR dimatikan atau dilewati.

S5 — Komit sumber resmi: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

Sesuai dengan pemeriksaan status alias dan r->uri_changed di ngx_http_map_uri_to_path().

S6 — Komit sumber resmi: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

Sesuai dengan panjang skrip HTTP/Stream dan logika alokasi buffer yang dicadangkan.

S7 - Komit sumber resmi: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

Sesuai dengan ambang batas hitungan r->main->blocked NGX_HTTP_MAX_BLOCKED 250 dan fallback jalur asinkron.

S8 — Komit sumber resmi: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

Pemisahan status sesuai dengan panjang sisa bingkai HTTP/3 yang tidak diketahui dan panjang isi permintaan DATA.

S9 — Komit sumber resmi: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

Sesuai dengan semua slot kunci selama sinkronisasi rotasi Tiket Sesi TLS.

S10 — F5: Pengumuman Vendor CVE-2026-15176

• https://my.f5.com/manage/s/article/K000162416

Cantumkan faktor pemicu seperti alias, rewrite, $request_filename dan log akses.

S11 — F5: Pengumuman Vendor CVE-2026-93479

• https://my.f5.com/manage/s/article/K000162607

Daftar tangkapan regex peta, jalur root, dan log kondisi evaluasi variabel.

S12 — dokumentasi modul NGINX resmi TLS/SSL

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

Deskripsi ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key dan otentikasi sertifikat klien dan instruksi lainnya.

S13 — Penasihat keamanan: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Menyediakan paket perangkat lunak lengkap versi tetap dan cakupan distribusi Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Penasihat keamanan: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Konfirmasikan paket perbaikan keamanan 1.26.3-3+deb13u10 untuk Debian 13 / trixie, dan catat asosiasi backport untuk CVE-2026-93479.

S15 — Pelacakan kerentanan: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Digunakan untuk memverifikasi status perbaikan distribusi Debian 12 / bookworm dan Debian 13 / trixie. Status ini dapat berubah seiring dengan pembaruan keamanan di masa mendatang.

S16 — Pelacakan kerentanan: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

Konfirmasi tambahan tentang status keamanan kerentanan HTTP/3 di berbagai cabang Debian.

S17 — Penasihat keamanan: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

Pemahaman tambahan tentang korelasi antara kerentanan regresi bulan Oktober dan perbaikan CVE-2026-42533 bulan Juli.

S18 — Dokumen modul proxy terbalik resmi NGINX

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

Kueri semantik dan nilai default konfigurasi seperti proxy_request_buffering, client_max_body_size, alias, aio, dll.

S19 — Catatan Rilis Resmi NGINX Plus

• https://docs.nginx.com/nginx/releases/

Daftar Plus CR/LTS cabang, versi, patch, dan pengingat kompatibilitas peningkatan.

S20 — Buletin Keamanan Resmi JavaScript NGINX / njs

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

Berisi njs 1.0.2 Oktober 2026 dan validasi XML terkait, masalah kehabisan memori.

S21 — Kubernetes: Instruksi pensiun resmi Komunitas ingress-nginx

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

Perlu diperhatikan bahwa proyek ini menghentikan rilis baru dan perbaikan keamanan pada bulan Maret 2026, dan disarankan untuk memigrasikan pengontrol yang dikelola atau Gateway API.

S22 — Kontrol layanan resmi NGINX dan instruksi peningkatan biner online

• https://nginx.org/en/docs/control.html

Bedakan antara pemuatan ulang konfigurasi, restart, dan metode pemutakhiran file yang dapat dieksekusi secara online untuk penerimaan peralihan proses.

S23 - Pemberitahuan Keamanan Pemerintah: Mei 2026 NGINX menulis ulang kerentanan

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

Memberikan latar belakang risiko historis dan saran pembaruan keamanan untuk CVE-2026-42945; penilaian terkait eksploitasi di alam liar harus didasarkan pada pengumuman lembaga pada saat itu dan bukti insiden lebih lanjut.

S24 — F5: Pengumuman Vendor CVE-2026-95101 dan CVE-2026-97629

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

Menjamin risiko masing-masing injeksi badan permintaan HTTP/3 dan rotasi kunci Tiket TLS otomatis.

S25 — F5: Pengumuman Vendor CVE-2026-97205

• https://my.f5.com/manage/s/article/K000162608

Deskripsi SSI/AIO memicu kondisi dan potensi risiko kerusakan memori.

Pembaruan keamanan NGINX: pemeriksaan konfigurasi, peningkatan, dan verifikasi