NGINX vulnerabilities: causes, fixes and production verification

Historical article date: 2026-10-14 (disclosure and security release date). Sources checked and information supplemented through 2026-10-27.

This article is archived by event date; version and release updates released after October 14 are included below. Audience: NGINX Open Source / NGINX Plus website and reverse proxy operation and maintenance personnel, security response personnel, distribution maintainers, as well as engineers who self-compile NGINX and maintain third-party modules.

This article focuses on the five NGINX core vulnerabilities that were disclosed and intensively fixed on October 14, 2026, and also looks back at the representative memory safety and request integrity vulnerabilities from May to September 2026. The content covers trigger conditions, code-level causes, impact scope, remediation workflow, short-term mitigation measures, official patch implementation, backports to older branches and production verification. References such as S1 link to the source appendix. Example configurations is only used to illustrate the deployment and auditing ideas, and should be verified based on the actual version, configuration inheritance, dependencies, and business capacity before implementation.

TL;DR: Priority actions

1. Prioritize security upgrades. For nginx.org Open Source packages, update the Stable 1.30 branch to at least 1.30.6 and the Mainline 1.31 branch to at least 1.31.7. At the verification date, 1.31.8 is the latest Mainline release. These are separate branch baselines; do not compare their numbers across branches. S1S2
2. Verify distribution installations by full package version. Ubuntu 22.04 / 24.04 / 26.04 / 26.10 have vendor backports; Debian 13 (trixie) requires at least 1.26.3-3+deb13u10. At verification, Debian 12 (bookworm) package 1.22.1-9+deb12u10 is still marked affected. Check each CVE; the Debian 13 advisory does not establish that Debian 12 is fixed. S13S14S15
3. Audit five configuration combinations: alias + rewrite + $request_filename, map + regex + variable evaluation, aio + ssi + include virtual, HTTP/3 with proxy_request_buffering on, and ssl_session_cache shared:... with automatic TLS Session Ticket key rotation. The presence of a directive alone does not establish exploitability; assess the request path and configuration scope. S1S3S4
4. Replace all old processes and containers. Run nginx -t, then restart the service or perform a high-availability rolling deployment. Confirm that old master/worker processes have exited; nginx -s reload alone does not prove that the running binary has changed.
5. Verify actual endpoints: HTTP/1.1, HTTP/2, HTTP/3 if enabled, proxied uploads and API request bodies, mTLS certificate authentication, SSI pages and access logs. Record package provenance, version, image digest, running processes and results for each endpoint.
6. If an immediate upgrade is impossible, remove applicable trigger conditions: disable unnecessary SSI/AIO or HTTP/3, review vulnerable alias/rewrite/map variable references, and assess temporary ssl_session_tickets off; for affected mTLS services. WAF, ASLR, rate limits and configuration changes cover only some conditions and cannot replace official patches. S3S4S8S12

1. Vulnerability Overview and Risk Judgment

NGINX released 1.30.6 (Stable) and 1.31.7 (Mainline) on October 14, 2026, fixing five security issues. Three involve heap overflows or use-after-free and received F5 CVSS v4.0 scores of 9.2 / Critical. The other two affect HTTP/3 request integrity and TLS client certificate authentication. S1S2S3

Distinguish the rating systems: nginx.org lists all five issues as medium, while F5 CVSS v4.0 and some national security agencies classify the three memory issues as Critical. This does not mean that all five allow unconditional remote code execution. Configuration, traffic reachability and conditions outside an attacker’s control matter. Memory corruption and reliable RCE are different levels of evidence. S1S3S4

CVE	Technical issues and typical trigger conditions	core impact	Evaluation and Disposal
CVE-2026-15176	alias path mapping + rewrite change URI + evaluation $request_filename	Heap buffer overflow, Worker crash; potential RCE under certain conditions	F5 CVSS v4.0 9.2; prioritize troubleshooting
CVE-2026-93479	HTTP/Stream script evaluation, especially map regex capture and root directory, log variable cross-reference	The reserved buffer is overwritten and the heap overflows; potential RCE under certain conditions	F5 CVSS v4.0 9.2; is a regression risk after previous repairs
CVE-2026-97205	SSI virtual includes and AIO/asynchronous operation; outstanding operation count overflow	Use-After-Free, Worker crash, memory corruption; potential RCE	F5 CVSS v4.0 9.2; requires non-default configuration
CVE-2026-95101	HTTP/3 Unknown frame is fragmented across buffers, proxy request body buffering is enabled	Incorrectly injecting non-DATA bytes into the upstream request body, possibly bypassing the request body size limit	This vulnerability affects request integrity. It does not itself provide remote code execution (RCE).
CVE-2026-97629	Shared TLS Session Cache, automatic key rotation and Worker key mirroring	Session Ticket forgery; client certificate authentication bypass may occur for the affected mTLS service	Special attention needs to be paid to the business impact of certificate authentication type API

The above CVSS score is given by F5 using v4.0; the same vulnerability may show different severity in CVSS 3.1, nginx.org own grades and distribution severity ratings. S1S3S4

1.1 Prioritize deployment exposure rather than CVE scores alone

Deployment form	Key investigation points	Disposal priority recommendations
Public network reverse proxy, including customized rewrite, alias, and complex map	CVE-2026-15176, CVE-2026-93479 and rewrite/map vulnerabilities from May to July	P0: Audit and update immediately
API / Management plane using client certificate as the only or main entrance authentication	Session Ticket and shared cache configuration of CVE-2026-97629	P0: Immediately confirm the authentication boundary and update
Provide external HTTP/3 upload, status change interface, transaction class API	CVE-2026-95101, especially the request body is proxied to the backend	P0/P1: Arrange according to business importance
SSI Dynamic page or asynchronous file I/O	CVE-2026-97205	P1: Confirm the combination conditions and repair as soon as possible
Only static pages + simple HTTP/1.1/2 reverse proxy	Configuration and version still need to be audited, but some CVE conditions may be missing	P1: Included in the emergency security upgrade window
Use retired Kubernetes Community ingress-nginx	The project stops security maintenance, and the risks are not limited to these five CVEs	Make an individual controller migration plan

