CVE-2026-49975, Tiny HTTP/2 Headers That Pin Gigabytes of Memory

CVE-2026-49975 is best understood as a concrete vulnerability record inside a broader HTTP/2 Bomb disclosure, not as a magic label that makes every HTTP/2 server vulnerable in the same way. The risk is still serious. Public research described a remote denial-of-service technique against default HTTP/2 configurations in several major server-side stacks, including nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora. The common pattern is ugly for defenders: a client sends a small amount of HTTP/2 traffic, HPACK decoding and header handling inflate the server-side state, and HTTP/2 connection behavior lets that state remain pinned long enough to exhaust memory. (Calif)

The important correction is scope. In public tracking, CVE-2026-49975 is tightly associated with the Apache-side issue in the HTTP/2 Bomb family, especially Cookie header accounting in mod_http2. Envoy, which is part of the same broader technical story, published its own advisory under CVE-2026-47774, with its own fixed versions and its own description of the bug mechanics. That distinction matters in patch management. A scanner finding, a blog headline, and a vendor advisory may all say “HTTP/2 Bomb,” but your remediation ticket must name the actual component, package version, configuration, and fix path. (SecLists)

The practical takeaway is simple: if you expose HTTP/2 to untrusted clients, especially at the public edge, you need to check whether your HTTP/2 implementation enforces decoded header limits, header count limits, correct Cookie accounting, and safe connection lifetime behavior. A limit on the encoded header block is not enough. A limit on a single header value is not enough. A reverse proxy in front of the application is not enough unless the proxy itself is patched or configured to reject the dangerous pattern before expensive state is created.

What CVE-2026-49975 names, and what it does not

CVE-2026-49975 sits in a messy but common zone of vulnerability disclosure: one research finding exposes a bug class across several implementations, while vendors assign or publish separate records for their own code. Security teams should resist the temptation to treat the CVE number as the whole story.

The original HTTP/2 Bomb disclosure described a remote memory-exhaustion attack against default HTTP/2 configurations across multiple server implementations. The researcher’s timeline says nginx was notified in April 2026 and shipped a new max_headers directive in 1.29.8, while Apache was notified on May 27, fixed the relevant mod_http2 issue the same day, and assigned CVE-2026-49975. The same disclosure later noted Envoy patches released on June 3, 2026. (Calif)

That does not mean “CVE-2026-49975 equals all HTTP/2 Bomb behavior everywhere.” Envoy’s official advisory describes a closely related memory-exhaustion issue involving Cookie header accounting and HPACK amplification, but it tracks that issue as CVE-2026-47774 and lists patched versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1. (GitHub)

Third-party vulnerability databases can also differ in scoring and wording. Tenable lists CVE-2026-49975 as a high-severity HTTP/2 Bomb issue and gives CVSS v3.1 7.5 and CVSS v4 8.7. SUSE lists the issue as important in its own packaging context, also gives CVSS v3.1 7.5, but shows CVSS v4 9.2. (Tenable®) This is not unusual. CVSS v4 environmental interpretation, distro backports, and package-specific exposure can lead to differences. For operations, the right question is not “which score wins?” The right question is “which exposed HTTP/2 components do we run, which ones have a vendor fix, and which ones still accept untrusted HTTP/2 traffic?”

A useful internal vulnerability record for this issue should include:

שדה	What to record	מדוע זה חשוב
Exposed hostname or service	Public domain, API gateway, ingress, service mesh listener, or internal endpoint	HTTP/2 exposure is often at proxies, not only at origin servers
HTTP/2 role	Client-facing server, reverse proxy, sidecar, gateway, or upstream	The vulnerable parser may sit before the app
Product and package	Apache httpd, mod_http2, nginx, Envoy, IIS, Pingora, distro package name	Fixes are product-specific
Version source	Binary version, package manager output, container image digest, build metadata	Banners and Server headers are often misleading
Config evidence	HTTP/2 enabled, header size and count limits, Cookie handling controls	The bug class depends on limits and accounting
Vendor advisory	CVE-2026-49975, CVE-2026-47774, or another vendor-specific record	Prevents mixing unrelated fixes
Mitigation status	Patched, HTTP/2 disabled, edge filter deployed, memory cap applied	Helps incident commanders understand residual risk

The short version for engineers is this: use CVE-2026-49975 as the Apache-side tracking anchor, but assess the whole HTTP/2 path. A production request may terminate at CDN, WAF, load balancer, ingress controller, service mesh, sidecar, API gateway, or origin server. The vulnerable parser might be any of those layers.

The bug class in one sentence

HTTP/2 Bomb turns cheap client-side header traffic into expensive server-side memory state, then keeps that state alive long enough for memory exhaustion.

That sentence is more useful than a nickname. It separates the issue into three parts:

Primitive	Defender question	מדוע זה חשוב
Header compression amplification	Can a small encoded header representation decode into a much larger in-memory representation?	Limits on wire bytes can miss decoded size
Header accounting bypass	Are Cookie fragments, duplicate fields, or merged fields counted before request acceptance?	Limits that run at the wrong phase can be bypassed
State lifetime extension	Can the client keep the request or connection alive while memory stays allocated?	Short-lived allocation spikes become sustained exhaustion

The attack is a denial-of-service issue, not a confidentiality or integrity issue. That does not make it minor. A remote unauthenticated DoS against edge infrastructure can take APIs, login flows, checkout pages, mobile backends, telemetry endpoints, and internal control planes offline. For SaaS companies and security-sensitive enterprises, availability is a security property.

Why HTTP/2 makes this possible

HTTP/2 is not “broken” because of CVE-2026-49975. The problem comes from the interaction between legitimate protocol features and implementation assumptions.

