HTTP/2 Bomb / CVE-2026-49975: Guidance for NGINX-, Apache-, and LEMP-based Environments

Overview

HTTP/2 Bomb / CVE-2026-49975 is a reported Denial of Service issue related to HTTP/2 request processing. It is relevant only for environments where HTTP/2 is enabled, or planned to be enabled, on an externally accessible SSL/TLS endpoint.

The original technical report describes the issue as a remote DoS class affecting HTTP/2 implementations, including nginx and Apache httpd.
Reference: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

This article explains the impact on Virtuozzo Application Management certified NGINX-, Apache-, and LEMP-based environments.

Scope

The following certified environment types may be relevant when HTTP/2 is enabled or planned to be enabled on an externally accessible SSL/TLS endpoint:

• NGINX-based environments
• LEMP environments
• Apache-based environments

Environments without externally exposed HTTP/2 over SSL/TLS are not considered in scope for this guidance.

Custom environments using nginx, Apache, or another HTTP/2-capable web server should be reviewed by the environment owner according to the relevant software vendor guidance.

NGINX-based environments

The latest available certified NGINX-based environments use nginx 1.30.2.

Based on the currently available information, nginx 1.30.2 contains the relevant nginx-side mitigation for HTTP/2 Bomb. The related nginx mitigation is based on the max_headers directive, which limits the number of request header lines.
Reference: https://nginx.org/en/docs/http/ngx_http_core_module.html#max_headers

Customers using older NGINX-based containers should redeploy or update to the latest available supported NGINX-based stack version if HTTP/2 is enabled and exposed.

LEMP environments

Current LEMP environments use nginx 1.30.2 and follow the same nginx-side mitigation status.

Customers using older LEMP containers should redeploy or update to the latest available supported LEMP stack version if HTTP/2 is enabled and exposed.

Apache-based environments

For Apache-based environments, the fix is provided through the updated mod_http2 package with the cookie header accounting fix against LimitRequestFields.

The fix will be available only for the supported Apache 2.4.67 AlmaLinux 9-based certified images.

The updated Apache 2.4.67 images are planned to be available for redeployment on June 6, 2026.

Customers using Apache-based environments should redeploy to the updated supported Apache 2.4.67 image after it becomes available. If they already use Apache 2.4.67, redeployment to the refreshed image is still required to receive the updated mod_http2 package.

Apache HTTP/2 documentation: https://httpd.apache.org/docs/current/howto/http2.html

Existing containers

Existing containers are not modified automatically after a new stack image is published. This is expected behavior to avoid unexpected changes to running applications.

To receive the latest security fixes, environment owners should redeploy or recreate containers using the latest supported stack image, or update the relevant packages manually if they manage the software inside the container themselves.

This follows the standard Virtuozzo Application Management stack update model: new stack images are published after upstream fixes are available, while existing containers remain under the environment owner’s control.
Reference: https://www.virtuozzo.com/application-management-docs/software-stacks-versions/#stack-updates-and-security-handling

Recommended actions

Customers should:

1. Check whether HTTP/2 is enabled and exposed in their environments.
2. For NGINX-based environments, use the latest available supported stack with nginx 1.30.2.
3. For LEMP environments, use the latest available supported LEMP stack with nginx 1.30.2.
4. For Apache-based environments, redeploy to the refreshed supported Apache 2.4.67 image after it becomes available on June 6, 2026.
5. If HTTP/2 is not required, consider disabling HTTP/2 as an additional hardening measure.
6. Periodically redeploy environments to supported stack versions to receive security fixes.

Notes

End-of-life or deprecated stack versions are not updated with new CVE fixes. To receive security fixes, migrate or redeploy to a currently supported stack version. Existing containers based on older images remain operational but are not automatically patched by the platform.