CVE-2026-49975, the HTTP/2 Bomb Behind Header Limits

CVE-2026-49975 sits in the uncomfortable part of HTTP/2 security where a request does not need to be large, authenticated, or obviously malicious to become expensive. The risk is not that every HTTP/2 server is automatically vulnerable. The risk is that specific HTTP/2 implementations accepted small compressed header patterns that could expand into costly internal objects, then kept those objects alive long enough to create remote memory pressure.

The public disclosure that brought the issue into view described a broader “HTTP/2 Bomb” class affecting several major server stacks, including Apache httpd, nginx, Microsoft IIS, Envoy, and Cloudflare Pingora. The same disclosure tied CVE-2026-49975 to the Apache-side issue and specifically to how cookie header fragments were accounted against Apache’s request-field limits. Envoy later published a separate advisory for a closely related issue under CVE-2026-47774, with patched versions across supported release lines. (blog.calif.io)

That distinction matters. CVE-2026-49975 should not be treated as a single universal bug in the HTTP/2 protocol. It is better understood as one concrete CVE in a larger family of implementation failures around HPACK decoding, header counting, cookie merging, and stream lifetime management. A defender who only asks “Do we support HTTP/2?” will get an answer that is too broad. A defender who asks “Where do we terminate HTTP/2, which implementation is doing it, what version is running, what header-count limit applies after cookie splitting, and how long can stalled streams retain memory?” is asking the right question.

The short version defenders need

The useful operational summary is simple enough to act on, but not simple enough to reduce to a banner check.

CVE-2026-49975 is associated with Apache httpd’s HTTP/2 handling, particularly the accounting of split Cookie headers against request field limits. Apache’s mod_http2 update to version 2.0.41 includes a fix described as cookie header accounting against LimitRequestFields, and the code change makes merged cookie handling count in a way that prevents those fragments from escaping the configured field limit. (GitHub)

The wider HTTP/2 Bomb disclosure showed the same general failure mode across multiple servers: a small number of bytes on the wire can cause much larger server-side allocations when HPACK indexed references, many header fragments, and stalled HTTP/2 streams interact. In researcher-run lab demonstrations, Envoy and Apache showed very high amplification ratios, while nginx and IIS showed lower but still serious memory pressure patterns. Those numbers should be treated as lab observations, not universal measurements for every deployment. (blog.calif.io)

For nginx, the most concrete public hardening signal is the new max_headers directive, introduced in nginx 1.29.8 with a default value of 1000. The directive limits the number of request header lines and returns a 400 response when the limit is reached. (Nginx)

For Envoy, the related advisory is not CVE-2026-49975. Envoy tracks the issue as CVE-2026-47774 and GHSA-22m2-hvr2-xqc8. The advisory states that affected Envoy versions before the patched releases could be driven into excessive memory consumption by unauthenticated remote clients through incomplete accounting of cookie header bytes and HPACK decoded size behavior. Patched versions listed by Envoy are 1.35.11, 1.36.7, 1.37.3, and 1.38.1. (GitHub)

For defenders, the right immediate path is not to run a public DoS proof of concept against production. The right path is to inventory HTTP/2 termination points, identify the exact implementation and version, verify whether the relevant patch or mitigation is present, add or confirm hard header-count limits, disable HTTP/2 temporarily where the risk is unacceptable, and collect evidence that remediation actually changed behavior.

What CVE-2026-49975 actually tracks

The public CVE ecosystem often lags the first technical write-up. That matters here because the identifier CVE-2026-49975 appeared in the researcher disclosure and downstream tracking before every public CVE database presented a fully detailed record. CVE.org search results showed the candidate as reserved, while downstream sources such as SUSE tracked the issue against Apache packages and assigned severity information. (CVE)

That does not make the issue speculative. The Apache-side fix is visible in the project’s source history. Apache’s commit updating mod_http2 to 2.0.41 includes a changelog entry for fixing cookie header accounting against LimitRequestFields, and the code path changes how cookie header fragments are handled so that merging does not bypass field-count enforcement. (GitHub)

The narrow interpretation is therefore:

