NGINX rewrite module bleeds memory

1. Opening Position

CVE-2026-42945 is a heap buffer overflow in the NGINX rewrite module. That is the defect class, that is the location, and that is the full extent of what the identifier asserts. Everything else about this vulnerability, including affected versions, trigger conditions, exploitation primitive, and patch status, is not confirmed in the material referenced for this writeup. Treat that gap as a condition of the analysis, not a limitation of it.

The operator position is straightforward. NGINX sits on the request boundary. The rewrite module operates on attacker-influenced input by design, because URI rewriting is the function it exists to perform. A memory corruption defect inside that module places the defect on the same side of the trust boundary as untrusted input. That alone determines how this CVE should be triaged, before any PoC, exploit chain, or proof of remote code execution is established.

The writeup framing in the topic title implies two outputs: a description of the defect and a working proof of concept. Neither the defect mechanism nor the PoC contents are present in the provided facts. This section commits to one rule for the remainder of the briefing. If it is not in the input, it is marked not confirmed. The vulnerability identifier and the module name do not authorise inference about cause, payload, or impact. They authorise concern and scoped response. Nothing more.

2. What Actually Failed

The externally observable system behaviour stated by the CVE record is a heap buffer overflow inside the rewrite module of NGINX. A heap buffer overflow means a write occurred outside the bounds of an allocation on the heap. The location of that write is internal to the rewrite module. The trigger path, the input that produces the overflow, the size of the overrun, and the data written are not confirmed.

The rewrite module is the named failure surface. That is significant only in one direction. The rewrite module is reachable from configurations that perform URI rewriting on request data. Whether reachability requires a specific directive, a specific regex construct, a specific input shape, or a default-on code path is not confirmed. Operators cannot conclude their deployment is exposed, and cannot conclude their deployment is safe, from the CVE identifier alone. Both positions require version data and configuration analysis that are not present in the provided facts.

No control behaviour is described in the input. Whether NGINX worker isolation, allocator hardening, stack canaries, or upstream mitigations contained the overflow at runtime is not confirmed. Whether the defect is exploitable for code execution, denial of service only, or information disclosure is not confirmed. The only confirmed system behaviour is that a write outside an intended heap allocation can occur within the rewrite module. Every other claim about runtime effect is unsupported by the material at hand.

3. Why It Failed

The direct cause of a heap buffer overflow is a write whose length or offset was not constrained to the bounds of the allocation receiving it. That is a logically necessary implication of the defect class. The specific failure, whether a length calculation, an allocation sizing, a copy primitive, an integer handling step, or another mechanism, is not confirmed by the provided facts. Naming a root cause without that detail would be inference, not analysis.

The rewrite module operates on request-derived data. That is its purpose, and it is stated by the module name. Any code path inside that module that handles request-derived data without enforcing a length boundary on writes into heap allocations will produce the observed defect class. Whether this CVE involves such a path on a default configuration, a non-default configuration, or a configuration constructed specifically to trigger the defect is not confirmed. The mechanism is consistent with the failure class. The mechanism is not stated.

The operator-relevant finding is the location, not the cause. A memory safety defect in a module that processes untrusted input means the boundary between request data and process memory inside the NGINX worker was not enforced by the code handling that data. Whether other controls compensated for that lack of enforcement is not confirmed. Until the specific defect mechanism, affected versions, and patched versions are published and verified against deployed inventory, the only defensible position is that the rewrite module is a confirmed memory safety failure surface on the request path, and the cause of that failure is not confirmed.

4. Mechanism of Failure or Drift

The mechanism is a write outside heap allocation bounds inside the rewrite module. That is the failure. The drift is the position of that failure relative to the trust boundary. NGINX terminates the request at the edge of the perimeter. The rewrite module operates on data sourced from that request by its stated function. A memory safety defect inside that module means the corruption primitive exists in code reached by request paths that match a rewrite directive, not in code reached only by authenticated callers or privileged internal operations.

The drift is not in the defect class itself. Heap buffer overflows occur in many code locations across many products. The drift is in what the location implies about boundary placement. A heap overflow inside a parser handling internal configuration carries one exposure profile. A heap overflow inside a module that exists to transform request URIs places the corruption primitive on the same execution context as the worker process handling incoming traffic. The worker process holds whatever privileges, file descriptors, upstream connections, and shared memory regions the deployment grants it. Whether any deployment grants more than minimum necessary is not confirmed.

The specific code path from input byte to out-of-bounds write is not confirmed. The function or operation responsible for the overrun is not confirmed. What is confirmed by the CVE record is that the rewrite module is the named defect surface and that the module’s stated function requires it to consume request-derived data. An operator analysis that treats this CVE as equivalent to a memory safety defect in a non-request-handling module is misreading the position of the failure. The defect class is identical to many others. The boundary placement is not.

5. Expansion into Parallel Pattern

The pattern is memory safety defects located in code that sits on the request path of a network-facing process. The mechanism repeats wherever a process accepts untrusted bytes and parses, transforms, or matches them in code written in a memory-unsafe language without enforced length boundaries on writes into allocations. The rewrite module instance, as named in the CVE, is one occurrence of the pattern. The pattern is the placement of unsafe operations at a point where input is attacker-influenced by design rather than by accident.

The pattern holds when the consuming code has no upstream control that constrains input shape to within the allocation sizes used internally. URI rewriting accepts request URIs by its function. Constraining input before it reaches the rewrite module would require a control upstream of the module inside the same process, or external to the process entirely. Whether such a control exists in NGINX, whether it is enforced on the code path that reached this defect, and whether the defect path bypasses it are not confirmed. The pattern is that controls placed inside the same process as the unsafe code share the failure domain of that code. They do not act as boundaries against defects in their own address space.

The pattern extends to any deployment where a network-facing process consolidates request termination, header parsing, URI handling, body processing, and upstream routing in a single execution context. Consolidation reduces the number of enforced boundaries between untrusted input and process memory. When a memory safety defect appears in any module reachable from the request path, the exposure is bounded by the privileges and reach of the entire process, not by the scope of the module. The rewrite module CVE is consistent with that pattern. The pattern is not specific to this product, and it is not specific to URI rewriting.

6. Hard Closing Truth

The CVE identifies a memory safety failure surface on the request path of a process that terminates external traffic. That is the operator-relevant fact extractable from the identifier and the module name. Affected versions, exploitation status, patch availability, public PoC contents, and runtime impact are not confirmed by the material at hand. They must be resolved against vendor advisories and deployed inventory before any further claim is made. Stating exposure without that resolution is fabrication. Stating safety without that resolution is also fabrication. Both are operationally equivalent failures.

What must now be true. Every deployment running NGINX must have a version inventory mapped against the vendor’s published affected and fixed version ranges for this CVE, sourced from the vendor directly. Every configuration using the rewrite module must be identified and treated as a candidate trigger path until the vendor confirms the specific directive and input conditions that reach the defect. The presence of compensating controls, including worker process privilege reduction, allocator hardening provided by the platform, request size and shape constraints enforced upstream of the process, and segmentation between the worker and any sensitive backend, must be verified against current configuration. Verified, not assumed.

Identity is the boundary. Here the boundary is the trust placed in request data by code that handles it without enforced length safety on heap writes. That boundary failed inside the rewrite module by the existence of the CVE class alone. Whether it failed exploitably, at scale, or against any specific deployment is not confirmed. Controls that are not enforced are not controls. Patch state that is not verified is not patched. Configuration that is not audited against the affected path is not safe. The vulnerability identifier authorises scoped response and inventory work. It does not authorise inference about cause, payload, or impact. Anything beyond what the vendor confirms is noise.