HTTP/2 replaced HTTP/1.1’s line-oriented request framing with binary frames, multiplexed streams, and HPACK header compression. HPACK exists because HTTP headers are repetitive. Many requests carry the same header names and values again and again: :method, :path, host, user-agent, accept, cookie, authorization metadata, tracing headers, feature flags, and application-specific headers. Compressing those fields saves bandwidth and improves performance.

HPACK allows header fields to be represented as literals or as references to table entries. It also maintains a dynamic table so an encoder can insert a header field once and refer to it later. The RFC describes both indexed and literal representations, and it notes that implementations may process headers sequentially but may also retain the complete header list for application constraints. (rfc-editor.org)

That last point is where reality bites. A web server or proxy usually does more than decode headers and discard them. It may need to:

• route by authority, path, method, or custom header;
• enforce authentication or authorization;
• normalize Cookie headers;
• forward the request to an upstream HTTP/1.1 service;
• apply request header limits;
• create application-visible header maps;
• log metadata;
• run WAF or policy logic;
• keep stream state until the request body or flow-control condition resolves.

If the implementation counts only the encoded bytes, or only individual header values, or only fields after a merge step, then a client may find a gap between “what the server allowed” and “what the server actually allocated.”

HPACK amplification is only half the story

A compression bomb is not new as a concept. Zip bombs, XML entity expansion, and decompression-ratio attacks all exploit the difference between compact input and expensive output. HTTP/2 Bomb has a similar shape, but the web-server context makes it operationally dangerous.

Public analysis of the HTTP/2 Bomb disclosure described HPACK references and Cookie fragments as a way to produce a high decoded-memory cost from small network input. BleepingComputer summarized the technique as combining HPACK compression amplification with a Slowloris-style hold using flow-control behavior. (BleepingComputer)

The key point is that HPACK’s dynamic table is not itself unlimited. The protocol bounds the dynamic table, and an implementation can enforce limits. The dangerous part is what happens after decoding. A small encoded reference can lead to repeated header objects, duplicated Cookie fragments, application header maps, or merged representations. If those objects are accepted and retained, the cost shifts from “network bandwidth” to “server memory per connection or per stream.”

That is why a narrow mitigation such as “lower the maximum header value size” can fail. An attacker may not need one huge header value. They may use many small fields, repeated references, or Cookie crumbs that look individually acceptable but become expensive in aggregate.

Cookie header splitting turns a normal feature into an accounting trap

Cookie handling is central to the Apache and Envoy discussions because HTTP/2 treats Cookie fields differently from the way many HTTP/1.1 applications expect to receive them.

RFC 9113 explains that Cookie header fields can be split into separate header fields in HTTP/2 and then concatenated with ; before being passed into non-HTTP/2 contexts. (rfc-editor.org) That behavior is legitimate. It can improve compression because repeated Cookie name-value pairs can be represented more efficiently. It also preserves compatibility with applications that expect one Cookie header.

The implementation trap is timing. Suppose a server applies a field-count limit before Cookie fragments are merged, but then the merge step creates or preserves additional header entries in a way that escapes the original count. Or suppose the server validates each Cookie fragment as small enough, but does not count the total decoded and buffered Cookie memory before accepting the request. In both cases, the server believes it has enforced a limit, but the actual memory cost is not bounded by that limit.

The Apache-side fix reflects this exact kind of accounting problem. The mod_http2 v2.0.41 release notes say it fixed Cookie header accounting against LimitRequestFields. (GitHub) The related Apache code change treats the Cookie merge as an “add” so the merge does not escape the field limit. (GitHub) For defenders, the lesson is broader than Apache: normalization and merge steps must count against the same limits as the original request parsing path.

HTTP/2 flow control affects memory lifetime

The other half of the HTTP/2 Bomb pattern is lifetime. A server can survive brief allocation spikes if it rejects the request quickly and frees the memory. The attack becomes much worse when a client can make expensive state remain allocated.

HTTP/2 flow control is directional and applies to DATA frames. RFC 9113 states that only DATA frames are subject to flow control, and WINDOW_UPDATE controls stream and connection windows. (rfc-editor.org) That matters because a client can influence request progress without necessarily sending a large body. If the implementation allocates header or request state and then waits on stream progress, flow-control windows, or application handoff, memory can remain pinned.

This resembles the operational logic of Slowloris: the attacker does not need to win with bandwidth. The attacker wins by making the server maintain expensive per-connection or per-request state for cheap clients. The HTTP/2 Bomb disclosure described a one-byte-on-the-wire-to-one-header-allocation effect and a zero-byte flow-control window hold that can keep the allocated memory from being freed. (Calif)

This is also why mitigation must consider connection lifetime and worker memory, not just parsing. A server that caps decoded headers but allows too many long-lived suspicious streams may still be exposed to resource exhaustion. A server that kills suspicious streams quickly but does not enforce decoded-size limits may still allocate too much before the kill path triggers.

Why normal header limits can miss the bug

Many teams assume they are protected because they configured a maximum request header size years ago. That assumption needs to be rechecked.

Header controls differ by what they measure and when they measure it:

בקרה	What it limits	What it may miss	Better question
Encoded header block size	Bytes received in compressed HTTP/2 representation	Decoded header expansion after HPACK	Is there a decoded header size limit?
Single header value size	Maximum length of one field value	Many small fields or repeated Cookie crumbs	Is there a total decoded header list limit?
Header count	Number of fields accepted	Fields created or preserved during Cookie merge	Are merged and normalized fields counted?
Dynamic table size	HPACK table memory	Application header maps and retained request state	What is total per-stream memory after decoding?
Request timeout	Slow or incomplete requests	Allocated header memory held before timeout	Are suspicious streams rejected early enough?
Worker memory limit	Total process memory	Root cause remains exploitable	Does memory isolation prevent full host failure?