Question	Practical answer
Is CVE-2026-49975 a protocol-wide HTTP/2 CVE	No. It is tied to a concrete implementation issue and public Apache-side tracking.
Is it related to the HTTP/2 Bomb disclosure	Yes. It belongs to the same disclosed family of HPACK, header accounting, and stalled-stream memory pressure.
Does it automatically mean every HTTP/2 server is vulnerable	No. Each implementation needs separate version and configuration checks.
Is Envoy’s related issue the same CVE	No. Envoy published CVE-2026-47774 for its related vulnerability.
Can a scanner safely prove this on production by sending the bomb	Usually no. Because the impact is denial of service, destructive validation belongs only in authorized lab or maintenance-window conditions.

The most important thing for a security team is not the label alone. The important thing is whether an internet-facing HTTP/2 endpoint is running an implementation that counts the wrong thing, fails to cap the right thing, or keeps expensive decoded objects alive for too long.

Why the attack works

HTTP/2 moved a large amount of connection state below the level most application teams inspect. That is useful for performance, but it also means an edge server can spend memory and CPU before a request reaches application code, middleware, route handlers, WAF logic, or normal observability fields.

The HTTP/2 Bomb class combines several facts that are individually legitimate.

First, HPACK is stateful header compression. A decoder maintains a dynamic table, and compressed header blocks can refer to entries by index rather than retransmitting full header names and values. RFC 7541 explicitly discusses dynamic table memory and the role of SETTINGS_HEADER_TABLE_SIZE, but the specification’s memory discussion is primarily about compression-state limits, not every temporary allocation a server might create while processing decoded header lists. (Editor de RFC)

Second, HTTP/2 has special Cookie handling. RFC 9113 allows Cookie header fields to be split into multiple fields to improve compression efficiency, and it requires those fields to be concatenated with ; before they are passed into a non-HTTP/2 context. (Editor de RFC)

Third, HTTP/2 flow control lets a receiver regulate DATA frame transmission on streams and connections. The flow-control mechanism is hop-by-hop, applies to DATA frames, and is driven by window updates. In ordinary traffic, this prevents one side from overwhelming the other. In the HTTP/2 Bomb pattern, the same stream-lifetime mechanics can keep server-side allocations around longer than a server author expected. (Editor de RFC)

Those three facts create the opening. A small compressed header block can cause a large number of decoded header entries or internal references. Cookie crumbs can be treated differently from ordinary headers because they are validly split and later merged. If a server checks only the encoded size, only the decoded aggregate bytes, or only the post-merge field view, it may miss the number of objects created along the way. If the response stream is then stalled through flow-control behavior, the memory is not released immediately.

The result is an availability bug that looks smaller at the packet layer than it feels at the process layer. A packet capture may not show a giant request body. An application log may show little or nothing, because the request may never become a normal application request. The worker or proxy process simply grows, swaps, stalls, restarts, or dies.

The exploit chain without unsafe payload details

A safe explanation of the attack chain is enough to understand the risk without giving a production-ready denial-of-service recipe.

At a high level, the attack behaves like this:

1. The client opens an HTTP/2 connection to a vulnerable endpoint.
2. The client causes the server-side HPACK decoder to process a pattern where small encoded references become many internal header objects.
3. The header list uses forms that are legal under HTTP/2 semantics, especially split Cookie fields.
4. The implementation accounts for the wrong boundary, such as encoded header block size, final merged size, or ordinary field count, while missing temporary fragments or repeated decoded references.
5. The client keeps one or more streams alive so the expensive objects are retained instead of promptly freed.
6. Memory pressure accumulates across streams or connections until the process slows, hits a memory cap, swaps, restarts, or is killed by the operating system.

That model is enough for defenders to reason about exposure. The exact bytes are not necessary for routine triage. In fact, they are dangerous in the wrong environment. A real proof of concept for this class is a DoS test. Running it against a production API, a shared CDN origin, a customer application, or a bug bounty target without explicit scope and rate limits can create the same outage the vulnerability describes.

The public disclosure also emphasized that the goal of a practical attacker is not always to crash the process immediately. Crashing a worker may produce obvious logs and quick restarts. A more damaging outcome can be sustained memory pressure below the out-of-memory threshold, because that can push the host into swap, increase latency, starve other workers, and make the service appear randomly unstable. (blog.calif.io)

Why header byte limits were not enough

Many teams assume that request header limits already solve this problem. They often do not.

Header controls can apply to different things:

