RHSB-2026-007 HTTP/2 HPACK Denial of Service - httpd, nginx, Envoy (CVE-2026-49975, CVE-2026-47774) - "HTTP/2 Bomb"

Executive Summary

Multiple denial-of-service vulnerabilities have been discovered in HTTP/2 server implementations. All have been rated with a severity impact of Important. The vulnerabilities target HPACK, the header compression scheme in HTTP/2, where a small request can trigger large memory allocations on the server. These have been assigned CVE-2026-49975 (httpd) and CVE-2026-47774 (Envoy). Upstream nginx has not assigned a CVE for this exploitation technique, but a fix is still available within Red Hat products; see the resolution section below for details. Other HTTP/2 implementations are also impacted, but are not utilized in Red Hat products.

Many fixes are available, with additional fixes forthcoming for remaining components. This bulletin will be updated as new information emerges. Log in with your Red Hat account, then click the "Follow" button below to be notified of updates.

Affected Products

The following Red Hat product versions are directly affected:

• Red Hat Enterprise Linux 8
• Red Hat Enterprise Linux 9
• Red Hat Enterprise Linux 10
• Red Hat JBoss Core Services
• Red Hat OpenShift Service Mesh 2
• Red Hat OpenShift Service Mesh 3

Further, any Red Hat product which is supported on Red Hat Enterprise Linux (including RHEL CoreOS) is also potentially impacted. This includes

• Product containers that are based on the RHEL or UBI container images. These images are updated regularly, and container health indicating whether a fix to this flaw is available can be seen in the Container Health Index, part of the Red Hat Container Catalog. In addition, any customer containers should be rebuilt when the base images are updated.
• Products that pull packages from the RHEL channel (this includes layered products such as Red Hat OpenShift Container Platform, Red Hat OpenStack Platform, Red Hat Virtualization, and others). Please ensure that the underlying HTTP/2 servers are current in these product environments.

Mitigation

Overall Guidance

The recommended approach is to disable HTTP/2 support. This rolls back affected services to the previous version of the protocol, HTTP/1.1. Component-specific guidance is provided below.

What Is the Impact of Disabling HTTP/2?

• Compatibility remains unbroken. All modern web browsers and API clients automatically fall back to HTTP/1.1 seamlessly.
• Performance reductions will occur. Page load times will increase because HTTP/1.1 delivers files sequentially instead of using HTTP/2 multiplexing.
• Bandwidth consumption will increase. HTTP/1.1 transmits uncompressed text headers, losing the data savings provided by HTTP/2 HPACK compression.
• Active TCP connections, CPU utilization, and memory usage will rise normally.

Apache httpd (CVE-2026-49975)

Add the following line into the configuration of a given virtual host:

Protocols http/1.1

For more granular control, you can also:

• Comment out the LoadModule line with http2_module or proxy_http2_module by adding a # at the beginning of the lines in the configuration files (e.g., /etc/httpd/conf.modules.d/*.conf).
• Remove h2 and h2c keywords from the Protocols directive in the configuration files (e.g., /etc/httpd/conf/httpd.conf or /etc/httpd/conf.d/*.conf).

Restart the service to apply changes:

systemctl restart httpd

nginx

Add the following entry into the configuration file:

http2 off;

For more granular control, you can also:

• In the active server blocks in the configuration files (e.g., /etc/nginx/nginx.conf or /etc/nginx/conf.d/*), remove the http2 keyword from listen directives and change http2 on to http2 off wherever it appears.

Restart the service to apply changes:

systemctl restart nginx

Envoy (CVE-2026-47774)

Disable HTTP/2 support on Envoy listeners where it is not strictly required, or deploy behind a CDN/reverse proxy that can absorb or rate-limit such attacks. Limiting the maximum number of concurrent streams and header list size via Envoy configuration can also reduce the attack surface.

More detailed Envoy mitigation steps will be provided in a future update to this bulletin.

Verification

There are two ways to verify mitigations are in place: client-side or server-side.

Client-Side Validation

Run the following curl header check command locally or externally (adjust URL as needed to target your domain):

curl -kI --http2 https://localhost

• Disabled: The first line of the output returns HTTP/1.1 200 OK.
• Enabled: The first line of the output returns HTTP/2 200.

Server-Side Validation

Run the following commands to verify configurations. Lines starting with # are comments and should be ignored.

• Verify Apache protocols configuration: grep -ri "Protocols" /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/*.conf. Active output lines should not contain h2 or h2c.
• Verify Apache modules configuration: grep http2 /etc/httpd/conf.modules.d/*.conf. Active lines loading the modules should be commented out.
• Verify nginx configurations: grep -s "http2" /etc/nginx/nginx.conf /etc/nginx/conf.d/*. Active lines should not contain the http2 keyword.

Resolution

nginx

The max_headers directive has been backported in the nginx packages below. It is enabled by default (limit: 1000 headers per request) and protects against this class of vulnerabilities.

• RHEL 8 — nginx 1.24 (nginx:1.24 module): RHSA-2026:28921 — nginx-1.24.0-3.module+el8.10.0+24380+8b0811ed.2
• RHEL 9 — nginx 1.24 (nginx:1.24 module): RHSA-2026:28212 — nginx-1.24.0-7.module+el9.8.0+24379+0344c460.2
• RHEL 9 — nginx 1.26 (nginx:1.26 module): RHSA-2026:29151 — nginx-1.26.3-9.module+el9.8.0+24374+c0e15309.1
• RHEL 9 — nginx 1.20 (AppStream): RHSA-2026:28973 — nginx-1.20.1-28.el9_8.3
• RHEL 10 — nginx 1.26 (AppStream): RHSA-2026:29874 — nginx-1.26.3-6.el10_2.4

Versions prior to the ones above do not have the max_headers directive and should be considered vulnerable. See the Mitigation section for instructions on disabling HTTP/2.

Diagnostic Steps

• There is no command to verify the default value of the max_headers directive. As a workaround, you can explicitly set max_headers in the /etc/nginx/nginx.conf file in the http or server block:

max_headers 1000;

• Then, run the following command to check the config. On a version that supports the max_headers directive, it will return:

# nginx -T | grep max_headers
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
     max_headers 1000;

With a version that does not support the max_headers directive, it will return:

# nginx -T | grep max_headers
nginx: [emerg] unknown directive "max_headers" in /etc/nginx/nginx.conf:43
nginx: configuration file /etc/nginx/nginx.conf test failed

References

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