# Missing idle timeout resource exhaustion

Check whether held connections, sessions, or callbacks have a bounded lifetime and cleanup on every exit path

_Area: Web business logic and race conditions. Seen in 2 disclosed reports; one confirmed bounty: $250; latest 2026-09-16. Updated 2026-10-25._

## How it works
A resource is allocated when a request or session begins, but nothing bounds how long it may be held. The code assumes the client will finish, disconnect, or that some timeout will fire. When that assumption breaks — a slow client, an early-return path, a callback scheduled outside the timeout window — the resource stays allocated indefinitely. Enough of these and the process runs out of slots or memory.

## Where it shows up
- Server or session setup with no read/idle timeout, or a timeout defaulted to 0 [E2](https://bugbountylibrary.com/r/h1%3A868834.md)
- A timeout that covers only one phase (headers) while the body phase is delegated to app code [E2](https://bugbountylibrary.com/r/h1%3A868834.md)
- Session or handle allocation before request validation, with cleanup only on the happy path [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9pj6-vhgr-3mwh.md)
- Timeout wrappers around a single entry point while engine-scheduled callbacks (GC, microtasks, timers) run outside it [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-r4fx-v8hh-22mv.md)
- Early-return branches that skip the close/release call [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9pj6-vhgr-3mwh.md)

## How to review
Trace every allocation to a guaranteed release on all exit paths, including errors and cancellation. The invariant: every held resource has a bounded lifetime enforced by the runtime, not by client behavior. For each timeout, confirm which phases and callbacks it actually covers; a timeout on one function does not cover work it schedules. For session tables, check that allocation happens after validation and that a Drop guard or equivalent releases on every path [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9pj6-vhgr-3mwh.md).

## Variants seen
- No idle timeout on HTTP body phase after a default change to 0 [E2](https://bugbountylibrary.com/r/h1%3A868834.md)
- Session created before body validation; early returns orphan the handle [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9pj6-vhgr-3mwh.md)
- Timeout bypassed by GC-scheduled cleanup callback busy-looping the event loop [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-r4fx-v8hh-22mv.md)

## Why fixes fail
E2 shows a runtime default change (timeout 0) silently removing protection the body phase relied on; header-only timeouts look sufficient but are not. E1 shows cleanup living only on the happy path, so each new early return reintroduces the leak.

## Impact and severity
Remote denial of service: connection-slot exhaustion [E2](https://bugbountylibrary.com/r/h1%3A868834.md), permanent session-table growth to OOM [E1](https://bugbountylibrary.com/r/ghsa%3AGHSA-9pj6-vhgr-3mwh.md), and indefinite host event-loop freeze [E3](https://bugbountylibrary.com/r/ghsa%3AGHSA-r4fx-v8hh-22mv.md). Severity rises when the trigger is unauthenticated and cheap, and when the leak is permanent rather than reclaimed on disconnect.

## Evidence
- E1: https://bugbountylibrary.com/r/ghsa%3AGHSA-9pj6-vhgr-3mwh.md
- E2: https://bugbountylibrary.com/r/h1%3A868834.md
- E3: https://bugbountylibrary.com/r/ghsa%3AGHSA-r4fx-v8hh-22mv.md