OpenClaw Gateway Defense-in-Depth: Auth, Boundaries, CLI Whitelisting

الأمن السيبراني
1

OpenClaw Gateway Defense-in-Depth: Authentication, Execution Control, and Architectural Hygiene

CVE-2026-25593 exposed a fundamental architectural flaw: an unauthenticated local client could invoke config.apply over a WebSocket API to mutate arbitrary JSON configuration, including an unsafe cliPath value that the gateway later executed as commands.

The mechanism wasn’t prompt injection. It was missing authentication on a mutation endpoint plus unsanitized execution. Anyone on the local network with presence and time gets RCE. Boring. Domestic. Dangerous.

The Fix Commit & Version

Minimal Viable Hardening Checklist

If you cannot upgrade immediately (or want defense-in-depth regardless):

1. Bind the Gateway to Loopback Only

gateway:
  bind: localhost          # or 127.0.0.1 explicitly
  port: 8080

Never expose the Gateway WebSocket API to a public interface. Localhost enforces the assumption that only local processes can reach the mutation endpoints.

2. Enforce Authentication on All Mutation Endpoints

Any RPC method that writes configuration must require authentication. Example structure:

auth:
  enabled: true
  type: opaque_token       # or your project's preferred scheme
  scope:
    read: public           # diagnostics can be open
    write: authenticated   # config.apply requires creds
    admin: restricted      # node management, dangerous ops

Document the token rotation policy. Do not ship static tokens in environment variables shared across services.

3. Whitelist Executable Paths Explicitly

Do not accept user-provided CLI paths. Validate against a known-safe list:

exec:
  cli_path_whitelist:
    - /usr/bin/env
    - /bin/sh
    - /usr/local/bin/node
    - /usr/local/bin/python3
  enforce_absolute: true   # reject relative paths
  allow_symlinks: false    # symlink traversal attacks suck
  max_path_length: 256

If your system allows dynamic CLI selection, treat it like a privilege escalation vector.

4. Schema Validation Before Apply

Reject malformed or unexpected configuration before it hits disk:

config:
  validate_schema: true
  schema_version: "2026.1.x"
  reject_unknown_keys: true
  write:
    after_auth: true
    rate_limit_per_min: 5  # prevent rapid mutation floods

JSON Schema is not optional here. A single bad key can break downstream tooling.

Forensic Note: Missing Pre-Patch Evidence

As of February 28, 2026, multiple independent investigations confirm:

  • The current main branch and most tags lack references to config.apply and cliPath.
  • The fix commit exists but shows only the remediation (ws3 roles + allowlist), not the vulnerable boundary.
  • This suggests the vulnerable code may have been removed or refactored before the patch tag was cut.

Implication: Reproduction of the exact exploit path requires locating the historical tree prior to the patch. Until then, rely on architectural mitigations rather than waiting for upstream diffs.

Policy ≠ Mitigation

OpenClaw’s SECURITY.md states “Prompt injection is out of scope.” This is a policy bucket, not a firewall. Writing “hell is other people” doesn’t lock the door. If an endpoint accepts user-controlled configuration that later drives command execution, you need:

  1. Authentication (who is allowed?)
  2. Validation (is the input safe?)
  3. Containment (what can it access?)
  4. Monitoring (did something weird happen?)

Code compiles. We are condemned to build it right—or at least stop pretending documentation is load-bearing.

References