Severity Assessment

CVSS Assessment

Threat Model Alignment

Classification: hardening

No documented trust boundary is bypassed in the verified code path: SECURITY.md says authenticated Gateway callers are treated as trusted operators, and the missing default limiter does not authenticate an attacker by itself. docs/gateway/security/index.md already classifies the same condition as the gateway.auth_no_rate_limit audit warning, so this is a defense-in-depth gap on the shared-secret auth boundary rather than a direct security-specific auth bypass. It is not covered by the Out of Scope list because the finding does not rely on prompt injection, hostile multi-tenant assumptions, or attacker control of trusted local state; it concerns a first-party exposed auth surface that omits online-guess throttling unless operators opt in.

Impact

When gateway.bind is non-loopback and shared-secret auth is in use, failed token/password attempts are throttled only if the operator explicitly configures gateway.auth.rateLimit. Without that config key, HTTP auth paths and non-browser WebSocket handshakes stay on unlimited 401/unauthorized responses instead of escalating to temporary 429 lockouts, so exposed deployments rely entirely on secret entropy rather than per-IP failed-auth throttling; on deployments using weak passwords or manually weakened tokens, a successful guess yields the same shared-secret operator access the gateway docs assign to token/password auth.

Affected Component

File: src/gateway/server.impl.ts:208-218

function createGatewayAuthRateLimiters(rateLimitConfig: AuthRateLimitConfig | undefined): {
  rateLimiter?: AuthRateLimiter;
  browserRateLimiter: AuthRateLimiter;
} {
  const rateLimiter = rateLimitConfig ? createAuthRateLimiter(rateLimitConfig) : undefined;
  const browserRateLimiter = createAuthRateLimiter({
    ...rateLimitConfig,
    exemptLoopback: false,
  });
  return { rateLimiter, browserRateLimiter };
}

File: src/gateway/auth.ts:553-562,595-606

if (limiter) {
  const rlCheck: RateLimitCheckResult = limiter.check(ip, rateLimitScope);
  if (!rlCheck.allowed) {
    return { ok: false, reason: "rate_limited", rateLimited: true, retryAfterMs: rlCheck.retryAfterMs };
  }
}

if (!safeEqualSecret(password, auth.password)) {
  limiter?.recordFailure(ip, rateLimitScope);
  return { ok: false, reason: "password_mismatch" };
}

The optional rateLimiter is forwarded unchanged into both HTTP and WebSocket auth wiring at src/gateway/server.impl.ts:666-669,1343-1354. Browser-origin WebSocket handshakes switch to the separate always-on limiter in src/gateway/server/ws-connection/handshake-auth-helpers.ts:46-60; direct HTTP requests and non-browser WebSocket clients keep using the optional rateLimiter path instead.

Technical Reproduction

1. Configure an exposed gateway with shared-secret auth and no auth limiter, for example gateway.bind: "lan" plus gateway.auth.mode: "password" or a manually configured gateway.auth.token, while leaving gateway.auth.rateLimit unset. The configuration reference documents gateway.auth.rateLimit as optional at docs/gateway/configuration-reference.md:2790-2793.
2. Send repeated wrong shared-secret attempts from the same remote IP to any gateway HTTP auth surface (/v1/chat/completions, /v1/responses, /tools/invoke) or to the WebSocket connect handshake without an Origin header. For WebSocket attempts, reconnect after each short burst because UnauthorizedFloodGuard is per connection.
3. In this configuration, createGatewayAuthRateLimiters() returns rateLimiter: undefined, so the HTTP handlers and WebSocket handshake path call authorizeGatewayConnect() without a limiter. src/gateway/auth.ts:553-562 therefore never sets reason: "rate_limited", and src/gateway/http-common.ts:47-65 / src/gateway/server-http.ts:239-265 can emit only 401 unauthorized failures for wrong secrets on the main auth surface.
4. Compare that with the explicit-config path in src/gateway/openai-http.test.ts:700-741: once gateway.auth.rateLimit is configured, the second bad request returns 429 with Retry-After. Without that config, the main shared-secret auth surface never transitions from repeated failures into lockout.

Demonstrated Impact

browserRateLimiter is always instantiated, but it is selected only for handshakes that present an Origin header (src/gateway/server/ws-connection/handshake-auth-helpers.ts:46-60). Direct API clients, CLI clients, and attacker-controlled non-browser WebSocket connections use the optional rateLimiter instead. UnauthorizedFloodGuard in src/gateway/server/ws-connection/unauthorized-flood-guard.ts:18-57 only counts unauthorized frames on one live socket, and message-handler.ts:1357-1372 closes that socket after repeated failures; reconnecting starts a fresh counter. createPreauthConnectionBudget() in src/gateway/server/preauth-connection-budget.ts:1-58 only caps concurrent unauthenticated sockets per IP and does not slow repeated credential guesses over time.

The remaining protections are advisory rather than enforcing. src/security/audit.ts:657-667 emits gateway.auth_no_rate_limit as a warn finding when non-loopback auth has no limiter, and the docs describe gateway.auth.rateLimit as optional (docs/gateway/configuration-reference.md:2790-2793). Startup also auto-generates a 48-hex-character token when token mode has no configured secret (src/gateway/startup-auth.ts:252-257), and src/security/audit.ts:587-595 warns on tokens shorter than 24 characters. Those mitigations raise attack complexity for default token deployments, which is why this finding is hardening rather than a direct auth bypass. The concrete gap is that password-mode deployments and manually weakened-token deployments still accept unlimited online guesses on exposed gateway auth surfaces until operators opt into throttling.

Environment

Verified against OpenClaw release v2026.4.2 (45546b946068fe57a0248eb81bcb3be113f3919d, published 2026-04-02T18:30:45Z) by tracing src/gateway/server.impl.ts, src/gateway/auth.ts, the gateway HTTP/WS auth handlers, and the security audit/docs guidance in this workspace. Affected deployments are gateways reachable over non-loopback interfaces (lan, tailnet, or custom) using shared-secret token or password auth with gateway.auth.rateLimit unset.

Remediation Advice

Make failed-auth throttling the default for non-loopback shared-secret auth rather than an opt-in setting. Reuse the existing createAuthRateLimiter defaults for token/password gateway auth, keep explicit gateway.auth.rateLimit configuration for threshold tuning instead of basic enablement, and align runtime behavior with the existing audit guidance so exposed deployments cannot run indefinitely with unlimited online guesses.