CVE-2026-49975 is uncomfortable because it lives between layers. A protocol parser may think it did its job. A header-limit function may think it did its job. A Cookie normalization function may think it did its job. A reverse proxy may think the request is still in progress. The combined effect is what matters.

For security review, do not ask only “Do we have header limits?” Ask:

• Are limits applied to decoded size, not only encoded size?
• Are limits applied before expensive allocations become persistent?
• Are duplicate headers and Cookie fragments counted correctly?
• Are normalization and merge operations charged to the same budget?
• Are suspicious streams torn down before memory accumulates?
• Are worker processes or containers capped so one edge component does not take down the node?

Affected components and patch signals

The public disclosure named several major HTTP/2 server implementations. Still, defenders should handle this as a component-by-component patching task.

רכיב	Publicly described issue	Tracking record or advisory	Patch or mitigation signal	What to verify
Apache httpd with mod_http2	Cookie header accounting issue in HTTP/2 request handling	CVE-2026-49975 in public discussion	mod_http2 v2.0.41 fixed Cookie accounting against LimitRequestFields	Package version, distro backport, mod_http2 loaded, HTTP/2 enabled
nginx	HTTP/2 Bomb exposure in default HTTP/2 configurations, mitigated by header-count hardening	nginx commit and release hardening, not necessarily the same CVE scope as Apache	nginx 1.29.8 added max_headers, defaulting to 1000 in the commit	nginx version, whether max_headers is available and configured, whether HTTP/2 is exposed
Envoy	Cookie header size bypass plus HPACK amplification causing memory exhaustion	CVE-2026-47774, GHSA-22m2-hvr2-xqc8	Fixed in 1.35.11, 1.36.7, 1.37.3, 1.38.1	Envoy version, downstream HTTP/2 listeners, gateway and sidecar images
Microsoft IIS	Listed in the broader HTTP/2 Bomb disclosure as affected in tested scenarios	Public reporting, but teams should rely on Microsoft’s own update channel for production decisions	Reduce exposure, monitor official fixes, use edge controls if no fix is confirmed	Windows Server build, IIS role, HTTP/2 exposure, fronting proxy behavior
Cloudflare Pingora	Listed in the broader HTTP/2 Bomb disclosure	Public reporting, product or project-specific fix status must be checked	Follow maintainer guidance and restrict untrusted HTTP/2 where needed	Whether Pingora is used directly or embedded in internal infrastructure

The original disclosure’s demo table reported dramatic memory growth across tested versions, including Envoy 1.37.2, Apache httpd 2.4.67, nginx 1.29.7, and IIS on Windows Server 2025. The exact numbers should not be blindly transposed to every production environment, because allocator behavior, worker configuration, memory limits, proxies, and request handling differ. The direction of risk is clear: low client cost can become high server memory cost. (Calif)

Apache httpd and mod_http2

For Apache operators, CVE-2026-49975 should be treated as an HTTP/2 and mod_http2 issue, not a generic Apache web application bug.

The practical checks are:

apachectl -v
apachectl -M | grep -E 'http2|ssl'
apachectl -t -D DUMP_VHOSTS
apachectl -t -D DUMP_RUN_CFG

Then inspect whether HTTP/2 is enabled:

grep -R "^\s*Protocols" /etc/apache2 /etc/httpd 2>/dev/null
grep -R "^\s*H2" /etc/apache2 /etc/httpd 2>/dev/null

Configurations vary by distribution. Debian and Ubuntu usually use /etc/apache2. RHEL-family distributions usually use /etc/httpd. Containers may put everything under /usr/local/apache2/conf.

The public mitigation guidance for Apache said the fix landed in mod_http2 v2.0.41 and httpd trunk, and that disabling HTTP/2 with Protocols http/1.1 is a temporary fallback if a fix cannot be deployed. It also warned that lowering LimitRequestFieldSize is only a partial mitigation, and that LimitRequestFields may not help if duplicate Cookie crumbs do not count against it in the vulnerable path. (Calif)

A temporary Apache mitigation may look like this:

# Temporary mitigation only, use when patched mod_http2 is not yet available.
# Validate impact first because this disables HTTP/2 for the affected vhost.

<VirtualHost *:443>
    ServerName api.example.com
    Protocols http/1.1
    SSLEngine on

    # Existing TLS, proxy, and application config here.
</VirtualHost>

Do not treat that as a permanent substitute for patching. Disabling HTTP/2 can affect gRPC, some mobile clients, latency, and connection reuse. It is a risk-reduction move for exposed services while the correct package is being rolled out.

For Apache package managers, the version number may not tell the whole story. Enterprise distributions often backport security fixes without changing to the latest upstream version. A server may report an older Apache version while containing a patched mod_http2. The defensible check is the distro security advisory, package changelog, and, where available, a test in a controlled environment.

Useful package checks include:

# Debian or Ubuntu
dpkg -l | grep -E 'apache2|libapache2-mod'
apt-cache policy apache2

# RHEL, Fedora, AlmaLinux, Rocky Linux
rpm -qa | grep -E '^httpd|mod_http2'
dnf info httpd mod_http2 2>/dev/null || yum info httpd mod_http2

# Look for security backport notes
rpm -q --changelog mod_http2 2>/dev/null | head -80
apt changelog apache2 2>/dev/null | head -120

If you run Apache behind another HTTP/2-terminating layer, such as a CDN, nginx, Envoy, HAProxy, or cloud load balancer, confirm whether Apache actually receives HTTP/2. Many stacks terminate HTTP/2 at the edge and forward HTTP/1.1 upstream. Others use HTTP/2 all the way to origin. The difference changes exposure.

nginx and header-count hardening

nginx appears in the broader HTTP/2 Bomb disclosure, but the specific remediation path is nginx-specific. The nginx commit for max_headers says the directive limits the number of accepted request headers, adding a control beyond existing buffer limits, and the code sets a default value of 1000. (GitHub)