Limit type	What it usually controls	Why it may fail against HTTP/2 Bomb patterns
Encoded header block size	Bytes received over the wire before HPACK decoding	HPACK indexed references can be small before decoding.
Decoded aggregate header size	Total decoded name and value bytes	It may miss object count, duplicate fragments, or allocation overhead.
Header field count	Number of accepted header fields	Cookie splitting and later merging can escape counting if implemented incorrectly.
Per-header field size	Maximum size of one header value	Many small fragments can be worse than one large value.
Dynamic table size	HPACK compression state memory	It does not necessarily cap all temporary decoded header objects.
Stream timeout	Duration of inactive or slow streams	It may not release memory quickly enough if the stream remains technically valid.
Process memory limit	Maximum memory available to worker or container	It limits blast radius but does not fix the vulnerable parser behavior.

The Apache-specific bug is a good example. The relevant fix was not “make headers smaller.” It was to ensure that cookie header handling is accounted against the configured field limit. The Apache commit for mod_http2 2.0.41 changes the cookie merge behavior and records the change as a fix for cookie header accounting against LimitRequestFields. (GitHub)

Envoy’s advisory shows the same pattern from another angle. Envoy described two interacting weaknesses: cookie fragments were buffered and merged after validation in a way that could bypass max_request_headers_kb, and HPACK limits were enforced on encoded bytes without an equivalent decoded-size limit in the affected path. The advisory also notes that flow-control stalling can extend the lifetime of per-stream allocations. (GitHub)

The lesson is broader than one product. HTTP/2 security controls need to cap not only the bytes a client sends, but also the number of internal objects a server creates and the time those objects are retained.

Affected software and current patch signals

Patch state changes quickly after a coordinated or semi-coordinated disclosure. The table below is a practical triage map, not a substitute for checking your vendor channel, package repository, container image, and build flags.

Componente	Public signal	Qué verificar	Temporary mitigation when patching is delayed
Apache httpd with mod_http2	CVE-2026-49975 is tied to Apache-side HTTP/2 cookie header accounting. mod_http2 2.0.41 includes the relevant fix. (GitHub)	Exact httpd version, mod_http2 version, distro backport status, whether Protocols enables h2 or h2c.	Disable HTTP/2 with Protocols http/1.1 where acceptable; patch through vendor packages when available.
nginx	nginx 1.29.8 introduced max_headers, defaulting to 1000 header lines, returning 400 when exceeded. (Nginx)	nginx version, whether the running binary includes the directive, whether HTTP/2 is enabled on each server block.	Upgrade or disable HTTP/2 on exposed listeners if upgrade is not possible.
Envoy	Envoy tracks the related issue as CVE-2026-47774, with patched versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1. (GitHub)	Envoy version, downstream HTTP/2 listener config, proxy role, container memory limits.	Upgrade; disable downstream HTTP/2 where acceptable; enforce stricter edge header limits before Envoy.
Microsoft IIS	The broader disclosure reported IIS as affected in lab testing. (blog.calif.io)	Windows Server version, IIS role, HTTP/2 enablement, vendor patch or mitigation guidance.	Disable HTTP/2 on exposed endpoints if vendor guidance or local testing indicates unacceptable risk.
Cloudflare Pingora	The broader disclosure reported Pingora as part of the affected family. (blog.calif.io)	Whether your organization runs Pingora directly or depends on a provider that does, and what provider guidance says.	Follow vendor/provider guidance; do not assume origin safety only because traffic passes through a CDN.
Linux distribution packages	SUSE tracks CVE-2026-49975 as important, and Debian’s tracker showed vulnerable and fixed states varying by release. (SUSE)	Distro advisory, package changelog, backport patch level, service restart status.	Use distro-supported mitigations while waiting for fixed packages.

Two operational warnings belong next to this table.

First, a version string can lie. Vendors backport fixes. Container images may include patched source with an older upstream version label. Reverse proxies may hide origin versions. Some teams also deliberately suppress banners. Treat the version string as one piece of evidence, not proof.

Second, the vulnerable component may not be the application server your developers think about. It may be an ingress controller, service mesh gateway, API gateway, CDN origin shield, sidecar proxy, load balancer module, Windows reverse proxy, or old container image inherited from a platform team.

Safe exposure checks