P0/P1 is the operation and maintenance disposal suggestions given in this article for public network exposure and certification sensitivity. It is not an official CVSS classification, nor should it replace the enterprise’s internal asset and change risk assessment.

1.2 Impact boundary and attack permissions

The core vulnerabilities in this batch are mainly located in NGINX Data Plane: the attack entry point is client connection and request, and the actual impact usually occurs in the Worker process. If the exploitable conditions for memory corruption are met, the code execution permission is generally restricted by the running user, container constraints, Linux capability, mounting and network permissions of the Worker; potential RCE does not automatically imply root privileges or host compromise. S4

But even if the process is non-privileged, it may still have access to proxy credentials, readable files containing certificate private keys, upstream service tokens, temporary files, internal API, and reachable networks. For mTLS, authentication bypass itself can be a serious business consequence, and does not necessarily have to be accompanied by code execution.

2. Cause analysis

2.1 Understand the three error-prone boundaries in NGINX

An NGINX worker is a long-lived, event-driven process that maintains request status, asynchronous operations and protocol parsers. This vulnerability embodies constraints at three engineering levels:

1. variable evaluation and memory size must be consistent: rewrite After changing the request URI, the path mapping must be consistent with the currently effective location; when the script interpreter calculates the variable length, the write space must cover the actual output and reserved areas.
2. Asynchronous operations must extend the life cycle of the requested memory: When there are unfinished file reading and writing, cache waiting or thread tasks, the relevant request memory pool cannot be released in advance.
3. protocol status and security status cannot be mixed or omitted: HTTP/3 The length of unknown frame skipping cannot be regarded as DATA request body length; TLS All key slots participating in signature verification must be correctly initialized and synchronized during session ticket rotation.

The following content is based on the NGINX upstream fix commit and vendor announcement to explain the failure mechanism that can be triggered; the example fragment is for analysis, is not the complete code that can be directly used to repair the production environment. S5S6S7S8S9

2.2 CVE-2026-15176: The path mapping between alias and rewritten URI is invalid.

In NGINX, the matched location and its alias determine the file path; rewrite can change the current request URI. After rewriting, the assumptions used by the original location mapping may no longer hold.

The affected processing path did not adequately check whether the request had been rewritten when checking the alias status in ngx_http_map_uri_to_path(). When the configuration continues to evaluate $request_filename after rewriting, the path may be constructed with assumptions that do not conform to the current URI state, eventually triggering an out-of-bounds write to the heap memory. S5

Typical combination (only used as a counterexample for configuration audit, deployment is not recommended):

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

The danger is not limited to return: set, if, add_header, log_format, etc. also need to be audited if $request_filename evaluation is triggered in the same request process. return in the example only makes this state path easy to see, it cannot be used to infer that all production configurations will produce overflows. S5S10

Consequences of attack: Constructing a request may cause Worker to restart or service interruption; under conditions such as ASLR being closed or can be bypassed, there is a potential RCE. The core of the upstream patch is to refuse to complete the rewritten URI path mapping in the alias context that is no longer valid, rather than simply expanding a certain buffer. S5S10

2.3 CVE-2026-93479: Mismatch between “reserved space” and real variable length in script evaluation

The HTTP and Stream modules of NGINX have script evaluators that concatenate literal strings and variable values into the result string. Application examples include HTTP document root paths, access log paths, and variable expressions in Stream.

Certain configurations of map + regular expressions allow captured values to be read by other expressions before the map result variable is evaluated. Combined with the script execution method with reserved length, the old implementation will count the len reserved space into the evaluated length accumulator in advance, so that subsequent write pointer calculations are no longer consistent with the buffer boundary. In a specific variable evaluation sequence, subsequent string writes may overwrite the reserved area, causing a heap overflow. S6

participatory elements	Why it’s worth paying attention to
regex in map	Capture variable evaluation may have independent life cycle and caching behavior
Anonymous captures such as $1, $2, etc.	Easily overwritten by other regular expressions or expressions, making it difficult to track ownership
Variables in root	Script execution and buffer reservation when triggering path building
log_format/Dynamic log path	The same type of evaluation may be triggered later in the request
Script expressions in stream	The upstream fix also modifies ngx_stream_script_run(). You cannot only review the HTTP module.

Important regression relationship: The code related to this vulnerability is related to the previous changes that fixed CVE-2026-42533. The official DSA for Debian 13 clearly states that the affected code was introduced into the trixie package via an earlier security backport. Therefore, “July map vulnerability patch has been installed” does not mean that October’s CVE-2026-93479 has been covered; the full security fix chain should be checked. S6S14S17

The potential RCE risk here is related to the memory protection environment, and it should not be claimed that the map regex alone will be able to be exploited by anonymous attackers. S11

2.4 CVE-2026-97205: AIO Unfinished operation count wraparound causes Use-After-Free

This vulnerability is not simply “turn on SSI and you will get UAF”. The key lies in the asynchronous operation reference count held by the main request.

NGINX Use r->main->blocked to track asynchronous processing that has not yet completed, in the old implementation it was 8-bit count; some paths did not do an upper limit check before incrementing the count. When the same main request accumulates 256 outstanding operations, the count may wrap around from 255 to 0. Subsequent processes will mistakenly believe that there is no asynchronous operation preventing the request from being released, thereby releasing the request memory pool that is still referenced by the task. S7

The failure process can be divided into:

1. With the associated asynchronous I/O/thread path enabled, the SSI page introduces multiple subrequests or read operations via include virtual.
2. The outstanding operations of a certain main request are accumulated up to the upper limit represented by the count field.
3. 8-bit count wraps around, incorrectly expressed as “no pending operations”.
4. The request memory pool is released, while file reads, cache waits, or callbacks of thread tasks still retain references to it.
5. Subsequent asynchronous completion callbacks access the released memory, resulting in UAF, Worker crashes or potential memory corruption.

