Hermes Agent < 0.16.0 - DNS Rebinding Bypass via WebSocket Endpoints

An attacker can exploit DNS rebinding to make a victim's browser initiate a WebSocket upgrade to a loopback-bound Hermes dashboard with an attacker-controlled Host header (e.g. `Host: evil.example`) and Origin header (e.g. `Origin: http://evil.example`). Because FastAPI HTTP middleware does not run for WebSocket upgrades, the vulnerable endpoints accept the connection as long as a valid dashboard session token is present in the WebSocket query string. Once the WebSocket is established, the attacker can inject malicious commands via `/api/pty` or read terminal output, bypassing the Host/Origin boundary that protects HTTP routes [ref_id=1][ref_id=2].

The vulnerability resides in `hermes_cli/web_server.py` where the four WebSocket endpoints (`/api/pty`, `/api/ws`, `/api/pub`, `/api/events`) did not validate the Host or Origin headers before accepting the upgrade. FastAPI HTTP middleware (which already enforced Host validation for normal HTTP requests) does not execute for WebSocket upgrade routes, leaving a transport-level gap.

The patch adds two new functions in `hermes_cli/web_server.py`: `_ws_host_origin_is_allowed()` and `_ws_request_is_allowed()`. The former reuses the existing `_is_accepted_host()` helper to validate the WebSocket Host header and, when present, checks that the Origin header also targets the bound dashboard host. The latter combines this Host/Origin check with the existing client-IP guard. All four WebSocket endpoints (`/api/pty`, `/api/ws`, `/api/pub`, `/api/events`) now call this shared guard before `accept()`, closing the transport gap. Invalid Host/Origin combinations cause the WebSocket to close with code 4403, while valid loopback usage and missing-Origin (non-browser) clients continue to work [ref_id=1][ref_id=2].