DoS / Resource Exhaustion

Reports cluster around:

• ReDoS - vulnerable regex in input-validation paths (Rails Money type, Fastify, every-language ecosystem)
• HTTP/2 'unknownProtocol' leak (Node CVE-2021-22883)
• CPU/memory exhaustion via large file upload, deeply-nested JSON, ZIP/gzip bomb, parser quadratic blowups
• DNS resolver over-fetching (Node DNS Max Responses CVE-2020-8277)
• Long-string PII fields causing UI-side crashes (Hey.com long-name)
• GraphQL deeply-nested queries
• Cookie-based DoS (oversized cookies on api.tumblr.com causing 4xx)
• Cache-pollution that creates unbounded entries
• Workflow-rule infinite loop (Nextcloud CVE-2020-8293). Most are nuanced (input-shape dependent) and require care to test without actually causing DoS in production.

• Validation/parsing endpoints with regex (Rails ActiveRecord money, email validators)
• JSON / XML / YAML parsers
• GraphQL endpoints without depth-limit middleware
• File upload paths without size/type limits
• DNS lookup wrappers
• Profile / name / display-name fields
• Cache-bound endpoints with user-controlled keys
• Template / workflow engines

• Submit super-long string + classic ReDoS pattern to validation endpoints
• Submit JSON with thousands of duplicate keys
• Submit deeply-nested JSON / XML / YAML
• Submit zip / gzip bomb to upload endpoints
• Submit GraphQL query with deeply-nested fragments
• Spawn many HTTP/2 connections sending unknownProtocol
• Submit oversized cookie for repeated requests
• Trigger expensive endpoint without rate limit
• Submit unbounded recursion in template / workflow rule
• Upload very large or pixel-bomb image

• Regex bomb: "(a+)+$" + 50000 'a' characters
• JSON: {"x":"x","x":"x","x":"x",...} (10000 duplicate keys)
• JSON: {"a":{"a":{"a":{...}}}} (5000 levels)
• ZIP bomb: a 42-byte zip that decompresses to 4.5 PB
• GraphQL: query { user { friends { friends { friends { ... } } } } } (50 depths)
• HTTP/2 unknownProtocol burst (CVE-2021-22883)
• Cookie: oa_consumer_key=AAAA... (1MB)
• Long name field (1MB) - Hey.com case
• PNG with extreme dimensions (pixel flood)

Testing for this class needs to stay strictly on the fingerprint-and-advisory side rather than attack-and-confirm, since actively taking a production target down is never an acceptable testing outcome. A version-fingerprint check against known DoS-related CVEs is the safest starting point. On validation endpoints, submitting a classic ReDoS pattern at low intensity, first at 5x then 10x the baseline input length, and watching for latency growth well short of full denial of service gives a real signal without the risk. On GraphQL endpoints, submitting progressively deeper queries (depth 5, 10, 25) and checking whether the server starts rejecting them reveals a missing depth limit. On upload endpoints, submitting progressively larger files, capped at a safe ceiling, shows whether a size limit is enforced. On cookie handling, submitting progressively larger cookie values shows where the server breaks. A CVE-marker match is high confidence; everything else here should be treated as advisory rather than confirmed, since none of it pushes all the way to an actual denial of service.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Active DoS testing against production is unethical and illegal in many jurisdictions.
• The right posture stays advisory: rely heavily on version-matching against known CVEs, plus controlled sub-DoS probing that never exceeds an ethical ceiling, for example testing ReDoS at a depth of 10 rather than 100.
• All findings here should be treated as informational unless paired with a confirmed CVE match.

Manual Testing Methodology

Here is a systematic approach to identifying DoS / Resource Exhaustion vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For DoS / Resource Exhaustion specifically, submit requests designed to maximize server-side work relative to request size — deeply nested payloads, very large pagination/limit parameters, strings crafted to trigger catastrophic regex backtracking, and a high volume of slow or held-open connections.

Compare the response against your baseline, looking specifically for measurably degraded response time or resource usage (CPU, memory, connection pool exhaustion) triggered by a disproportionately small or cheap request — the finding is the disproportion, not just that the server got slow under obviously heavy load.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For DoS / Resource Exhaustion, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Denial-of-service through resource exhaustion takes a service down, or degrades it badly enough to be unusable, without needing a memory-corruption bug or a logic flaw — just a request pattern the application never bounded. Unbounded pagination, unbounded recursive parsing, unbounded regular expressions, and unbounded concurrent connections are all the same underlying mistake wearing a different costume: the server does an amount of work proportional to something the client controls, with no ceiling.

The business impact is direct and immediate — the service is unavailable to legitimate users for as long as the exhaustion holds, which for a customer-facing application translates straight into lost revenue and SLA violations, and for backend infrastructure can cascade into failures in whatever depends on it.

A specific and underrated variant is algorithmic-complexity DoS: a single small request that happens to trigger worst-case behavior in a parser or regular expression (ReDoS) can consume disproportionate CPU relative to its size, which means rate-limiting by request count alone doesn't fully address it — the fix has to bound the work itself, not just the request rate.

Prevention and Secure Coding

Preventing DoS / Resource Exhaustion takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Explicit limits on everything client-influenced. Cap pagination size, upload size, request body size, recursion depth, and any other parameter whose processing cost scales with a client-supplied value.

Timeout every external and internal call. A request that depends on a slow downstream service should fail fast rather than holding a connection and a thread open indefinitely while it waits.

Audit regular expressions for catastrophic backtracking. A regex with nested quantifiers over user-controlled input can take exponential time on a crafted string (ReDoS) — test parsing-related regexes against adversarial input, not just typical input.

Rate-limit and quota per client, not just globally. A global rate limit alone lets one abusive client still exhaust the budget everyone else needs.

Autoscaling and circuit breakers as the operational backstop. Application-level bounds are the primary control; autoscaling and circuit breakers limit how far a miss still propagates.