The safest first step is to determine where HTTP/2 is exposed. These commands do not prove exploitability. They help locate endpoints that deserve version and configuration review.

For a public endpoint, check whether the TLS negotiation offers HTTP/2:

curl -vk --http2 https://target.example/ -o /dev/null

Look for a line showing that the server accepted h2. You can also check ALPN directly:

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

If the result shows ALPN protocol: h2, the endpoint supports HTTP/2 at that layer. That does not identify the origin server. A CDN, load balancer, or edge gateway may be the HTTP/2 terminator.

For nginx, collect the binary version and relevant configuration:

nginx -v

nginx -T 2>/dev/null | grep -E 'listen .*http2|http2|max_headers|large_client_header_buffers'

On nginx 1.29.8 and later, check whether max_headers is present and whether the default or configured value is appropriate for your environment. The official directive documentation states that the default is 1000 and that nginx returns 400 when the number of header lines reaches the limit. (Nginx)

For Apache httpd, check whether HTTP/2 support is loaded and enabled:

apachectl -v
apachectl -M | grep -i http2
apachectl -t -D DUMP_VHOSTS

grep -RInE '^\s*Protocols|^\s*H2|^\s*LimitRequest' /etc/apache2 /etc/httpd 2>/dev/null

Pay attention to Protocols h2 http/1.1, Protocols h2c http/1.1, and virtual-host-specific overrides. Also check whether your distribution has shipped a patched mod_http2 package or whether you are relying on an upstream source build.

For Envoy, start with the version and the admin config dump if the admin interface is available only on a trusted local interface:

envoy --version

curl -s http://127.0.0.1:9901/config_dump > envoy-config.json

jq '.. | objects | select(has("http2_protocol_options") or has("typed_config"))' envoy-config.json | head

Envoy’s own advisory describes the affected condition as a downstream HTTP/2 issue that can be triggered by unauthenticated remote clients, so internet-facing gateways and ingress paths deserve priority. (GitHub)

For Kubernetes, inventory ingress controllers, gateways, and images before testing any payload behavior:

kubectl get pods -A -o wide | egrep 'nginx|httpd|apache|envoy|istio|gateway'

kubectl get deploy,ds -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{" "}{range .spec.template.spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | egrep 'nginx|httpd|apache|envoy'

If you run a service mesh, remember that the sidecar or gateway may terminate or originate HTTP/2 even when the application container itself speaks HTTP/1.1.

Evidence that is worth collecting

A strong CVE-2026-49975 triage record contains more than a scanner result. It should help an engineer reproduce the decision without running a dangerous payload.

Useful evidence includes:

Pruebas	Por qué es importante
ALPN result showing h2	Confirms HTTP/2 is exposed at the tested layer.
Component name and version	Connects the endpoint to Apache, nginx, Envoy, IIS, Pingora, or another implementation.
Package changelog or commit reference	Shows whether the fix is present even when the version string is backported.
HTTP/2 enablement config	Distinguishes installed-but-disabled modules from active exposure.
Header-count and size-limit config	Shows whether a hard cap exists at the right layer.
Memory limit for worker or container	Defines blast radius if parser-layer mitigation fails.
Access and error log snippets	Helps correlate unusual requests or 400 responses after mitigation.
Restart or OOM records	Shows whether the issue has produced real availability symptoms.
Remediation diff	Proves what changed and supports audit or customer reporting.

For teams using AI-assisted validation workflows, the safest value is controlled evidence collection rather than autonomous exploitation. Penligent describes agentic workflows where operators can lock scope and control actions, and its AI pentesting workflow material emphasizes authorized scope, evidence chains, validation loops, and false-positive handling. That model maps well to this issue: automation can gather ALPN results, package data, config snippets, memory-limit evidence, and remediation status, while any destructive DoS validation remains gated behind explicit authorization and a safe test environment. (Penligente)

The important line is control. A tool that can reproduce a denial-of-service condition must not be allowed to spray payloads across production infrastructure. A useful workflow makes the boring evidence fast and leaves high-risk validation to a deliberate human decision.

Mitigation playbook

The best mitigation is to run a fixed version of the affected component. If that is not immediately possible, reduce the exposed protocol surface and contain the blast radius.

For Apache httpd, confirm whether the mod_http2 fix is present. The relevant Apache source change is in the mod_http2 2.0.41 update and specifically addresses cookie header accounting against LimitRequestFields. (GitHub)

If you cannot patch immediately and HTTP/2 is not a hard requirement, disable it on exposed virtual hosts:

Protocols http/1.1

Then reload or restart Apache according to your operating system:

apachectl configtest
systemctl reload apache2 || systemctl reload httpd

Do not assume that lowering only LimitRequestFieldSize fully mitigates the issue. A per-field byte limit does not necessarily address many small cookie fragments or object-count amplification. LimitRequestFields becomes more meaningful when the implementation correctly accounts for split and merged Cookie fields.

For nginx, upgrade to a version that includes max_headers if your deployment is affected by the broader class. nginx documents max_headers as available in 1.29.8, with a default of 1000. (Nginx)

A simple hardened default may look like this on versions that support the directive:

http {
    max_headers 1000;

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

        # normal TLS and proxy configuration
    }
}

