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.

Executive Risk Snapshot

• CVSS v3.1: 8.3 (High)
• CVSS v4.0: 8.7 (High)
• Primary risk: 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.

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.

Affected Code

File: openclaw/src/gateway/server/ws-connection/message-handler.ts:341–345

const allowInsecureControlUi =
  isControlUi && configSnapshot.gateway?.controlUi?.allowInsecureAuth === true;
const disableControlUiDeviceAuth =
  isControlUi && configSnapshot.gateway?.controlUi?.dangerouslyDisableDeviceAuth === true;
const allowControlUiBypass = allowInsecureControlUi || disableControlUiDeviceAuth;

File: openclaw/src/gateway/server/ws-connection/message-handler.ts:429–453

if (!device) {
  if (scopes.length > 0 && !allowControlUiBypass) {
    scopes = [];
    connectParams.scopes = scopes;
  }
  const canSkipDevice = sharedAuthOk;

  if (isControlUi && !allowControlUiBypass) {
    const errorMessage = "control ui requires HTTPS or localhost (secure context)";
    markHandshakeFailure("control-ui-insecure-auth");
    sendHandshakeErrorResponse(ErrorCodes.INVALID_REQUEST, errorMessage);
    close(1008, errorMessage);
    return;
  }

File: openclaw/src/gateway/server/ws-connection/message-handler.ts:652

const skipPairing = allowControlUiBypass && sharedAuthOk;
if (device && devicePublicKey && !skipPairing) {

Steps to Reproduce

1. Configure OpenClaw with gateway.controlUi.allowInsecureAuth: true
2. Connect to the gateway over HTTP (not HTTPS) from a remote client
3. Authenticate using only the gateway token (no device identity required)
4. Observe that full administrative access is granted without device verification or device pairing
5. An attacker in MITM position can intercept the token and reuse it

Recommended Fix

1. Remove or deprecate the allowInsecureAuth option entirely
2. Require HTTPS or localhost for Control UI connections
3. If HTTP must be supported, require additional authentication factors
4. Add prominent security warnings in documentation and configuration

Detailed Risk Analysis

CVSS Assessment

Attack Surface

The vulnerability is reachable whenever gateway.controlUi.allowInsecureAuth: true is set in the gateway configuration and the gateway is accessible over HTTP from a non-loopback network. Any network-adjacent attacker with passive MITM capability can capture the token. No attacker privileges are required beyond network access.

Exploit Conditions

The configuration option must be enabled by an administrator. Once enabled, exploitation requires only network access and the ability to observe HTTP traffic (passive MITM). A legitimate user must initiate a Control UI connection for the token to appear on the wire (UI:R).

Impact Assessment

The intercepted token grants full operator-level administrative access to the gateway, including all operator.admin, operator.approvals, and operator.pairing scopes. Confidentiality and integrity impacts are High; availability impact is Low.

References

• CWE: CWE-319: Cleartext Transmission of Sensitive Information
• CWE: CWE-287: Improper Authentication

Exploitability Proof

When allowInsecureAuth: true is configured:

1. allowInsecureControlUi = true (line 341–342)
2. allowControlUiBypass = true (line 345)
3. The HTTPS enforcement block if (isControlUi && !allowControlUiBypass) at line 436 is skipped
4. canSkipDevice = sharedAuthOk — token/password alone satisfies the check
5. Device identity verification is skipped; no pairing is required (line 652)
6. Full admin connection is established over unencrypted HTTP with token-only auth

The token is transmitted in plaintext and can be intercepted passively.

Mitigation Checks Performed

• The security audit in openclaw/src/security/audit.ts:345–365 flags this as severity: "critical" with checkId: "gateway.control_ui.insecure_auth" and remediation guidance
• However, the audit is a CLI advisory tool (openclaw security audit) — it does not block the configuration from being applied
• The documentation at openclaw/docs/gateway/security/index.md:130–135 warns about this downgrade but does not prevent it
• No rate limiting or additional protections are applied to connections that use the bypass path
• Device pairing bypass at line 652 is also unmitigated when allowControlUiBypass is active

Reproduction Evidence

From the code flow:

1. User sets gateway.controlUi.allowInsecureAuth: true in config
2. Control UI connects over HTTP with just token auth
3. allowInsecureControlUi = true (line 341)
4. allowControlUiBypass = true (line 345)
5. Device requirement and HTTPS enforcement are bypassed (lines 429–453)
6. Device pairing is also skipped (line 652)
7. Full admin access granted without device identity or pairing

Why This Is Exploitable (Not Hardening)

This is a real vulnerability:

• The option exists, is documented, and is operationally reachable
• It completely bypasses both the device identity security model and device pairing
• Tokens sent over HTTP are vulnerable to passive interception
• An intercepted token grants full administrative access
• The security audit flags it as critical but cannot prevent its use
• The dangerouslyDisableDeviceAuth sibling option produces the same bypass via the same allowControlUiBypass flag