CVE-2026-9256 NGINX ngx_http_rewrite_module PoC Derivation Process and Thoughts

Scope: Only for local ranges, authorized reproduction environments, vulnerability verification, and protection rule analysis. Do not use against unauthorized targets. The PoC ideas in this document only verify remotely observable NGINX worker crash behavior, and do not include RCE, ASLR bypass, or stable exploit chains.

1. Vulnerability Background

CVE-2026-9256 is a heap buffer overflow vulnerability in the NGINX ngx_http_rewrite_module. The vulnerability is not triggered simply by accessing a fixed URI, but rather depends on a specific rewrite configuration pattern: overlapping PCRE capture groups in the rewrite regex, and multiple capture variables (e.g., $1, $2) referenced in the replacement part.

When an attacker constructs a special URI that causes the rewrite logic to enter a relevant path, NGINX may experience a discrepancy between the calculated length and the actual written data when processing captured content, concatenating rewrite results, or performing URI/parameter escaping. This ultimately results in heap memory corruption in the worker process.

Therefore, the key to this vulnerability is not the /api path itself, but whether the target NGINX configuration contains a vulnerable rewrite rule that can be hit by a request. The default /api used in the PoC is only an example path in the current reproduction environment. During actual testing, the request path must be adjusted based on the rewrite rules in the NGINX configuration that contain overlapping capture groups and reference multiple capture variables.

The current PoC aims to verify worker crash / denial of service behavior. It does not attempt to construct a precise heap layout, overwrite return addresses or function pointers, or demonstrate remote code execution. The stable evidence observable from the remote side is mainly: the trigger request connection is abnormally closed, followed by NGINX service resuming response, and keep-alive connections being interrupted by the worker crash after triggering.

2. Why can't you rely only on an HTTP status code?

After this vulnerability is triggered, it does not necessarily manifest as a fixed HTTP 500, 502, or 400. This is because NGINX's master-worker model allows the master to restart a new worker after a worker process crashes. The remote side typically does not see the entire service become completely unavailable; instead, a connection is abruptly closed, read times out, or the connection is reset, and then subsequently visiting / again yields a normal response.

Therefore, the PoC cannot determine whether the vulnerability exists based solely on the HTTP status code of a single request. If you send a long URI once, see a connection drop, and immediately conclude "vulnerability exists", the risk of false positives is high. Connection drops can also result from network jitter, proxy timeouts, request interception by intermediate devices, backend rate limiting, or the server actively closing the connection.

Thus, the PoC must be designed as a multi-stage verification:

1. First, confirm the target is alive.
2. Then, confirm that the example rewrite path is likely active.
3. Send an overflow trigger request and observe whether the connection is abnormally closed or times out.
4. Immediately send a normal request to confirm whether NGINX has resumed responding.
5. Use the keep-alive method to repeatedly verify whether the worker connection is consistently dropped after triggering.

Only when "trigger connection abnormal + subsequent service recovery + multiple keep-alive drops" all occur simultaneously can the existence of CVE-2026-9256-style worker crash behavior be judged more reliably.

3. PoC Construction Approach

The core trigger path of the current PoC is:

GET /api/++++++++++++++++++++++++++++++++... HTTP/1.1
Host: 127.0.0.1:19321

Where /api/ is the example route used to hit the rewrite rule in the current target, followed by a large number of + characters. The default count is 4096.

There are three main reasons for choosing +.

First, + is a legal URI character. When sent using a normal HTTP client, it is usually not truncated or forcefully rewritten like spaces, #, etc. Therefore, the current PoC does not need to use raw sockets to construct illegal request lines as in some request-target bypass vulnerabilities.

Second, a large number of repeated characters allow rewrite capture groups to obtain a sufficiently long input, expanding the output scale of subsequent replacement concatenation or escaping processing, making it easier to trigger inconsistencies between calculated length and actual written data.

Third, the payload structure of repeated + is simple, making it easy to observe in packet captures, logs, and IDS rules, and convenient for adjusting lengths for threshold testing.

However, note that + is not the only theoretically triggerable character. The real trigger condition is still "hitting a vulnerable rewrite configuration + input entering relevant capture groups + rewrite output processing triggering heap overflow." In different environments, the trigger route, character type, and length threshold may all need adjustment.

3.1 Explanation of Other Potentially Triggerable Characters

The current PoC defaults to using a large number of + as trigger characters, but this does not mean only + can trigger the issue. + is simply the most suitable character for writing into a general PoC because it is relatively stable in URIs, easily sent by normal HTTP clients, and its packet characteristics are clear.

From a vulnerability principle perspective, as long as a character enters the NGX_ESCAPE_ARGS escaping logic during NGINX rewrite processing and expands from the original 1 byte to the 3-byte %XX form, it can cause a discrepancy between the calculated length and the actual written data. That is, the trigger point is not essentially + itself, but "the dense appearance of characters that can be escaped in args mode."

In addition to +, characters that should be theoretically considered include:

Space: 0x20
#: 0x23
%: 0x25
&: 0x26
?: 0x3F
Control characters: 0x00-0x1F
High bytes: 0x7F-0xFF

If these characters enter the relevant captures and are treated as args content for escaping in rewrite replacement, they will produce similar expansion effects. For example:

+      -> %2B
&      -> %26
%      -> %25
#      -> %23
?      -> %3F
Space  -> %20

Each occurrence of such a character theoretically expands from 1 byte to 3 bytes, increasing the actual written length by 2 bytes. If the input contains a large number of such characters, the actual written length may significantly exceed the buffer length that was incorrectly calculated earlier, making it easier to trigger a heap buffer overflow.

However, the usability of different characters in a PoC is not entirely the same.

+ is the most stable. It can usually appear directly in the HTTP request-target without being truncated by browsers or command-line tools, and it does not naturally change the path/query structure of the URI. Therefore, the current PoC uses 4096 + characters as the default payload.

& can also be a candidate character because it will be escaped to %26 in args mode. However, in shells, & has the meaning of background execution, and in URLs it is often used as a query parameter separator. Therefore, care must be taken with quoting and positioning during testing, otherwise the request may not be sent as intended.

% can also be a candidate character because it will be escaped to %25. However, % itself is also the prefix for URL encoding. Some clients, proxies, or frameworks may attempt to interpret %XX sequences. If constructed incorrectly, the target may not receive the raw % character but instead preprocessed content from the client.