If you cannot upgrade and your risk tolerance is low, disable HTTP/2 on the exposed listener using the syntax supported by your nginx version. On newer nginx configurations, that may mean setting the HTTP/2 directive off where available; on older configurations, it may mean removing http2 from the listen directive and reloading after a config test.

nginx -t
systemctl reload nginx

For Envoy, use the patched release lines named in Envoy’s advisory. The advisory states that fixes need to address both buffered cookie accounting and decoded header size behavior, and that fixing only one side may leave residual risk. (GitHub)

A temporary Envoy mitigation may include disabling downstream HTTP/2 for high-risk public listeners or enforcing stricter header and cookie limits at a layer in front of Envoy. Because Envoy deployments vary widely across API gateways, service mesh ingress, edge proxies, and sidecars, teams should validate the exact listener path rather than relying on a global version inventory.

For all server stacks, resource isolation matters. It does not fix the bug, but it can prevent one worker from exhausting the whole node.

For a systemd-managed service, review the current memory cap:

systemctl show nginx --property=MemoryMax
systemctl show apache2 --property=MemoryMax
systemctl show httpd --property=MemoryMax

A conservative override can cap the service while you patch and test:

[Service]
MemoryMax=512M

Apply the override through systemctl edit, then reload systemd and restart during a maintenance window:

systemctl daemon-reload
systemctl restart nginx

For Kubernetes workloads, set memory requests and limits on ingress controllers, gateways, and proxy pods:

resources:
  requests:
    memory: "256Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"
    cpu: "500m"

A memory limit is not a substitute for patching. It is a circuit breaker. Without a limit, a single proxy process may pressure the node. With a limit, the pod may restart, but the damage is more likely to stay inside the workload boundary.

Detection and monitoring

Detection is hard because the attack may not look like a classic flood. A few HTTP/2 connections can matter more than thousands of ordinary HTTP/1.1 requests. The strongest signal is usually a mismatch: low request volume, low bandwidth, but rapidly increasing memory in a proxy or web-server process.

Start with process and container memory.

For Kubernetes, monitor memory and OOM restarts around HTTP/2-facing workloads:

max_over_time(container_memory_working_set_bytes{container=~"nginx|httpd|envoy"}[5m])

increase(kube_pod_container_status_restarts_total{reason="OOMKilled"}[15m])

If your metrics include pod labels, narrow the query to ingress, gateway, and edge namespaces:

max by (namespace, pod, container) (
  container_memory_working_set_bytes{
    namespace=~"ingress|gateway|istio-system|edge"
  }
)

On Linux hosts, look for kernel OOM activity and service restarts:

journalctl -k --since "30 minutes ago" | grep -Ei 'out of memory|oom|killed process'

journalctl -u nginx --since "30 minutes ago"
journalctl -u apache2 --since "30 minutes ago"
journalctl -u httpd --since "30 minutes ago"
journalctl -u envoy --since "30 minutes ago"

For nginx after the max_headers control is active, watch for requests rejected because too many header lines were sent. Exact log messages can vary by build and configuration, so use broad searches first:

grep -Ei 'too many.*header|header.*too many|400' /var/log/nginx/error.log

For Apache, combine access-log anomalies with worker memory and error logs. The attack may not produce an application-level route hit, so do not rely only on application logs.

ps -o pid,ppid,rss,cmd -C apache2 -C httpd --sort=-rss | head

