Hermes Agent - Pre-Authentication Memory Exhaustion

In Hermes Agent the dashboard's public authentication routes (/auth/native/token, /auth/native/refresh, and /auth/password-login) read and parse the entire JSON request body before any authentication check, with no application-level size limit.

The gated_auth_middleware in hermes_cli/dashboard_auth/middleware.py lets these paths through via _GATE_PUBLIC_PREFIXES before checking for a session. The handlers in routes.py rely on Pydantic models whose string fields have no size bound, and the pinned web stack (FastAPI 0.133.1, Starlette 1.3.1, Uvicorn 0.41.0) buffers the full body before the handler runs. Uvicorn's configuration in start_server (hermes_cli/web_server.py) caps WebSocket message size but sets no HTTP body limit.

As a result, an unauthenticated client can send oversized payloads that are fully loaded into memory before being rejected. Testing confirmed that a ~1 MB body to /auth/native/refresh returned 401 instead of 413, and that chunked uploads of 32 MiB and 128 MiB, sent without Content-Length, still reached /auth/password-login's application-level rejection (404). Keeping eight concurrent 32 MiB uploads open for fifteen seconds raised the dashboard process's memory from 721 MiB to 1.08 GiB, while /api/status continued to report overall=ok.

Although every request is ultimately rejected, an anonymous attacker can drive substantial memory consumption by holding several large uploads in progress, which creates a denial-of-service risk.