The official fix adds NGX_HTTP_MAX_BLOCKED 250 to the request header file, and adds restrictions to the output filter, cache read, and upstream thread path; when the threshold is reached, operations with synchronized paths are completed synchronously, and if they cannot be safely processed, further addition of pending tasks will be refused. S7

applicability judgment: It must be evaluated whether SSI, AIO, virtual inclusion, subrequests and related asynchronous operations can occur in combination in the same request chain. These are usually not the default plain static proxy configurations. aio off; or ssi off; can remove specific trigger elements, but business function dependencies should be confirmed first. S4S7S25

2.5 CVE-2026-95101: HTTP/3 unknown frame is confused with the status of DATA request body

The HTTP/3 frame parser must distinguish between DATA frames (which need to be passed to HTTP request body processing) and unknown frames that should be skipped. The length of unknown frames must also be accurately preserved when fragmenting across network buffers.

The old implementation of ngx_http_v3_parse_data() used the st->length field to save the “remaining number of bytes to be skipped” when skipping unknown frames, while the request body filter interpreted the same field as the “remaining DATA payload length”. If the unknown frame happens to span multiple parse calls, the next batch of bytes after parsing is interrupted may be mistaken as part of the request body. S8

Two types of risks arise:

• request body injection: The non-DATA frame payload submitted by the client may be transmitted to the upstream application, changing the data actually received by the backend.
• size limit bypasses: client_max_body_size and other restrictions. The expected checks are concentrated on the DATA path, and incorrectly converted content may bypass the corresponding verification.

The typical trigger scenario described by the official is when ngx_http_v3_module receives HTTP/3 request and forwards proxy_request_buffering on. Proxy request body buffering is enabled by default in ngx_http_proxy_module. Therefore, the reverse proxy that turns on HTTP/3 should be checked first. It is not appropriate to assume that there is no trigger condition just because proxy_request_buffering on; is not explicitly written. S8S18

The direct consequence of this vulnerability belongs to the backend request integrity and security boundary change, which is not the equivalent expression of RCE directly completed in the NGINX core. The ultimate business impact depends on how these bytes are parsed and trusted upstream. S24

2.6 CVE-2026-97629: TLS Ticket rotation misses the third key slot

In affected configurations, NGINX can automatically generate and rotate TLS Session Ticket keys through shared memory cache, allowing multiple Worker to process the same batch of tickets.

The relevant synchronization logic allocates 3 key slots for each Worker, and the decryption callback will also traverse these slots; but the old implementation only copies 2 key slots from the shared memory each time, resulting in the key name, HMAC key and AES of the third slot. The key may remain uninitialized. If the key identifier of a ticket is matched by this status, uninitialized key material may be used for signature verification and decryption, thus forming a path to forge the TLS session. S9

High-risk deployment combinations are typically:

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

The most serious business consequence of this vulnerability is that on services that use client certificate authentication (mTLS) in ssl_verify_client on; and other ways, forged recovery sessions may bypass client certificate verification. The success of the attack is also subject to uncontrollable conditions; a site that only uses a normal server-side HTTPS certificate and no client certificate authentication should not be mischaracterized as “the attacker can bypass the entire website login.” S9S12

This is a TLS session authentication status issue and has nothing to do with whether the server’s TLS private key is cracked or whether the public CA root certificate is affected. S24

2.7 How to understand DoS, RCE, authentication bypass and known exploits

• DoS: Memory error causes Worker to crash or massively reboot. Whether it causes overall unavailability is related to traffic pressure, process restart ability, connection maintenance time and high-availability architecture.
• potential RCE: Some announcements indicate that there is a possibility of code execution when ASLR is closed or bypassed. This does not mean that a public attack chain that can stably and universally execute commands has been disclosed. S4
• Request injection/authentication bypass: It may directly change the protected business status or request content, and cannot be ignored just because it does not directly obtain the shell.
• has discovered attack attempts: CVE-2026-42945 in May 2026 has reports of in-the-wild exploitation activities; should not directly infer this historical fact to mean that all five CVEs in October have been successfully exploited on a large scale. S23

3. Repair version and patch selection

3.1 NGINX Open Source official patch baseline

upstream branch	The first official version covering five vulnerabilities in October	Recommendations as of 2026-10-27
Stable 1.30.x	1.30.6（2026-10-14）	Install at least 1.30.6, and follow up with subsequent security versions.
Mainline 1.31.x	1.31.7（2026-10-14）	1.31.8（2026-10-21）
The earlier NGINX Open Source branch	It cannot be judged solely based on “old vulnerability patches have been applied”	Migrate to the maintained branch first; otherwise, the vendor is required to provide formal evidence of backing on a CVE-by-CVE basis.

These are the version conclusions of the nginx.org upstream source code/official branch, and should not be used to directly deny the security package with backported fixes provided by the distribution vendor. Even if the value of 1.31.6 is greater than 1.30.6, it is still lower than the patch baseline of the mainline branch. S1S2

3.2 The upstream impact scope of five CVEs

The following ranges are listed according to the original text of the nginx.org security bulletin and need to be understood in conjunction with the “current running branch” and the “actual configuration path”:

CVE	Upstream tags affected versions	Officially labeled fixed version
CVE-2026-15176	0.1.29–1.31.6	1.30.6+ or 1.31.7+, within their respective branches
CVE-2026-93479	1.30.0–1.30.5，1.31.2–1.31.6	Same as above
CVE-2026-97205	0.8.11–1.31.6	Same as above
CVE-2026-95101	1.25.0–1.31.6	Same as above
CVE-2026-97629	1.23.2–1.31.6	Same as above

CVE-2026-93479 has specific introduction-version limits; not every old NGINX version is affected by this regression. Older versions outside those ranges may still be affected by the earlier map regex vulnerability CVE-2026-42533. S1

3.3 Ubuntu: distribution backports (USN-8955-1)