grep -Ei 'h2|http2|header|field|limit|memory|segmentation|child' /var/log/apache2/error.log /var/log/httpd/error_log 2>/dev/null

For Envoy, the official advisory lists practical indicators such as abnormal memory growth, container OOM exits, and unusual HTTP/2 traffic with repeated indexed cookie references. (GitHub)

If you capture traffic, focus on metadata and shape, not on sharing exploit payloads. Useful observations include:

Señal	Defensive interpretation
ALPN h2 from a small number of clients	Confirms the traffic reached the HTTP/2 parser.
Many streams from few connections	Possible attempt to multiply retained per-stream state.
Header-heavy requests with low bandwidth	Consistent with compression amplification.
Repeated Cookie fragments	Relevant to cookie accounting issues.
DATA flow-control stalling	May explain why stream memory is retained.
Memory growth without request-body volume	Points away from ordinary upload floods.

Detection should be paired with mitigation evidence. After patching or disabling HTTP/2, the same monitoring panels should show stable memory under normal traffic. If memory still climbs under low-bandwidth HTTP/2 traffic, the endpoint may still be exposed through another layer.

Operating in Kubernetes and service mesh environments

Kubernetes and service mesh deployments make this class harder to reason about because HTTP/2 can appear in more places than the public hostname suggests.

An application may receive HTTP/1.1, while the ingress controller terminates HTTP/2. A gateway may accept HTTP/2 from the internet and then speak HTTP/1.1 upstream. A service mesh may use HTTP/2 internally even if the external route does not. gRPC services may depend on HTTP/2 by design. A CDN may terminate HTTP/2 at the edge while the origin also supports HTTP/2 for origin pulls.

A practical inventory should include:

kubectl get ingress -A

kubectl get gateway -A 2>/dev/null

kubectl get httproute -A 2>/dev/null

kubectl get svc -A | egrep 'LoadBalancer|NodePort'

Then identify the running images:

kubectl get deploy,ds,sts -A \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{" "}{range .spec.template.spec.containers[*]}{.name}{":"}{.image}{" "}{end}{"\n"}{end}' \
  | egrep 'nginx|envoy|apache|httpd|istio|gateway|ingress'

For each candidate, answer these questions:

Question	Por qué es importante
Does this pod accept traffic from the internet or only from the cluster	Internet-facing exposure gets priority.
Does the listener enable HTTP/2 downstream	The vulnerable parser is on the downstream side.
Does the workload use a patched image	Tags such as latest are not evidence.
Is there a memory limit	Without a limit, one proxy can pressure the node.
Is there a second HTTP/2 hop behind the first gateway	Patching only the edge may leave origin or mesh exposure.
Does gRPC require HTTP/2	Disabling HTTP/2 may break functionality.
Are canary and blue-green versions different	Old gateway pods may remain in service after patching.

In mesh environments, avoid one dangerous assumption: “The edge gateway is patched, so the cluster is safe.” That may be true for external attackers, but not for internal tenants, compromised workloads, SSRF paths, or partner networks that can reach internal HTTP/2 listeners.

Lessons from related HTTP/2 CVEs

CVE-2026-49975 belongs to a long pattern. HTTP/2 has repeatedly produced vulnerabilities where the protocol’s valid features become implementation stress tests.

Envoy’s CVE-2026-47774 is the closest relative. The advisory describes unauthenticated remote DoS through excessive memory consumption, caused by incomplete accounting of cookie header bytes and encoded-versus-decoded HPACK limits. It also describes flow-control stalling as a way to keep per-stream allocations alive. The fix spans multiple release lines, which is a sign that the issue affected supported production deployments rather than a narrow development branch. (GitHub)

Apache’s CVE-2025-53020 is also relevant. Apache’s own vulnerability listing describes an HTTP/2 denial-of-service issue where memory consumption could increase and recommends upgrading to fixed versions. The lesson is not that every Apache HTTP/2 issue is identical. The lesson is that resource lifetime bugs in HTTP/2 request handling have recurred often enough that defenders should treat HTTP/2 modules as high-priority edge components, not passive plumbing. (Apache Lists)