For nginx operators, start with version and build evidence:

nginx -v
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v2|openssl|modules'
nginx -T 2>/dev/null | grep -nE 'listen .*http2|http2 |max_headers|large_client_header_buffers'

Older nginx configurations often enabled HTTP/2 with a listen 443 ssl http2; style directive. Newer configurations may use a separate http2 directive depending on version. Do not copy-paste a mitigation from a random snippet without checking your installed nginx documentation and config test output.

The public disclosure said nginx 1.29.8 and later include max_headers with a default of 1000, and suggested disabling HTTP/2 with http2 off; if an upgrade is not possible. (Calif) Validate the exact syntax in your version before deployment:

nginx -t
systemctl reload nginx

A temporary nginx mitigation might be conceptually simple:

server {
    listen 443 ssl;
    server_name api.example.com;

    # Temporary risk reduction only.
    # Use syntax supported by your installed nginx version.
    http2 off;

    # Existing TLS and proxy configuration here.
}

The real fix is not “set a random small header size.” Header-size tuning can break legitimate traffic, especially authentication flows with large cookies or enterprise identity headers, while still missing header-count and decoded-size problems. Treat nginx hardening as a combination of patching, header count limits, decoded-size awareness, edge filtering, and memory isolation.

Envoy and CVE-2026-47774

Envoy deserves separate treatment because its official advisory is clear, detailed, and uses a different CVE.

The advisory for GHSA-22m2-hvr2-xqc8 describes an unauthenticated remote client causing excessive memory consumption through two behaviors: Cookie header bytes were not fully accounted during request header size validation, and HPACK limits applied to encoded bytes without a corresponding decoded-size limit. It states that the combination lets large decoded allocations bypass protections. (GitHub)

That advisory also explains the operational failure mode. Cookie fragments can be buffered separately and merged after validation, bypassing max_request_headers_kb; HPACK can make small encoded blocks expand after decoding; and the resulting memory growth can cause out-of-memory kills. Envoy reported an example where a development build under a 3 GiB memory limit was killed within seconds. (GitHub)

For Envoy operators, the first task is inventory. Envoy may appear as:

• an edge proxy;
• an API gateway;
• a Kubernetes ingress gateway;
• a service mesh sidecar;
• an internal east-west gateway;
• a cloud-managed proxy image;
• a vendor appliance component.

Version checks vary by deployment, but common examples include:

envoy --version

# Kubernetes examples
kubectl get pods -A -o wide | grep -i envoy
kubectl get deploy -A -o yaml | grep -i "image:.*envoy" -n
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i envoy

If the admin interface is safely available only from an administrative network, version and config evidence may be collected from /server_info ו /config_dump. Never expose Envoy’s admin interface publicly.

The official Envoy advisory says there is no complete workaround short of applying the fix, but it lists temporary mitigations such as disabling downstream HTTP/2 where feasible, enforcing stricter request header and Cookie limits before Envoy, and monitoring for memory growth, OOM kills, and unusual HTTP/2 repeated indexed Cookie references. (GitHub)

That “before Envoy” phrase is important. If Envoy is the first HTTP/2 parser exposed to the client, a WAF behind Envoy will not help. A filter must run before the vulnerable allocation path or the Envoy build itself must be patched.

IIS, Pingora, and cases with less public patch detail

The broader HTTP/2 Bomb disclosure included Microsoft IIS and Cloudflare Pingora among affected implementations. Public security coverage also repeated those names. (Calif) However, when a vendor-specific advisory or patch note is not available in the same level of detail, defenders should avoid guessing.

For IIS, the safe path is:

• confirm whether the server negotiates HTTP/2 with untrusted clients;
• check the Windows Server build and installed cumulative updates;
• monitor Microsoft’s security update channels and product documentation;
• use an edge proxy, CDN, or load balancer to restrict suspicious HTTP/2 behavior before IIS where possible;
• apply process and host memory safeguards;
• consider temporarily disabling HTTP/2 only after validating application impact.

For Pingora, the safe path is similar but depends on whether you use Pingora directly, consume it through a vendor product, or rely on a managed service that uses it internally. If you operate Pingora in your own infrastructure, track the project or vendor release notes. If you rely on a managed edge provider, verify the provider’s statement rather than assuming exposure from the underlying technology name.

The broader lesson is that “affected in public research” and “actionable patch advisory for your deployment” are not the same artifact. Vulnerability management should store both.

Safe exposure checks without running a DoS payload

Do not begin by running a public proof of concept against production. For a denial-of-service class issue, the first phase should be passive or low-impact evidence collection.

Start by checking whether a hostname negotiates HTTP/2:

curl --http2 -I https://example.com/

curl -sS -o /dev/null -D - --http2 https://example.com/ | grep -i '^HTTP/'

A response such as HTTP/2 200 confirms HTTP/2 from your client to the endpoint. It does not prove which backend component parsed the request.

ALPN negotiation can be checked with OpenSSL:

openssl s_client -connect example.com:443 -servername example.com -alpn h2 </dev/null 2>/dev/null | grep -i 'ALPN protocol'

Expected output when HTTP/2 is negotiated:

ALPN protocol: h2

Check multiple paths. CDNs and load balancers can route by hostname, path, SNI, client region, or protocol. An API domain, static asset domain, admin domain, and mobile backend may terminate HTTP/2 differently.

Next, identify the likely HTTP/2 terminator. Do not trust only the Server header:

curl -sSI --http2 https://example.com/ | grep -iE 'server:|via:|x-cache|cf-ray|x-envoy|x-request-id'

Headers can reveal useful clues, but they can also be removed, spoofed, normalized, or generated by a layer that is not the vulnerable origin.