Canonical USN-8955-1 October 26, 2026 provides security update for four Ubuntu builds: S13

Ubuntu version	nginx and the same source package fixed version	Description
22.04 LTS	1.18.0-6ubuntu14.22	It is a vendor backport; the upstream version number still shows 1.18.0
24.04 LTS	1.24.0-2ubuntu7.19	Same as above
26.04 LTS	1.28.3-2ubuntu1.12	Same as above
26.10	1.30.4-7ubuntu1.1	Same as above

The announcement contains corresponding fixed versions of homologous packages such as nginx-core, nginx-extras, nginx-full, and nginx-light. Don’t draw conclusions about whether to fix it from the upstream part only shown by nginx -v. such as Ubuntu 24.04 and 1.24.0-2ubuntu7.19 have been patched by this vendor, but 1.24.0 from any source is not inherently safe.

Ubuntu officially also clearly marked that CVE-2026-95101 only affects Ubuntu 26.04 / 26.10, and CVE-2026-97629 only affects Ubuntu 24.04 / 26.04 /26.10. Here is Ubuntu’s own packaging and functional scope, which cannot be directly promoted to other distributions. S13

3.4 Debian: Differences between versions must be checked separately

Debian advisory DSA-6575-1 (2026-10-21) covers these five CVEs and identifies the fixed nginx package for Debian 13 / trixie as:

1.26.3-3+deb13u10

However, as of the time of verification of this report, 1.22.1-9+deb12u10 for Debian 12 / bookworm is still flagged as vulnerable by the Debian Security Tracker. Therefore:

• Debian 13 Just update and accept according to DSA-6575-1.
• Debian 12 must check the security fixes provided by the current Security Tracker or ELTS vendor one by one; before the fix is confirmed in the announcement, do not declare that all five items have been fixed based on the success of apt upgrade.
• The Debian source package may carry a patch set independent of the nginx.org version number. For custom builds, you need to check the complete source code package fix set, and you cannot just copy a single upstream commit and consider it complete.

The above distinction is based on DSA and CVE tracking records. S14S15S16

3.5 NGINX Plus, njs and Ingress Controller

Products/Components	Security Selection and Verification Key Points
NGINX Plus (commercial version)	Please refer to the announcement and upgrade instructions of the Plus branch corresponding to F5. The latest CR at the time of verification is PLS.37.2.0.1, and the security build of LTS is PLS.37.0.7.1; the Plus version and included backport cannot be directly replaced by Open Source’s 1.30/1.31 threshold. S19
njs / ngx_http_js_module	2026-10-14 releases njs 1.0.2 and fixes CVE-2026-101019 and CVE-2026-101025; if you are using njs, you must also check the compatibility of the module with NGINX. S20
F5 NGINX Ingress Controller / Gateway Fabric	The NGINX core is a related but independent software distribution chain. Fix the relevant vulnerabilities with their respective controllers, images and release notes. You cannot just replace a NGINX binary in the Pod.
Kubernetes Community kubernetes/ingress-nginx	The project is decommissioned in March 2026 and will no longer provide new security maintenance. You should plan to migrate to a maintained controller or Gateway API rather than mistaking its release number for the F5 NGINX Ingress Controller. S21

3.6 Which Patch should you actually choose?

Deployment form	Recommended practices	Proof of repair
nginx.org official DEB/RPM package	Upgrade to the fixed version of the upstream branch	nginx -v/-V, package source, official security announcement
Ubuntu/Debian official repository	Install vendor security packages	Full package version + vendor USN/DSA + CVE status
RHEL/Alma/Rocky/SUSE/Other distributions	Upgrade according to specific distribution security bulletins and package versions	Corresponding vendor CSAF/announcement, Ubuntu/Debian version cannot be applied
Official or custom container images	Rebuild or pull the verified repair image and replace it on a rolling basis	Image digest, build SBOM, running pod/container image ID
Self-compiled NGINX, OpenResty, Tengine or versions patched with third-party modules	Prioritize the use of the maintainer’s full security version; perform reviewed patch backports for the target source tree when necessary	Five vulnerability fixes, ABI/module compatibility, unit and business regression

OpenResty and Tengine are different release systems; this table only describes the verification method. does not mean that all its versions are affected at the same time as the standard NGINX, nor can the upstream code patch be applied unconditionally.

4. Formal repair process

4.1 Inventory of actual instances of receiving external traffic

Collate for each entry at least:

• Domain name, load balancing/CDN/edge proxy link, origin site exposure method and network protocol used.
• NGINX products (Open Source, Plus, Ingress, etc.), full version, package repository source, image digest.
• nginx -V displays the building modules and compilation parameters; whether there are njs, Lua, OpenResty, and third-party dynamic modules.
• Real running master/worker PID, Service Unit/Container/Pod, Replica and Worker Node.
• The actual effective http/stream, server, location, include configurations.
• Whether to enable HTTP/3, mTLS, SSI/AIO, dynamic log path, complex map and regex capture.

Don’t just check the default /etc/nginx/nginx.conf. The production environment often loads multiple sites, TLS and module configurations through include. There may also be multiple NGINX installation paths or multiple proxy layers.

4.2 Check version and compilation information

# 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 reports the build of the binary found on the command-line path; it does not prove that the running worker has loaded it. nginx -v may omit the distribution’s full package suffix, so check the package manager or supply-chain records as well.

4.3 Export the effective configuration and perform the first round of static screening

nginx -T will test the configuration and dump the merged configuration. The output may contain sensitive information such as authentication credentials, key paths, internal host names, etc. It is recommended to save the controlled terminal with root permissions and private file permissions, and do not post the original files to public work orders:

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

This is just the candidate path locator, not a reliable CVE automatic determination tool:

1. grep cannot determine whether the variables are located in the same location or the same request evaluation chain, nor can it deduce the configuration inheritance relationship.
2. proxy_request_buffering on, some cache and ticket configurations have default values, and not writing the corresponding instructions does not mean that the risk disappears.
3. Configurations generated by reverse proxies, CDN, container sidecars, or controllers may differ from manually inspected files.
4. The characteristics of NGINX Plus and dynamic modules may need to be confirmed using their respective official management tools.

