Hermes CLI Dashboard WebSocket Host/Origin Validation Bypass

Vulnerability Overview This vulnerability involves issues with Host and Origin validation in the Dashboard WebSocket routes. Specifically, the Dashboard's WebSocket routes did not correctly validate the Host and Origin headers, allowing attackers to bypass existing HTTP middleware checks by crafting malicious requests, thereby gaining access to the Dashboard. Impact Scope Affected Endpoints: , , , and . Attack Scenario: Attackers can bypass the Dashboard's Host header defenses via WebSocket transport by leveraging valid Dashboard session tokens through browser proxy chains, token leakage, or intentionally exposed deployment environments. Potential Risk: Attackers can access sensitive Dashboard information or execute unauthorized operations. Remediation 1. Add Shared WebSocket Host/Origin Pre-checks: Implement shared Host/Origin pre-check logic before WebSocket routes accept requests. 2. Validate Host and Origin Headers: Ensure that the Host and Origin headers in WebSocket upgrade requests match the host bound to the Dashboard. 3. Reject Invalid Combinations: Return a 403 status code for invalid Host/Origin combinations. 4. Preserve Existing Behavior: Non-WebSocket HTTP behavior remains unchanged. POC Code Below is the code comparison before and after the fix: Before Fix After Fix Security Reproduction Steps 1. Simulate the Dashboard binding to by setting . 2. Enable the embedded Dashboard chat to test under the relevant WebSocket routes. 3. Open with a valid session token and attacker-controlled headers: - - 4. Confirm that the WebSocket closes and returns a 403 status. 5. Repeat the above steps with a valid Host and a malicious Origin, confirming that the WebSocket closes and returns a 403. 6. Repeat the above steps with a valid Host and Origin, confirming that the WebSocket is accepted. Expected Vulnerable Behavior In the vulnerable code, HTTP routes reject bad Host headers, but WebSocket routes still accept the same attacker-controlled Host/Origin patterns when a valid Dashboard session token is provided. Post-Fix Behavior After the fix, malicious WebSocket Host/Origin combinations are rejected before acceptance, while valid local loopback usage remains functional. File Changes : Added and applied WebSocket Host/Origin guard logic. : Added WebSocket regression tests covering the existing HTTP Host header tests. Maintainer Impact Local loopback Dashboard usage remains unchanged for valid local loopback Host/Origin requests. Missing WebSocket Origin headers are still permitted for non-browser clients, such as internal Dashboard sidebar publishers. Existing public interface binding behavior is preserved because already handles as explicit operators, where Host-layer protection cannot provide the same boundary. The patch is intentionally narrow and does not redesign Dashboard session token handling. Remediation Rationale The safest boundary is enforcing Dashboard Host validation at every transport access point. Reusing maintains consistency between HTTP and WebSocket behavior while checking the Origin. Blocking the second browser access signal during WebSocket handshakes prevents deviations from policy.

Goal Reached Thanks to every supporter — we hit 100%!

Hermes CLI Dashboard WebSocket Host/Origin Validation Bypass

More from this source