Apache’s CVE-2026-23918 shows a different failure mode. Apache listed it as a double-free and possible remote code execution issue on early HTTP/2 reset, affecting 2.4.66 and fixed in 2.4.67. That vulnerability matters here because it reminds teams that HTTP/2 implementation flaws are not limited to bandwidth exhaustion or memory growth. State-machine and memory-safety bugs can live in the same protocol layer. (Apache HTTP Server)

nginx’s historical HTTP/2 advisories also provide context. nginx has previously listed multiple HTTP/2 denial-of-service vulnerabilities, including CVE-2019-9511, CVE-2019-9513, and CVE-2019-9516. Those older issues are not the same as CVE-2026-49975, but they reinforce the same defensive habit: HTTP/2 parsing, prioritization, flow control, and header handling deserve explicit patch tracking. (Nginx)

The common thread is not that HTTP/2 is unsafe by default. The common thread is that HTTP/2 gives implementations more state to manage. More state creates more boundaries where a limit can apply to the wrong object, the wrong time, or the wrong representation.

Common mistakes during triage

The first mistake is treating HTTP/2 support as the vulnerability. HTTP/2 support is exposure, not proof. A patched nginx, patched Envoy, or correctly fixed Apache deployment can safely support HTTP/2. The task is to identify vulnerable implementations and missing mitigations.

The second mistake is trusting the banner. Apache, nginx, and Envoy are often fronted, repackaged, backported, or hidden. A response header may name the CDN but not the origin. A container tag may be stale. A Linux distribution may backport a fix without changing the upstream version number. You need package changelogs, build hashes, config dumps, and service restarts.

The third mistake is testing with a destructive public PoC as the first step. Because the vulnerability class is denial of service, the proof can be the outage. Even inside a bug bounty program, an out-of-scope DoS test can violate program rules. A safer report contains exposure evidence, version evidence, configuration evidence, vendor references, and a clear explanation of why destructive validation was not performed.

The fourth mistake is lowering only one byte-size limit. The attack path is about encoded size, decoded size, count, and lifetime. A one-line byte limit may reduce some risk while leaving the object-count path open.

The fifth mistake is patching the first visible proxy but ignoring secondary HTTP/2 hops. Modern stacks often have several: CDN edge, cloud load balancer, ingress controller, service mesh gateway, sidecar, gRPC service, and origin server. The vulnerable parser is wherever HTTP/2 is decoded.

The sixth mistake is forgetting to restart. Package updates do not protect a process that is still running the old binary or module. After patching, verify the running process start time and loaded binary.

ps -eo pid,lstart,cmd | egrep 'nginx|httpd|apache2|envoy' | grep -v grep

The seventh mistake is assuming a CDN always absorbs the issue. A CDN may protect the public edge, but origin pulls, bypass hostnames, direct IP access, internal routes, partner VPNs, and misconfigured DNS can still expose an HTTP/2 terminator.

Notes for bug bounty hunters and red teams

A good report for this class does not need to knock the target offline.

For a bug bounty report, include:

• The tested hostname and timestamp.
• Evidence that the endpoint negotiates HTTP/2.
• The apparent HTTP/2 terminator if known.
• Non-invasive version or fingerprint evidence.
• Public vendor references for the affected implementation.
• A clear statement that no destructive DoS payload was sent.
• A safe reproduction plan the program can run in a lab.
• Recommended fix or mitigation.
• Caveats if the endpoint is behind CDN or if the origin implementation is uncertain.

For a red team, the bar is different but still controlled. If the rules of engagement allow availability testing, run it only against agreed infrastructure, with a stop condition, monitoring access, an emergency contact, and a rollback path. The goal should be to prove business impact without damaging unrelated tenants or shared platforms.

A useful red-team finding might say:

The public API gateway negotiates HTTP/2 and runs Envoy in an affected release range.
The gateway has no container memory limit and shares a node with unrelated workloads.
No destructive payload was sent during external testing.
A lab clone using the same image and listener configuration reproduced rapid memory growth under controlled conditions.
Recommended actions are to upgrade Envoy to a patched release, set gateway memory limits, and enforce header-count limits at the edge.

That is stronger than a screenshot of a scanner alert. It tells the engineering team what to fix and tells leadership why the risk matters.

PREGUNTAS FRECUENTES

Is CVE-2026-49975 only an Apache issue?