4.4 Deploy fix through trusted channels

Debian/Ubuntu (official distribution repository):

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

This set of commands cannot generate security fixes out of thin air that are not yet available. Especially for Debian 12, if the upgraded package is still deemed vulnerable by the security tracking system, additional vendor repair, isolation or migration measures are required. S13S14S15

nginx.org official package:

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

If using self-compiled, OpenResty, Tengine or NGINX Plus, use the fix version supported by the corresponding maintainer and do not mix nginx.org, distribution and third-party repository packages. Original binaries/images, configurations, signatures, and rollback deployment manifests should be preserved.

Containers/Kubernetes: update the immutable image, record its digest and replace all old replicas with a staged rollout. kubectl rollout status only confirms that the deployment controller finished; also verify image digests, ingress routing and unhealthy replicas.

4.5 Verify configuration and replace old Worker

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'

Do not treat nginx -s reload as proof that a new binary is running: ordinary configuration reloads let the old master start new workers without replacing its executable. NGINX supports a dedicated online binary upgrade procedure, but it requires additional steps and verification. Without an established procedure, use a high-availability traffic switch followed by a service restart, or roll out replacement containers. S22

If you manage NGINX via the systemd socket, container entry script, or multiple installations, you should check the actual launch target and process path instead of directly assuming that systemctl restart nginx covers all instances.

4.6 Accept and do business regression from the real external entrance

It is recommended to perform at least:

• Are normal HTTPS, rewritten routes, static resources, and alias mapping pages correct.
• Are the regular map distribution, variable root path, access log path, SNI/certificate routing, and Stream proxy correct.
• Are normal uploads, chunked uploads, API requests and upstream volume limits for HTTP/3 (when enabled) still as expected.
• mTLS: Legitimate certificate requests should succeed; missing, expired, or unauthorized certificates should still be rejected, and TLS resumption/reconnection should not accidentally change permissions.
• Whether SSI page and asynchronous file access are normal; the error log shows no abnormal requests for memory references or repeated Worker crashes.
• After the traffic switch, the old version process and the old image replica should have exited.

Testing must be conducted in own or authorized environment. Normal request smoke test cannot alone prove that the memory vulnerability has been fixed; ultimately, the supplier’s fixed version, source code patch and runtime test must be jointly accepted for acceptance.

5. Mitigation measures when immediate upgrade is not possible

This section is a risk reduction option, not a patch replacement. All temporary configuration changes should be backed up, executed nginx -t, released in batches, and quickly rolled back if necessary. S3S4

5.1 Control traffic priority based on external exposure

Prioritize reducing the attack surface of services that cannot be upgraded in time: on the management surface and internal API Add trusted source access control, upstream network isolation or short-term offline; add connection, request body and rate limits to high-risk entrances; ensure that source authentication occurs at entry-related NGINX before the request processing chain. It should be noted that most of the vulnerabilities themselves are located in NGINX Inside the data plane, traditional WAF Rules may not accurately determine custom configuration trigger conditions.

5.2 alias / rewrite: avoid evaluating $request_filename after rewriting

It is recommended to check and adjust:

• Try not to perform rewrite that will change URI at the same time as location using alias.
• Avoid using $request_filename when URI has been rewritten but the correct position match has not yet been completed.
• Check for indirect variable references in return, set, if, add_header, access log format, and include files.
• Use clear root/try_files/independent location when business permits, but only changes alias to root. It may also change the file path semantics, which must be verified one by one.

Do not directly copy the common “safe rewrite template” on the Internet to overwrite the existing configuration. Different location prefixes and rewrite targets result in path splicing with completely different meanings. S5

5.3 map/Regex: Reduce capture variable state mixing

It is recommended to prioritize named captures and limit their propagation scope, rather than allowing anonymous captures such as $1 to be reused across different regex evaluation paths over time. For example:

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

This snippet only demonstrates an easier-to-audit structure of variable ownership; does not mean that it has been proven to independently eliminate all CVE-2026-93479 trigger paths to. In particular, review whether capture variables are referenced ahead of time by other root or log_format, and whether there are volatile, dynamic paths, and interdependent evaluation chains. F5/CERT recommends using named capture and limiting the scope of use to the corresponding regular matching configuration as a short-term relief. S3S6

5.4 AIO + SSI: Shut down unnecessary function combinations

For servers/paths that don’t require SSI or asynchronous file I/O, use:

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

From the perspective of vulnerability triggering conditions, closing one of the two is usually enough to remove the specific chain described; closing at the same time is only applicable to scenarios where the business does not rely on this capability. Check include virtual, subrequests, cache, and thread pool behavior; when reverse proxy load is high, shutting down AIO may change latency and I/O performance. S7

5.5 HTTP/3 Request body injection: temporarily close the entrance if necessary

Disable the quic listener involving HTTP/3, cancel the Alt-Svc response header that announces HTTP/3, and check whether the edge layer/load balancer still sends QUIC requests directly to the unrepaired NGINX:

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

The above is just a description of the change difference, not a complete server configuration that can be enabled individually. The setting syntax of HTTP/2 is related to the NGINX version; if you need to retain HTTP/2, you should use http2 on; or the existing valid syntax according to the corresponding version, and check with nginx -t. must be merged with the existing server configuration before deployment, instead of replacing the entire section with this section. also checks the UDP 443 firewall, HTTP/3 termination location and client fallback path of CDN/front proxy.

Another type of short-term mitigation is to use proxy_request_buffering off; on the affected proxy path, but this will change the behavior of upstream request body streaming, failure retries, and some upload workflows; only be used after sufficient testing and confirmation that the directive does hit the affected HTTP/3 proxy path. S8S18

5.6 TLS Session Ticket: Priority protection mTLS Authentication boundary

