Hermes WebUI < 0.51.468 - Resource Exhaustion via Unauthenticated OAuth Flow Endpoint

An unauthenticated attacker sends repeated or concurrent HTTP POST requests to `/api/onboarding/oauth/start`. Each request triggers a device-code request to the upstream OAuth provider and inserts a new pending flow into the in-memory `_OAUTH_FLOWS` dictionary, while also spawning a daemon polling thread. By flooding the endpoint, the attacker causes unbounded accumulation of flow state and threads, exhausting server memory and thread resources. The advisory notes this can also trigger repeated outbound device-code requests to upstream OAuth providers.

The vulnerability resides in `api/oauth.py`, specifically in the `start_onboarding_oauth_flow` function and the `_start_anthropic_flow` helper. The unauthenticated `POST /api/onboarding/oauth/start` endpoint lacked single-flight semantics, allowing repeated or concurrent requests to create unbounded in-memory flow state entries and daemon polling threads [ref_id=1][ref_id=2].

The patch introduces per-(provider, hermes_home) locks (`_oauth_start_lock`) and a `_pending_oauth_flow_for_locked` helper that atomically checks for an existing live flow under `_OAUTH_FLOWS_LOCK`. For the Codex path, the entire check→device-code request→insert→worker-spawn sequence is serialized by the per-key lock, with a double-check after the network call to avoid duplicate work. For the Anthropic path, an atomic check-and-insert under `_OAUTH_FLOWS_LOCK` is sufficient because no I/O occurs between check and insert. This ensures that concurrent or repeated requests reuse the existing flow and worker instead of creating new ones, preventing unbounded accumulation of in-memory state and daemon threads [ref_id=1][ref_id=2].