• CVE-2026-49975 is publicly tied to the Apache-side HTTP/2 cookie header accounting issue.
• The broader HTTP/2 Bomb disclosure included multiple server implementations, but those implementations do not all share the same CVE.
• Envoy tracks its closely related issue as CVE-2026-47774, with its own advisory and patched versions.
• Treat each HTTP/2 terminator separately: Apache, nginx, Envoy, IIS, Pingora, CDN edge, ingress controller, and service mesh gateway may each have different exposure and patch status.

Can I prove exposure without sending an HTTP/2 Bomb payload?

• Yes. You can safely prove that an endpoint negotiates HTTP/2 with curl --http2 o openssl s_client -alpn h2.
• You can collect package versions, module status, config snippets, distro advisory status, and memory-limit evidence.
• You can compare the running version against vendor fixes such as Apache mod_http2 2.0.41, nginx 1.29.8 max_headers, or Envoy’s patched release lines.
• You should avoid destructive payloads unless you own the environment or have explicit written authorization.

Does disabling HTTP/2 fully mitigate the risk?

• Disabling HTTP/2 on the vulnerable listener removes the HTTP/2 parser path for that listener.
• It may break gRPC, some API clients, or performance expectations, so test before changing production.
• It does not fix another HTTP/2 terminator behind the first one.
• It is a temporary control when patching is delayed, not a replacement for a fixed server.

Why did existing header limits not always stop the attack?

• Some limits apply to encoded bytes before HPACK expansion.
• Some limits apply to final decoded size but not the number of internal objects.
• Cookie header splitting is valid in HTTP/2, and incorrect accounting can let fragments avoid field-count limits.
• Flow-control behavior can keep memory alive longer than expected, turning temporary parsing cost into sustained pressure.

Is CVE-2026-49975 remote code execution?

• The public Apache-side issue is best treated as an availability vulnerability, not remote code execution.
• The realistic impact is memory exhaustion, process instability, latency, worker crashes, or service denial.
• Do not describe it as RCE unless a vendor advisory for your exact component says so.
• Related HTTP/2 bugs can have different impact. For example, Apache’s CVE-2026-23918 was listed as a double-free and possible remote code execution issue, but that is a separate vulnerability. (Apache HTTP Server)

How is Envoy’s CVE-2026-47774 related?

• Envoy’s issue belongs to the same HTTP/2 Bomb family but has a separate CVE.
• Envoy’s advisory cites incomplete accounting of cookie header bytes and HPACK decoded-size behavior.
• It also notes that flow-control stalling can extend the lifetime of per-stream allocations.
• Envoy lists patched versions as 1.35.11, 1.36.7, 1.37.3, and 1.38.1. (GitHub)

What should Kubernetes teams check first?

• Check internet-facing ingress controllers and gateway pods.
• Identify Envoy, nginx, Apache, Istio, and other HTTP/2-capable images.
• Verify exact image digests and package changelogs, not just tags.
• Confirm memory limits for edge workloads.
• Look for internal HTTP/2 routes, gRPC services, service mesh sidecars, and bypass paths that do not pass through the patched edge.

What should a responsible bug bounty report include?

• Show that the endpoint supports HTTP/2.
• Provide non-destructive version or configuration evidence.
• Reference the relevant vendor advisory or commit.
• Explain why the issue can cause memory pressure or DoS.
• Avoid sending a destructive payload unless the program explicitly allows DoS testing.
• Include practical remediation steps and caveats about CDN or origin uncertainty.

Closing judgment

CVE-2026-49975 is not a reason to panic about HTTP/2. It is a reason to stop treating HTTP/2 as invisible infrastructure.

The vulnerable surface is usually at the edge, but “edge” now means more than one server. It can mean a CDN origin path, a cloud load balancer, an ingress controller, an Envoy gateway, an Apache virtual host, an nginx reverse proxy, a service mesh hop, or a Windows IIS endpoint. The right response is to map those termination points, patch what has a vendor fix, disable HTTP/2 where the risk is not worth the feature, enforce hard header-count limits, and make sure memory caps prevent one parser from taking down a host.

The most reliable validation is not a public bomb payload. It is a clean evidence chain: HTTP/2 exposure, implementation identity, vulnerable or fixed version, relevant configuration, resource isolation, monitoring signal, and remediation proof. That is the difference between knowing a CVE exists and knowing whether it can hurt your environment.