If upgrading is not possible and the instance relies on shared session cache + automatic ticket key rotation, evaluate:

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

This can turn off the TLS Session Ticket mechanism, thereby removing the ticket forgery path described in this vulnerability; however, it may affect session resumption performance. You cannot just turn off mTLS client certificate verification to “avoid vulnerabilities”, as that will directly delete the original authentication boundary. S9S12

Explicit ssl_session_ticket_key files and secure rotation can also be used by professional TLS management processes to circumvent auto-generated conditions, but key custody, full node distribution, rotation, and old ticket lifecycles all need to be carefully audited. It is not recommended to hardcode a long-term reusable key in ordinary web configuration or scripts for temporary emergencies. Critical services that use mTLS should additionally be monitored for TLS session resumption behavior and rejection of requests without a valid client certificate. S12

5.7 The role of operating system and border protection

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

ASLR, non-root workers, read-only container filesystems, minimal file permissions and network isolation can reduce the impact of potential RCE. ASLR does not fix heap overflows or UAF and cannot guarantee that workers will not crash. WAF, rate limits and request body size limits do not fix TLS Ticket key synchronization. S4

5.8 Common misunderstanding: These operations are not sufficient to complete the repair

Common operations	Why is it insufficient?
“nginx -v looks relatively new”	The branch to which it belongs, the complete backported package version of the release version and the online process are not checked.
“Only one of the intranets was upgraded”	The old Worker/old container/old CDN origin instance still receives requests
”Site does not use PHP/dynamic tags”	The defect occurs in the NGINX core path or protocol parsing and does not rely on PHP execution.
”Opening WAF/Cloudflare is enough”	WAF cannot be proven to block all NGINX configuration-dependent memory flaws or TLS resumption flaws
”Already opened ASLR”	Just taking advantage of difficulty mitigation; DoS with request injection is still possible
”HTTP/3 is not exposed to the public network, so there is no need to upgrade at all”	The other four CVEs still require independent evaluation; and there may be direct connections to hidden origins
”July’s map vulnerability has been fixed”	October CVE-2026-93479 involves subsequent script evaluation regression issues
”Disabling caching solves all problems”	Only affects some TLS cache or AIO scenarios, and does not cover alias, script, HTTP/3

6. Official Patch implementation ideas and review points

This section follows the October 2026 upstream NGINX fixes. The snippets illustrate representative changes for patch review; they are not complete, independently compilable fixes. For custom builds, review the full commits, surrounding code and tests, and prefer a complete supported release. S5S6S7S8S9

6.1 CVE-2026-15176: URI has been rewritten to include alias path mapping rejection conditions

The upstream commit modified ngx_http_map_uri_to_path() in src/http/ngx_http_core_module.c:

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

review focus: The file system path cannot be continued to be calculated when URI has changed but the corresponding location semantics of alias are no longer reliable. This is an enhancement to the pre-state constraint. It is not a simple check whether the request URI contains illegal characters. S5

6.2 CVE-2026-93479: Correctly distinguish between output data length and reserved length

The upstream commit updates src/http/ngx_http_script.c and src/stream/ngx_stream_script.c at the same time. The core intention can be summarized as:

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

Here, pool is an illustrative parameter name: the actual HTTP and Stream allocation expressions differ. The change calculates script output length first, then adds reserved length to the final allocation so output does not overwrite reserved space. S6

When auditing and backporting, the corresponding evaluator of HTTP/Stream must also be covered; only checking the configuration syntax file of map cannot prove that the defect has been fixed.

6.3 CVE-2026-97205: Set safety threshold for 8-bit asynchronous operation count

Upstream added at src/http/ngx_http_request.h:

#define NGX_HTTP_MAX_BLOCKED 250

And add similar entries to asynchronous file reading, cache waiting, output filtering and thread operation:

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

review focus: All actual code paths that will add r->main->blocked must be covered. You cannot just write the threshold constant in the header file. Backport also needs to check the complete coordination of synchronous fallback, asynchronous callback and error return to ensure that deadlock or reference leakage will not be caused by direct rejection of tasks. S7

6.4 CVE-2026-95101: Maintain skip status separately for unknown frames

The upstream adds the skip field in the HTTP/3 parser status structure and performs status separation:

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

The key is not to “disable unknown HTTP/3 frames”, but to ensure that across multiple reads, the skipped byte count and DATA payload length are always managed by independent states. Reviews should focus on unknown frame cross-buffer sharding, and eventual consistency of client_max_body_size. S8

6.5 CVE-2026-97629: Synchronize the complete TLS key slot array

The upstream changes are located at 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));

The original image contained three key slots, but only the first two were copied. Instead, synchronize based on the actual number of array elements to ensure that the voting key set of Worker is consistent with the shared memory. When reviewing, also confirm that the array allocation, initialization, shared lock and rotation logic are consistent, rather than just checking the memcpy length modification once. S9

6.6 Why is it not recommended to apply only scattered patch fragments?

These five modifications span src/http, src/stream, src/http/v3, and src/event respectively, and older versions may have security backports and unofficial extensions. Backporting should form the following check matrix:

Check object	What must be confirmed
patch source	Official submission, matching target version, complete patch and signature verification
Original patch set	Does not conflict with historical modifications such as CVE-2026-42533, distribution backport, etc.
code path	HTTP + Stream script, AIO/thread, HTTP/3, OpenSSL Ticket are all covered
Compiled compatible	OpenSSL, PCRE, module ABI, dynamic module and link dependencies are consistent
functional regression	alias rewrite, dynamic log, SSI/AIO, HTTP/3 upload, mTLS session resumption
runtime	All Worker/Pods run new verified builds, no legacy images remain

For teams that maintain their own releases, it is recommended to keep auditable patch IDs, package versions, build logs, and regression reports for each CVE; for ordinary operation and maintenance, the safest solution is to install the vendor’s complete security updates.

7. Historical vulnerability backtracking, old branches and other products

7.1 NGINX core vulnerability worthy of simultaneous confirmation from May to September 2026

