Nginx and CVE-2026-49975

Rocky Linux Help & Support
1

Hello,

We are running Rocky Linux 9 where is nginx 1.26.3 as default version. Today I’m reading about a Hidden HTTP/2 Bomb that should be fixed in nginx 1.29.8+

Please could some of the maintainers check patch for supported nginx 1.26.3 if it can be applied? For the time I have to disable http2.

Source:

https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

Thank You.

J.

2

Since Rocky is based on RHEL, then RHEL will be the ones who check and backport a fix if it’s needed. Only at that point will it be in Rocky.

3

@iwalker it looks like this backported fix was eventually applied but it has a serious bug that also affected ubuntu (see ubuntu’s note on CVE-2026-49975, which I would link but my account is not allowed to include URLs)

nginx fixed this by releasing 1.29.8 with a max_headers directive with a default of 1000. They did not mention this release on their security page, and did not assign an nginx specific CVE to this issue. The nginx fix for this issue breaks ABI and introduced a regression causing nginx to crash when being used with external modules. The CVE fix was reverted in 8398-2. USN-8398-3 provided a complete fix for this issue.

Rocky has the same regression in nginx-1.26.3-9.module+el9.8.0+40222+e48d13b6.1 (RLSA-2026:29151). The max_headers patch inserts a field into a public struct in src/http/ngx_http_request.h:

$ dnf download --source nginx-1.26.3-9.module+el9.8.0+40222+e48d13b6.1
$ rpm2cpio nginx-*.src.rpm | cpio -idm --quiet
$ cat 0017-Added-max_headers-directive.patch

--- a/src/http/ngx_http_request.h
+++ b/src/http/ngx_http_request.h
 typedef struct {
     ngx_list_t                        headers;
+    ngx_uint_t                        count;
     ngx_table_elt_t                  *host;

ngx_http_headers_in_t is embedded by value in ngx_http_request_t, so this shifts every following field. Modules built against the prior 1.26.3-9 respin then read r->headers_in.* at the wrong offsets and segfault on the first request (worker process exited on signal 11).

Normally NGX_MODULE_SIGNATURE would refuse an incompatible module at load time, but it only encodes struct-affecting build options, not source-level struct changes — so it’s byte-identical across both builds and the module loads, then crashes:

$ for b in 40194+40adfc1b 40222+e48d13b6.1; do
    dnf download "nginx-core-1.26.3-9.module+el9.8.0+$b" >/dev/null 2>&1
    printf '%s  ' "$b"
    rpm2cpio nginx-core-*"$b"*.rpm | cpio --to-stdout -i --quiet ./usr/sbin/nginx \
      | strings | grep -m1 -E '^[0-9]+,[0-9]+,[0-9]+,'
  done
40194+40adfc1b   8,4,8,0011111111010111011111111111111111
40222+e48d13b6.1 8,4,8,0011111111010111011111111111111111   # identical, yet ABI differs

Like Ubuntu did in USN-8398-3, this needs a respin that either drops the max_headers struct change from the 1.26 z-stream or bumps a signature-affecting identifier so mismatched modules fail to load instead of segfaulting at runtime.

4

If it’s a bug, then it needs to be reported here: https://bugs.rockylinux.org/