For Kubernetes, inventory ingress and gateway objects:

kubectl get ingress -A
kubectl get gateway -A 2>/dev/null
kubectl get httproute -A 2>/dev/null
kubectl get svc -A | grep -Ei 'ingress|gateway|envoy|nginx|apache|httpd'

List container images:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -Ei 'nginx|envoy|apache|httpd|iis|gateway|ingress'

For Docker or Compose-based deployments:

docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}' | grep -Ei 'nginx|envoy|apache|httpd'
docker inspect <container_name> --format '{{json .Config.Image}}'

For systemd services:

systemctl status nginx --no-pager
systemctl status apache2 --no-pager 2>/dev/null || systemctl status httpd --no-pager
systemctl status envoy --no-pager 2>/dev/null

The goal of this phase is to answer four questions:

Question	Safe evidence
Does the endpoint negotiate HTTP/2?	ALPN and curl --http2 output
Which component terminates HTTP/2?	Config, load balancer routing, gateway deployment, service ownership
Is the component in a vulnerable version or config state?	Package version, container image digest, vendor advisory, distro changelog
Is mitigation already present?	Patched build, HTTP/2 disabled, max_headers, Envoy fixed version, Apache mod_http2 fix

Only after that should a team consider controlled dynamic validation, and only against systems they own or are explicitly authorized to test.

Detection signals that matter

HTTP access logs are not enough. Some HTTP/2 resource-exhaustion attacks can hurt the server before a normal application request is completed. Earlier HTTP/2 CONTINUATION-frame research also warned that requests may not appear in typical access logs when the attack happens at the HTTP/2 framing layer. CERT/CC’s 2024 note on CONTINUATION attacks described multiple implementations that failed to limit or sanitize CONTINUATION frames, causing memory or CPU exhaustion. (kb.cert.org)

For CVE-2026-49975 and the broader HTTP/2 Bomb family, monitor at several layers:

אות	Where to collect	What it may indicate	Common false positives	Suggested response
Rapid RSS growth in web server or proxy process	Host metrics, container metrics, process exporter	Header or stream state accumulating	Legitimate traffic spike, deploy leak	Correlate with HTTP/2 connection metrics and recent config changes
OOM kill, exit code 137	Kubernetes events, system logs, container runtime	Process exceeded memory limit	Under-sized memory limit, unrelated leak	Preserve logs, restart safely, reduce exposure, patch
Few clients holding long HTTP/2 connections	Proxy metrics, connection tracking	Slow state-retention pattern	Mobile clients, gRPC, long polling	Compare header behavior and stream counts
High rate of rejected headers or 431 responses	Edge proxy logs	Header limit enforcement firing	SSO cookies, large enterprise headers	Check source distribution and header count
Abnormal Cookie fragmentation	HTTP/2-aware proxy telemetry, debug logs in lab	Possible exploitation or probing	Some clients split Cookie normally	Treat as suspicious when volume and repetition are high
Upstream reset or local reset spikes	Envoy, gateway, load balancer metrics	Parser or policy rejecting traffic	Deployment changes, upstream outage	Correlate with memory and client IPs
Kernel OOM killer logs	dmesg, syslog, cloud logging	Host-level memory exhaustion	Other process memory leak	Check which process was killed and why

On Linux hosts, useful commands include:

dmesg -T | grep -Ei 'killed process|out of memory|oom'
journalctl -k --since "2 hours ago" | grep -Ei 'killed process|out of memory|oom'
ps -eo pid,ppid,cmd,%mem,rss --sort=-rss | head -20

For Kubernetes:

kubectl get events -A --sort-by='.lastTimestamp' | grep -Ei 'oom|killed|evicted'
kubectl top pods -A --containers | grep -Ei 'nginx|envoy|apache|httpd|gateway'
kubectl describe pod -n <namespace> <pod> | grep -Ei 'Reason:|OOMKilled|Exit Code|Last State' -A6

For Envoy, watch memory and downstream HTTP/2 metrics where available. The official advisory lists detection indicators such as rapid memory growth, OOM exits, and unusual HTTP/2 repeated indexed Cookie references. (GitHub)

Detection should not become a substitute for patching. It is there to confirm exposure, catch active probing, and validate that mitigation holds under real traffic.

Mitigation playbook

The best mitigation is a vendor fix. Temporary controls reduce risk, but they do not remove the underlying parser or accounting bug.

Patch the component that actually terminates HTTP/2

Patch by ownership boundary:

1. Public CDN or managed edge: confirm provider status and whether your custom configuration changes exposure.
2. Cloud load balancer: check provider security notices and HTTP/2 settings.
3. Kubernetes ingress: patch the controller image and verify rollout.
4. Envoy gateway or service mesh: patch gateway and sidecar images, not only the control plane.
5. nginx origin: update to a build with the header-count hardening.
6. Apache origin: update mod_http2 or distro package containing the Cookie accounting fix.
7. IIS origin: apply Microsoft guidance and cumulative updates when available.

For fleets, build a patch matrix:

דרגה	Example component	עדיפות	Reason
Internet edge	CDN custom proxy, nginx, Envoy gateway, IIS	הגבוה ביותר	Directly reachable by untrusted clients
API ingress	Kubernetes ingress, API gateway	הגבוה ביותר	Often handles authentication and high-value traffic
Service mesh ingress	Envoy gateway, sidecars receiving external traffic	גבוה	HTTP/2 may be enabled by default
Internal east-west	Sidecars, internal gateways	Medium to high	Risk depends on attacker’s network position
Origin behind HTTP/1.1 proxy	Apache or app server receiving only HTTP/1.1	Lower for this issue	Still verify no alternate HTTP/2 path exists

Disable HTTP/2 where patching is delayed