Many NGINX instances that have not been updated for a long time are not only affected by the new issue in October. The following are the representative repair nodes in the near future: S1S2

CVE	First fix release	Key risks and conditions requiring audit
CVE-2026-42945	Stable 1.30.1 / Mainline 1.31.0, May 13	rewrite Anonymous regex capture and replacement logic triggers heap overflow, potential RCE; there are public reports of in-the-wild attack attempts
CVE-2026-9256	Stable 1.30.2 / Mainline 1.31.1, May 22	Overlapping regex capture and length estimation in rewrite lead to overflow
CVE-2026-42055	Stable 1.30.3 / Mainline 1.31.2, June 17	HTTP/2 Specific configuration to upstream or gRPC, large request header condition triggers buffer overflow
CVE-2026-42530	Mainline 1.31.2, June 17	HTTP/3 Use-After-Free; official mark affected range 1.31.0–1.31.1
CVE-2026-42533	Stable 1.30.4 / Mainline 1.31.3, July 15	map + regex capture variable evaluation causes heap overflow, and subsequent patches have regression correlation with CVE-2026-93479 in October
CVE-2026-60005	Stable 1.30.4 / Mainline 1.31.3, July 15	ngx_http_slice_module Memory content leaked under specific variable and cache update conditions
CVE-2026-56434	Stable 1.30.4 / Mainline 1.31.3, July 15	SSI is related to UAF; not the same root cause as October’s AIO counting vulnerability
CVE-2026-90439	Stable 1.30.5 / Mainline 1.31.6, September 15	Limited heap overflow of HTTP/3 + specific OpenSSL version combination, mainly manifested as crash/limited memory corruption

Other vulnerabilities such as NGINX Core, HTTP/2, charset, and SMTP announced in 2026 should also be investigated according to official security bulletins; this table intentionally focuses on typical events that are most relevant to the current NGINX public-facing reverse proxy deployments and have memory safety or request integrity implications. is not all CVEs in 2026. List. S1

Why pay special attention to CVE-2026-42945

There are security bulletins from government agencies that record in-the-wild exploitation activities and public exploit code information for this rewrite vulnerability in May. Therefore, for instances that have not been patched for a long time from May to the present and have open complex regular expression rewrites on the public network, in addition to completing the repair, the abnormal Worker crash, access logs and suspicious changes at that time should be additionally reviewed. S23

“An attack attempt occurred” does not automatically prove that the attacker has reliably executed commands on every target; when incident response is involved, compromise indicators and process crashes should be investigated separately from true evidence of privilege escalation or persistence.

7.2 Remediation for older versions and distribution backports

NGINX Different branches have their own support cycles and different vulnerability introduction times. The five new patches cannot be rolled out to all early source trees without review.

scene	Recommended strategy
Release version has announced complete security patches	Use vendor packages and document complete package versions; avoid replacing with incompatible upstream bare binaries
Debian 12 and other affected releases that are not yet covered by all CVEs in this batch	Submit risk work orders, limit external exposure, and check supplier/ELTS status; migrate or use a verifiable maintenance release chain when necessary
Historical branches that have ended upstream support	Prioritize migration to supported versions; if short-term backporting is necessary, maintainers will evaluate dependencies and patch compatibility, and write complete tests.
Comes with NGINX fork (OpenResty, Tengine, customized gateway)	First determine whether the corresponding code path is included, and then use the fork maintainer’s security statement. It cannot be directly equivalent to the upstream version.
Security patches lead to changes in business functionality	Adopt staged rollouts, traffic switching between versions, and configuration adaptation; it is not appropriate to restore the unfixed version of the public network without isolation.

7.3 Separate remediation for njs, Ingress and NGINX Core

• njs: In addition to the NGINX main program, you also need to check the version of the NGINX JavaScript module itself. njs 1.0.2 fixes an October 2026 XML parsing memory exhaustion and XML validation inconsistency issue with entity reference attributes. For deployments associated with XML signature verification using nginx-saml, you should further read the official njs instructions for plug-in scenarios. S20
• F5 NGINX Plus / NGINX Ingress Controller: Plus, controller and Gateway Fabric may each have additional security bulletins, different packaging versions and unique policy vulnerabilities. Upgrading one layer does not mean automatically updating another layer. S19
• Kubernetes Community ingress-nginx: Kubernetes officials have already announced that the controller stopped maintenance in March 2026, and its warehouse cannot be confused with the F5 controller. Affected businesses should plan smooth migration and verify Ingress annotations and Gateway API semantic differences instead of waiting for a new security version. S21

8. Acceptance criteria and follow-up inspections

It is recommended that the following list be used as the acceptance conditions for change work orders:

Project	Qualification standards	Evidence that can be retained
Asset and portal coverage	All external and direct-connected instances that can bypass CDN have been inventoried.	Domain name, LB, IP, Pod/container list
Package source and repair scope	Use versions confirmed to cover all applicable CVEs	Upstream security advisory, USN/DSA, package version, image digest
old process exits	All old master/worker/containers have been replaced	PID/start time, rolling deployment status, running image
Configuration audit	High-risk combinations have been eliminated or covered by patches, and inheritance relationships have been verified	redacted summary and audit record of nginx -T
TLS/mTLS	Trusted certificates pass; invalid or missing certificates are rejected; session resumption does not bypass authentication	Negative/positive authorization test, controlled TLS test results
HTTP/3 request body	Enable path fixed; upstream request body and throttling behave correctly	HTTP/3, proxy upload, volume limit regression test
SSI/AIO	The function meets the requirements, Worker has no abnormal abort	Business regression, crash and error rate monitoring
Operation and maintenance monitoring	No obvious exception 5xx, SIGSEGV, process exits repeatedly	Service indicators and logs before and after changes
Rollback strategy	If rollback is necessary, first limit exposure and preserve security boundaries	Change Orders, Emergency Flows, and Quarantine Plans
subsequent life cycle	Determine security bulletin subscriptions, container update frequency, and branch migration plans	Upgrade ledger, responsible person and next audit date

