Fix Summary

The gateway.controlUi.allowInsecureAuth configuration option allows the Control UI to authenticate using only a token over unencrypted HTTP, bypassing both device identity verification and the device pairing requirement. This enables man-in-the-middle attacks where an attacker can intercept the token and gain full administrative access to the gateway.

Issue Linkage

Fixes #20683

Security Snapshot

• CVSS v3.1: 8.3 (High)
• CVSS v4.0: 8.7 (High)

Implementation Details

Files Changed

• src/gateway/server.auth.e2e.test.ts (+24/-4)
• src/gateway/server/ws-connection/message-handler.ts (+6/-2)

Technical Analysis

When gateway.controlUi.allowInsecureAuth: true is set, the allowControlUiBypass flag is set to true inside the WebSocket handshake handler. This flag suppresses two distinct security checks: (1) the HTTPS/localhost enforcement block that normally rejects non-secure Control UI connections, and (2) the device pairing requirement that gates new devices. The result is that any client presenting a valid shared secret (token or password) is granted full operator-level scopes over an unencrypted HTTP connection. No device identity is registered or verified. Tokens in transit are fully plaintext-exposed.

Validation Evidence

• Command: pnpm build && pnpm check && pnpm test
• Status: passed

Risk and Compatibility

non-breaking; no known regression impact

AI-Assisted Disclosure

• AI-assisted: yes
• Model: GPT-5.3-Codex

Greptile Summary

This PR fixes a critical security vulnerability where gateway.controlUi.allowInsecureAuth: true allowed Control UI to bypass both HTTPS/localhost enforcement and device pairing requirements, enabling man-in-the-middle attacks over unencrypted HTTP.

Changes Made

• Modified allowControlUiBypass calculation to exclude allowInsecureControlUi flag, ensuring allowInsecureAuth no longer bypasses secure-context or device-auth checks
• Updated tests to verify Control UI now correctly rejects token-only auth over HTTP and enforces pairing requirements even when allowInsecureAuth is enabled
• Added telemetry to track when insecureAuthConfigured is set during failed handshake attempts

Issues Found

• The security audit message in src/security/audit.ts:352 still describes the old insecure behavior and needs updating to reflect that allowInsecureAuth no longer bypasses security checks

Confidence Score: 4/5

• This PR is safe to merge after updating the security audit message - it fixes a critical vulnerability without introducing new security issues
• The fix correctly addresses the security vulnerability by preventing allowInsecureAuth from bypassing security checks. Tests comprehensively verify the new behavior. One minor issue: the security audit message needs updating to reflect the fixed behavior
• src/security/audit.ts needs the audit message updated to reflect that allowInsecureAuth no longer bypasses security

_{Last reviewed commit: b228890}