Disabling HTTP/2 is a blunt but effective temporary control when the vulnerable component is exposed and a fixed package cannot be deployed quickly.

Apache example:

<VirtualHost *:443>
    ServerName app.example.com
    Protocols http/1.1
</VirtualHost>

nginx example, subject to installed version syntax:

server {
    listen 443 ssl;
    server_name app.example.com;

    # Temporary mitigation if supported by your nginx build.
    http2 off;
}

Envoy configurations are more varied. The official advisory recommends disabling downstream HTTP/2 where feasible as a temporary mitigation, but the exact configuration depends on whether HTTP/2 is enabled through ALPN, codec options, gateway API resources, or service mesh policy. (GitHub)

Before disabling HTTP/2, check for dependencies:

תלות	מדוע זה חשוב
gRPC	Requires HTTP/2 in common deployments
Mobile APIs	May rely on HTTP/2 connection reuse for performance
Browser-facing sites	Usually tolerate HTTP/1.1 but may see latency changes
Internal service mesh	Protocol changes can break routing or observability
CDN to origin	Edge may still speak HTTP/2 to origin even if clients do not

A safe rollout uses a canary, metrics, rollback, and explicit owner approval.

Enforce decoded header size and header count

The strongest configuration posture is layered:

• limit encoded header block size;
• limit decoded total header bytes;
• limit number of header fields;
• count Cookie fragments before and after merge;
• reject suspicious repeated Cookie fragments early;
• cap concurrent streams and connection lifetime;
• isolate worker memory.

Do not rely on a single “large header buffer” setting. A larger buffer may make the service more tolerant of legitimate enterprise headers, but it can also increase memory exposure if other controls are missing. A smaller buffer may break users without addressing repeated small fields.

Add resource isolation

Resource limits do not fix CVE-2026-49975, but they limit blast radius.

For systemd services, check current memory controls:

systemctl show nginx --property=MemoryMax
systemctl show apache2 --property=MemoryMax 2>/dev/null || systemctl show httpd --property=MemoryMax

A drop-in limit might look like:

# /etc/systemd/system/nginx.service.d/memory.conf
[Service]
MemoryMax=1G
Restart=on-failure

Apply carefully:

systemctl daemon-reload
systemctl restart nginx

For containers, set memory limits and requests. Kubernetes example:

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "1000m"

Memory limits can turn a full-node outage into a pod restart. They can also cause restart loops if limits are too low. Use metrics, not guesses.

Put filters in front of the vulnerable parser

Edge filtering can help only if it runs before the vulnerable HTTP/2 parser or inside a patched parser path. A WAF behind the vulnerable component is too late.

Useful edge policies include:

• reject excessive header count;
• reject excessive Cookie fragment count;
• reject abnormal repeated Cookie patterns;
• reduce long-lived idle HTTP/2 connections;
• limit concurrent streams per connection;
• cap request header bytes after decoding where the product supports it;
• rate-limit suspicious clients by behavior, not only request count.

HAProxy’s writeup on the HTTP/2 Bomb disclosure emphasized patching and disabling HTTP/2 where patches are unavailable, and it also described edge filtering as a way to drop malicious clients when deployed in front of affected backends. (HAProxy Technologies) Treat that as a layer, not a root fix.

Safe validation workflow

A safe validation plan should prove exposure and remediation without taking down production.

A mature workflow has five stages:

1. Inventory
   Identify all HTTP/2-speaking endpoints, including public edge, API gateways, ingress controllers, service mesh gateways, sidecars, and origins.
2. Version and config evidence
   Collect package versions, container image digests, module lists, and HTTP/2 configuration. Store command output with timestamps.
3. Non-destructive protocol checks
   Confirm ALPN negotiation and HTTP/2 support with benign requests.
4. Controlled lab reproduction
   If exploit behavior must be validated, reproduce it only in an isolated clone with strict memory limits, no production traffic, and written authorization.
5. Patch verification
   Re-run benign exposure checks, confirm fixed versions, confirm config changes, and watch memory metrics under normal load.

For teams using AI-assisted security workflows, the useful automation is not “fire a DoS exploit at everything.” It is disciplined evidence collection: enumerate HTTP/2 endpoints, correlate versions with advisories, preserve config snippets, open scoped remediation tickets, and verify the fix. A platform such as Penligent can support that kind of authorized agentic workflow when operators keep destructive validation gated and human-approved; its own CVE-2026-49975 HTTP/2 Bomb analysis also distinguishes the Apache-side CVE from the broader HTTP/2 Bomb family. The operational rule remains the same: automate discovery and evidence, not unsupervised outage testing.

A useful internal report should include:

Evidence item	דוגמה
Endpoint	https://api.example.com negotiates h2
HTTP/2 terminator	Envoy gateway deployment edge-gateway
Version	Envoy image digest and version output
Advisory mapping	CVE-2026-47774 for Envoy, not CVE-2026-49975
Exposure	Public internet, unauthenticated
הפחתה	Upgraded to fixed version or HTTP/2 disabled
איתור	Memory dashboard link, OOM log query
Retest	Benign ALPN and version checks after rollout
Residual risk	Internal sidecars still under review

That level of evidence is what auditors, incident commanders, and engineering leads can act on.

How CVE-2026-49975 compares with earlier HTTP/2 DoS bugs

CVE-2026-49975 is not the first serious HTTP/2 denial-of-service issue. It belongs to a pattern: HTTP/2 gives implementations powerful features, and attackers look for places where state management, limits, or lifecycle handling break under adversarial input.