8.1 What should you focus on in the logs and running status?

Troubleshoot abnormalities on servers that have been exposed for a long time worker process exited on signal 、 SIGSEGV , request failure spikes, abnormal source access aggregation, unexpected TLS Session resumption/authentication success and abnormal backend request body behavior. These indicators can only be used as investigation clues and are not sufficient evidence to directly prove that a certain CVE has been exploited. ;The lack of relevant logs does not prove that there has not been an attack.

8.2 Recommended final risk conclusion wording

The acceptance report for the production environment should use the following precise expression:

NGINX external service entrance and software package source have been identified. All applicable instances have been upgraded to the upstream official security version, or the backport confirmed by the release vendor has been completed; the old Worker and old containers have been replaced. The alias/rewrite/map, AIO/SSI, HTTP/3 request body and TLS Session Ticket/mTLS related configurations have been audited and passed functional, authentication and request integrity regression tests. For instances that have not yet completed the upgrade, additionally register exposure areas, compensation measures, responsible persons, and completion deadlines.

If the patch for Debian 12 or other releases is still incomplete, it is not appropriate to judge the entire acceptance form as “completed”; the unresolved CVE, whether there is a corresponding trigger configuration, the isolation status and the final upgrade route should be clearly recorded.

---

Appendix: Cited sources and links

Description: The [Sx] numbers in the text uniformly correspond to this section. The following gives priority to upstream project security announcements, code commits, supplier release announcements and national security agency information. The severity of the vulnerabilities quoted is described according to the rating criteria of each issuing organization; the data verification date is October 27, 2026.

S1 — NGINX Open Source Official Security Bulletin

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

Contains the upstream affected versions, fix branches, and official severity levels of five October CVEs, and also covers historical vulnerabilities through 2026.

S2 — NGINX official version release record

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

Confirm 1.30.6 / 1.31.7 of 2026-10-14, 1.31.8 of 2026-10-21, and critical security release milestones from May to September.

S3 - Cyber Security Agency of Singapore: F5 NGINX Three Critical vulnerabilities

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

Description of CVSS v4.0 9.2 scores, required configuration conditions, and interim mitigation recommendations for CVE-2026-15176, CVE-2026-93479, and CVE-2026-97205.

S4 - NHS England: F5 NGINX High risk advisory

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

Describes the DoS / potential RCE impact of memory safety issues, and constraints such as ASLR being turned off or bypassed.

S5 — Official source commit: CVE-2026-15176

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

Corresponds to the status check of alias and r->uri_changed in ngx_http_map_uri_to_path().

S6 — Official source commit: CVE-2026-93479

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

Corresponding to HTTP/Stream script length and reserved buffer allocation logic.

S7 - Official source commit: CVE-2026-97205

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

Corresponds to the r->main->blocked count threshold NGX_HTTP_MAX_BLOCKED 250 and asynchronous path fallback.

S8 — Official source commit: CVE-2026-95101

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

The status separation corresponding to HTTP/3 unknown frame remaining length and DATA request body length.

S9 — Official source commit: CVE-2026-97629

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

Corresponds to all key slots during synchronization TLS Session Ticket rotation.

S10 — F5: CVE-2026-15176 Vendor’s Announcement

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

List trigger factors such as alias, rewrite, $request_filename and access logs.

S11 — F5: CVE-2026-93479 Vendor Announcement

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

List map regex capture, root path, and log variable evaluation conditions.

S12 — NGINX official TLS/SSL module documentation

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

Description ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key and client certificate authentication and other instructions.

S13 — Security advisory: Ubuntu USN-8955-1 (2026-10-26)

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

Provide the complete software package fixed version and distribution scope of Ubuntu 22.04 / 24.04 / 26.04 / 26.10.

S14 — Security advisory: Debian DSA-6575-1 (2026-10-21)

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

Confirm the security fix package 1.26.3-3+deb13u10 for Debian 13 / trixie, and record the backport association for CVE-2026-93479.

S15 — Vulnerability tracking: Debian Security Tracker: CVE-2026-15176

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

Used to verify the distribution fix status of Debian 12 / bookworm and Debian 13 / trixie. This status may change with future security updates.

S16 — Vulnerability tracking: Debian Security Tracker: CVE-2026-95101

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

Supplementary confirmation of the security status of the HTTP/3 vulnerability on different Debian branches.

S17 — Security advisory: Red Hat: CVE-2026-93479

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

Supplementary understanding of the correlation between the October regression vulnerability and the fix for July CVE-2026-42533.

S18 — NGINX official reverse proxy module document

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

Query the semantics and default values of configurations such as proxy_request_buffering, client_max_body_size, alias, aio, etc.

S19 — NGINX Plus Official Release Notes

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

List Plus CR/LTS branches, versions, patches and upgrade compatibility reminders.

S20 — NGINX JavaScript / njs Official Security Bulletin

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

Contains October 2026 njs 1.0.2 and related XML validation, memory exhaustion issues.

S21 — Kubernetes: Community ingress-nginx official retirement instructions

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

Note that the project stopped new releases and security fixes in March 2026, and it is recommended to migrate the maintained controller or Gateway API.

S22 — NGINX official service control and online binary upgrade instructions

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

Distinguish configuration reload, restart and online executable file upgrade methods for process switching acceptance.

S23 - Government Security Notice: May 2026 NGINX rewrite vulnerability

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

Provide historical risk background and security update suggestions for CVE-2026-42945; judgments related to in-the-wild exploitation should be based on the agency announcement at the time and further incident evidence.

S24 — F5: CVE-2026-95101 and CVE-2026-97629 Vendor Announcements

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

Covers the risks of HTTP/3 request body injection and automatic TLS Ticket key rotation respectively.

S25 — F5: CVE-2026-97205 Vendor’s Announcement

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

Description SSI/AIO trigger conditions and potential memory corruption risks.

NGINX security update: configuration checks, upgrades and verification