Why does a small HTTP/2 request sometimes create a large outage risk?

Because compression and flow control can decouple wire size from in-memory cost. If decoded headers are not governed as carefully as encoded bytes, an attacker can multiply resource use with repeated references and stalled responses. The outage risk grows when the listener is public, because the attacker needs no credentials and can keep the connection alive cheaply.

Why does a small HTTP/2 request turn into a large resource spike?

HTTP/2 lets a tiny request fan out into much larger server work because the visible wire payload is not the same as the hidden processing cost. Header compression, multiplexing, and stream state all create opportunities for disproportionate CPU, memory, and connection pressure when the server expands, queues, or waits on data more expensively than the client had to send it.

The practical lesson is that request size alone is a poor proxy for impact. A server can be stressed by repeated references, decompression work, stalled streams, or bookkeeping overhead long before the raw byte count looks large, which is why resource governance matters as much as transport efficiency.

Which HTTP/2 behaviours make the risk disproportionate?

Two design features drive most of the mismatch. First, header compression means the encoded request can be small while the decoded header set, table lookups, and repeated references consume much more server-side work. Second, flow control and multiplexing can let a client hold connections open cheaply while the server keeps state for multiple streams, buffers, and scheduling decisions.

This is why the same pattern can look harmless in packet capture but still create a service-level problem. The attacker does not need a large payload if the protocol lets them force the server to spend more effort than they spend to send the request.

When the listener is public, the exposure is worse because no authentication boundary blocks the first request. That makes transport-layer efficiency features part of the attack surface, not just performance tuning details.

What distinguishes a nuisance from an outage condition?

The difference is usually scale, concurrency, and how much work is triggered per connection. If the server can keep accepting new streams, allocate memory for them, and defer expensive response handling, a single client may create a backlog that looks modest at the edge but becomes material inside the application, proxy, or reverse proxy tier.

Operationally, the outage threshold is crossed when the server starts spending resources on protocol housekeeping faster than it can complete useful work. At that point, latency increases, worker pools saturate, and unrelated traffic can slow down or fail even if the original request volume still appears low.

That is why this class of problem is often about asymmetric cost, not bandwidth saturation. The most important question is not how many bytes arrived, but how much memory, CPU, and connection capacity each request consumes after decoding and scheduling.

Risk and Threat Considerations

HTTP/2 resource-exhaustion issues matter because the protocol can be abused to create a denial-of-service condition without needing a large traffic volume or expensive attacker infrastructure. Public-facing endpoints are especially exposed because the attacker can probe limits, hold connections open, and force the server into expensive internal work before any higher-level control can intervene.

Failure mechanism: The protocol permits a small encoded request to expand into many decoded headers, queued streams, or stalled responses, so the server burns disproportionate CPU, memory, and concurrency capacity while processing seemingly minor input.

Impact: The likely result is elevated latency, exhausted worker pools, connection starvation, and partial or full outage of the affected service or shared front-end tier, even when incoming byte volume remains low.

Practitioner Guidance

What to verify: Confirm that your edge, proxy, and application tiers enforce hard limits on header size, concurrent streams, connection duration, and per-connection memory growth. The control must be tested where decoding and stream scheduling actually occur, not only where packets first arrive.

What to prioritise: Watch for resource asymmetry indicators, especially rising memory per connection, unusually long-lived HTTP/2 sessions, and a jump in active streams without a matching increase in legitimate request volume. Those signals matter more than raw throughput when assessing this failure mode.

Decision rule: If a public listener can amplify a tiny request into expensive server-side work, treat protocol hardening and rate shaping as availability controls, not just performance settings. If you cannot bound the cost of one connection, you cannot assume the service is safe under low-volume abuse.

Practitioner takeaway: The real defence is to cap post-decode work per connection, because HTTP/2 outage risk comes from hidden server cost, not visible request size.

Related resources from NHI Mgmt Group

• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why can a single SaaS app create such a large blast radius?
• Why do connection reuse and proxy translation create extra risk for HTTP request smuggling?