Issue	Main primitive	Pressure type	מדוע זה חשוב במקרה זה
CVE-2023-44487, HTTP/2 Rapid Reset	Rapid stream creation and reset	CPU, stream management, request handling	Shows how low-cost HTTP/2 control behavior can create large server work
HTTP/2 CONTINUATION Flood, including CVE-2024-27316 for Apache httpd	Unbounded or poorly limited CONTINUATION frames	Memory or CPU exhaustion	Shows that header block lifecycle and END_HEADERS handling are recurring attack surfaces
CVE-2026-49975	Cookie accounting and HTTP/2 Bomb behavior in Apache-side tracking	Memory exhaustion	Shows why decoded header size, header count, and merge accounting must align
CVE-2026-47774	Envoy Cookie header size bypass plus HPACK amplification	Memory exhaustion	Shows the same bug family can require separate vendor CVEs and fixes

CVE-2023-44487, known as Rapid Reset, was exploited in the wild in 2023 and involved HTTP/2 request cancellation behavior that allowed attackers to create high server load. NVD describes it as an HTTP/2 protocol issue involving request cancellation and rapid stream resets, exploited in the wild from August through October 2023. (NVD)

The 2024 CONTINUATION-frame wave is another close relative. CERT/CC described a class of vulnerabilities where implementations did not properly limit or sanitize CONTINUATION frames, allowing attackers to cause out-of-memory crashes or CPU exhaustion. The CERT note lists multiple implementation-specific CVEs, including CVE-2024-27316 for Apache httpd. (kb.cert.org)

CVE-2026-49975 is different in mechanics. It is not primarily about rapid stream resets or endless CONTINUATION frames. Its practical center is decoded header memory, Cookie fragmentation, HPACK amplification, and retained state. But the strategic lesson is the same: HTTP/2 security cannot be reduced to request-per-second rate limits. You need protocol-aware limits.

Common mistakes during remediation

The most dangerous mistakes are the ones that look reasonable during an emergency.

Mistake one, treating a Server header as inventory

A response header such as Server: cloudflare, Server: nginx, או Server: Apache may be true, partial, or intentionally misleading. It may describe the CDN, not the origin. It may describe the origin, not the HTTP/2 terminator. It may be stripped or rewritten.

Use real infrastructure inventory, config, package data, and routing knowledge.

Mistake two, patching origin but not gateway

Many modern stacks terminate HTTP/2 before origin. If Envoy, nginx ingress, a cloud load balancer, or a service mesh gateway terminates client HTTP/2, patching only the application server may not address the exposed parser.

Trace the path:

client
  -> CDN
  -> cloud load balancer
  -> ingress controller
  -> service mesh gateway
  -> sidecar
  -> application server

At each hop, ask whether HTTP/2 is accepted downstream or upstream.

Mistake three, lowering one header-size setting and calling it fixed

A smaller header-size setting may help some cases, but CVE-2026-49975-style risk involves count, decoded size, Cookie merge accounting, and state lifetime. If the vulnerable path uses many small fields, the single-value limit may never fire.

Mistake four, leaving internal HTTP/2 out of scope

Attackers who gain a foothold inside the network may reach internal gateways that were never hardened like the public edge. Service mesh environments often use Envoy heavily. Internal does not mean safe; it means the exploit prerequisite changes from internet access to network position.

Mistake five, running a public PoC in production

A denial-of-service proof of concept is not a harmless scanner. Public reporting says a companion repository and PoC were published for HTTP/2 Bomb. (BleepingComputer) That does not make it safe to point at production. Use non-destructive checks first, then isolate any exploit validation in a lab.

Mistake six, assuming autoscaling is a fix

Autoscaling may add capacity while the attack consumes it. Worse, it can raise cloud spend during an incident. Autoscaling is useful for resilience, but a parser-level memory bug needs a parser-level fix or a pre-parser rejection layer.

First 24 hours response plan

When CVE-2026-49975 appears in your vulnerability feed, the first day should be structured. Panic wastes time.

Hour 0 to 2, classify exposure

Build a quick list:

• internet-facing HTTP/2 endpoints;
• Apache httpd with mod_http2;
• nginx terminating HTTP/2;
• Envoy gateways and sidecars;
• IIS servers exposed over TLS;
• managed edge services that terminate HTTP/2;
• Kubernetes ingress controllers;
• gRPC services.

Use ALPN checks and infrastructure inventory. Do not depend only on scanner labels.

Hour 2 to 6, map components to advisories

Create a table:

Service	HTTP/2 terminator	Version	Advisory	Owner	Exposure	פעולה
api.example.com	Envoy gateway	1.37.2	CVE-2026-47774	פלטפורמה	Public	Patch gateway
www.example.com	nginx	1.29.7	HTTP/2 Bomb hardening	Web platform	Public	Upgrade or disable HTTP/2
legacy.example.com	Apache mod_http2	distro package	CVE-2026-49975	Infra	Public	Check backport or disable HTTP/2
internal-grpc	Envoy sidecars	mixed	CVE-2026-47774	Service mesh	פנימי	Patch mesh image

Hour 6 to 12, deploy lowest-risk mitigations

Prioritize internet-facing services. If a fixed package is available, patch. If no fix is available and exposure is high, consider temporarily disabling HTTP/2 or placing a patched edge layer in front.

During the rollout, watch:

• 4xx rates;
• 5xx rates;
• latency;
• gRPC failures;
• mobile app errors;
• memory usage;
• OOM events;
• connection counts.

Hour 12 to 24, verify and document

For each remediated service, store:

• command output showing version;
• config output showing HTTP/2 state;
• package changelog or advisory link;
• deployment timestamp;
• dashboard screenshot or metric link;
• post-change ALPN result;
• owner sign-off;
• rollback plan.

The result should be a defensible record, not a Slack thread that disappears.

Deeper engineering lesson, charge every byte to the right budget

CVE-2026-49975 is a reminder that protocol implementation security is accounting.

Every expensive object needs to be charged to a budget:

