HTTP Stalling Attack

How HTTP Stalling Attacks Work

An HTTP stalling attack is a slow-application-layer denial of service pattern. The attacker opens connections and then withholds completion, so the server keeps sockets, worker threads, request parsers, or timeout state reserved while little useful work is done. The damage comes from resource pinning rather than traffic volume alone.

This matters because modern web stacks often have several chokepoints, including reverse proxies, load balancers, application servers, and thread pools. A small number of deliberately incomplete requests can reduce concurrency for legitimate users, especially when timeout handling is generous or uneven across layers.

Why It Is Effective Against Web Services

HTTP stalling is effective when the service allocates scarce per-connection or per-request state before the request is complete. If a server waits on headers, body bytes, or downstream processing, the attacker can hold that state open cheaply and repeatedly. The attack is often more efficient than flooding because it tries to exhaust concurrency, not bandwidth.

Services are especially exposed when they rely on synchronous workers, small connection pools, or front-end components that do not aggressively bound partial-request lifetimes. Even where autoscaling exists, a stalling pattern can still create a backlog faster than the platform can add capacity.

For a broader view of this class of attack and the controls that blunt it, see the Denial of Service at Application Layer Guide.

Detection and Exposure Checks

Exposure is usually visible in the architecture before it is visible in logs. Look for public HTTP endpoints, reverse proxies that buffer incompletely, worker pools that stay occupied by idle sockets, and timeout settings that differ between tiers. These are the conditions that let a slow request consume disproportionate capacity.

Detection depends on correlating connection lifetime, request completion rate, and worker saturation. A spike in open-but-incomplete requests, rising time-in-state, or a growing queue with low throughput is a stronger signal than raw request count alone. Network traces, proxy logs, and application metrics are most useful when viewed together.

The practical control problem is not just blocking bad traffic, but identifying which layer is actually holding state. A front-end proxy may appear healthy while the application tier is quietly pinned.

Remediation and Hardening

Mitigation usually comes from tightening the amount of time and memory any incomplete request is allowed to consume. Shorter timeouts, per-connection and per-IP limits, request buffering rules, and worker isolation all reduce the attacker’s ability to pin capacity. Where possible, put the most restrictive controls closest to the internet-facing edge.

Compensating controls matter when a patch or redesign is not immediately possible. Rate limiting, queue limits, graceful degradation, and circuit-breaker behaviour can preserve service for legitimate traffic even under partial-request abuse. Testing should confirm that controls behave consistently across proxies, caches, and application servers rather than only at one tier.

Operationally, the best hardening is to make incomplete requests cheap to reject and expensive to sustain. That shifts the burden back to the attacker instead of your thread pool.

Post-Incident Review and Service Impact

After an event, review whether the attack merely caused transient slowdown or whether it left behind wider service degradation. Prolonged stalls can mask other availability problems, trigger retries, and amplify load on dependent systems. If the service uses shared pools or shared front doors, the blast radius can extend beyond the targeted application.

Post-incident analysis should also verify whether monitoring saw the pattern early enough to distinguish a low-and-slow exhaustion attack from ordinary latency. Good review material includes timeout histograms, connection-state timelines, proxy saturation, and any failover or autoscaling actions that were triggered too late or not at all.

Related resources from NHI Mgmt Group

• Why does exposing high-privilege MCP tools over HTTP create a much larger attack surface than stdio-based transports?
• Is HTTP/2 Rapid Reset Attack being exploited in the wild?
• How do you patch or mitigate an HTTP/2 rapid reset attack?
• What does HTTP Desync Attack look like in a real intrusion?