• decoded header bytes;
• header field count;
• Cookie fragment count;
• merged Cookie size;
• HPACK dynamic table memory;
• per-stream state;
• per-connection state;
• request body buffers;
• upstream forwarding buffers;
• logging buffers;
• WAF inspection buffers;
• application header maps.

The budget must apply at the right time. A limit checked after allocation may still allow memory spikes. A limit checked before Cookie merge may miss merge-created cost. A limit checked on encoded bytes may miss decoded cost. A limit checked per header may miss aggregate cost. A timeout without a memory cap may allow thousands of expensive states to accumulate before cleanup.

A safer design treats request processing as a set of quotas:

connection_budget
  ├── stream_budget
  │     ├── decoded_header_bytes_budget
  │     ├── header_count_budget
  │     ├── cookie_fragment_budget
  │     ├── request_body_budget
  │     └── upstream_buffer_budget
  └── lifetime_budget
        ├── idle_timeout
        ├── header_receive_timeout
        ├── stream_duration_limit
        └── suspicious_state_cleanup

The moment any budget is exceeded, the implementation should reject early and free state. That is easier to say than to implement, but it is the correct mental model for reviewing HTTP/2 parser and proxy code.

שאלות נפוצות

Is CVE-2026-49975 the same as HTTP/2 Bomb?

• Not exactly. CVE-2026-49975 is publicly tied to the Apache-side tracking of the HTTP/2 Bomb disclosure, especially mod_http2 Cookie header accounting.
• HTTP/2 Bomb is the broader bug class and disclosure name covering multiple implementations.
• Envoy’s related issue is tracked separately as CVE-2026-47774 in the official Envoy advisory.
• For remediation, always map the finding to the exact product, version, and advisory rather than assuming one CVE covers every affected stack.

Does disabling HTTP/2 fully remove the risk?

• Disabling HTTP/2 on the exposed vulnerable component removes this specific HTTP/2 attack path for that listener.
• It does not patch the underlying software.
• It may break or degrade gRPC, service mesh traffic, mobile API performance, or browser connection reuse.
• It may not help if another layer still accepts HTTP/2 before traffic reaches the disabled component.
• Use it as a temporary mitigation when patching is delayed, not as the final state.

Is nginx affected by CVE-2026-49975?

• nginx was included in the broader HTTP/2 Bomb disclosure, but CVE-2026-49975 should not be treated as a blanket nginx CVE without checking vendor-specific tracking.
• nginx 1.29.8 added the max_headers directive, with the commit setting a default of 1000 accepted request headers.
• Defenders should verify nginx version, HTTP/2 exposure, whether max_headers exists in their build, and whether a distro or vendor backport applies.
• If an upgrade is not immediately possible, disabling HTTP/2 on exposed listeners may reduce risk while a real fix is prepared.

Why do normal header size limits fail here?

• Some limits apply to encoded HTTP/2 header bytes, while the server pays memory cost after HPACK decoding.
• Some limits apply to one header value, while the attack pattern can use many small fields or Cookie fragments.
• Some limits apply before Cookie merge or normalization, while the expensive state appears after merge.
• Some limits reject the request too late, after memory has already been allocated and retained.
• Effective defense needs decoded-size limits, header-count limits, correct Cookie accounting, and early cleanup.

What is the safest way to check whether a service is exposed?

• First confirm whether the endpoint negotiates HTTP/2 using benign ALPN or curl --http2 checks.
• Identify the actual HTTP/2 terminator through infrastructure inventory, not only response headers.
• Collect package versions, container image digests, module lists, and configuration output.
• Compare those findings against vendor advisories and distro security trackers.
• Avoid running DoS proof-of-concept code against production. Use isolated lab validation only with explicit authorization.

How is CVE-2026-49975 different from CVE-2023-44487?

• CVE-2023-44487, Rapid Reset, abused rapid HTTP/2 stream creation and cancellation to create server work.
• CVE-2026-49975-style HTTP/2 Bomb behavior focuses on HPACK decoding, Cookie header accounting, and memory retained across connection or stream lifetime.
• Both are HTTP/2 denial-of-service issues, but the exploited primitives differ.
• Defenses overlap at the operational layer, such as stream limits, rate limits, and patching, but parser-specific fixes are different.

Should I run the public PoC against production?

• No, not as a first step.
• This is a denial-of-service class vulnerability, and a successful test may cause the outage you are trying to prevent.
• Start with passive inventory, benign HTTP/2 checks, version evidence, and configuration review.
• If dynamic validation is required, run it only in a cloned or isolated environment with strict memory limits and written authorization.
• Production validation should focus on confirming patched versions and safe behavior, not reproducing memory exhaustion.

What should I patch first?

• Patch the internet-facing HTTP/2 terminator first.
• Prioritize Envoy gateways, nginx edge servers, Apache mod_http2 servers, IIS endpoints, and ingress controllers exposed to untrusted clients.
• Then patch internal gateways and service mesh components reachable from less-trusted network zones.
• Do not forget sidecars and managed gateway images; they may terminate HTTP/2 even when the application server does not.
• If you cannot patch immediately, reduce exposure by disabling HTTP/2 on the vulnerable listener or placing a patched enforcement layer in front.

CVE-2026-49975 is not just another line in a vulnerability feed. It is a sharp example of how modern protocol features create security debt when implementations account for the wrong thing at the wrong time. HTTP/2 header handling needs more than a maximum wire-size check. It needs decoded-size limits, header-count limits, correct Cookie merge accounting, stream lifetime controls, and memory isolation.

For defenders, the winning move is disciplined and specific: find every place that accepts HTTP/2, identify the real parser, map it to the correct advisory, patch or disable exposure, and preserve evidence that the fix landed. The systems most at risk are not necessarily the ones with the most traffic. They are the ones that let cheap client input become expensive server state and then keep that state alive.