GHSA-r7vr-gr74-94p8: Improper Authorization and Privilege Escalation in OpenClaw

OpenClaw relies on a dual-tier authorization model to manage interaction. The system implements a general allowlist for standard user interaction and a secondary ownership model for administrative tasks. The core command dispatching logic verifies general authorization but fails to consistently enforce ownership validation across all exposed endpoints.

This structural omission maps to CWE-285 (Improper Authorization) and CWE-863 (Incorrect Authorization). The vulnerability specifically affects the /config and /debug command handlers. The system exposes these interfaces to any user present on the standard allowlist, operating under the assumption that the primary dispatcher has handled all necessary access control requirements.

Successful exploitation allows a standard user to access surfaces intended exclusively for the bot owner. The vulnerability resides in the core routing engine and affects all OpenClaw versions prior to v2026.3.12.

The vulnerability originates in the routing and execution logic for administrative commands. The OpenClaw dispatcher relies on a central gatekeeper function named rejectUnauthorizedCommand. This primary function validates whether the sender is permitted to interact with the bot in any capacity. It does not differentiate between standard users and the administrative owner.

Handlers for sensitive commands such as /config and /debug processed execution parameters based on an implicit trust model. Because the dispatcher routed the command to the handler, the handler assumed the user possessed the requisite permissions. The handlers lacked a secondary verification step to assess the granular privilege level of the requesting entity.

This architectural design flaw violates the principle of defense in depth. The system trusted the binary outcome of the primary authorization check without verifying the specific permissions required for the action being requested. The failure to evaluate the senderIsOwner state at the function level enabled the privilege escalation path.

Prior to version v2026.3.12, the /config and /debug handlers lacked explicit ownership checks. The execution path evaluated the generic rejectUnauthorizedCommand output and proceeded directly to processing sensitive inputs. The HandleCommandsParams object passed to the handler contained a command.senderIsOwner boolean flag, but the vulnerable code ignored this property entirely.

The patch addresses this structural deficiency by introducing a specific gatekeeper function named rejectNonOwnerCommand in src/auto-reply/reply/command-gates.ts. This function explicitly evaluates the senderIsOwner boolean property attached to the incoming command object. It returns early if the sender is the owner, effectively functioning as a pass-through.

// src/auto-reply/reply/command-gates.ts
export function rejectNonOwnerCommand(
  params: HandleCommandsParams,
  commandLabel: string,
): CommandHandlerResult | null {
  if (params.command.senderIsOwner) {
    return null;
  }
  logVerbose(
    `Ignoring ${commandLabel} from non-owner sender: ${redactIdentifier(params.command.senderId)}`,
  );
  return { shouldContinue: false };
}

The function constructs an audit log entry using logVerbose and redactIdentifier when a non-owner attempts to access the command. This provides necessary visibility into privilege escalation attempts. It returns a CommandHandlerResult object with shouldContinue set to false, instructing the dispatcher to halt execution.

The fix implements this helper directly within the sensitive handlers. The updated logic in src/auto-reply/reply/commands-config.ts conditionally applies this check, allowing internal read-only operations while blocking unauthorized external modifications or disclosures.

// src/auto-reply/reply/commands-config.ts
const allowInternalReadOnlyShow =
    configCommand.action === "show" && isInternalMessageChannel(params.command.channel);
const nonOwner = allowInternalReadOnlyShow ? null : rejectNonOwnerCommand(params, "/config");
if (nonOwner) {
    return nonOwner;
}

The allowInternalReadOnlyShow constant demonstrates a necessary exception for system-internal components that require configuration access. The patch balances security with operational requirements by leveraging the isInternalMessageChannel utility.

Exploitation requires the attacker to possess an account that is already authorized to interact with the OpenClaw bot. An external, completely unauthenticated attacker cannot trigger this vulnerability, as they are blocked by the initial rejectUnauthorizedCommand check during the primary dispatch phase.

The attacker issues a direct message or channel command containing the /config show or /debug payload. The dispatcher processes the request, validates the user against the general allowlist, and routes the command directly to the administrative handler.

Upon execution, the bot processes the handler logic and returns the requested data or alters its runtime state according to the attacker input. The lack of secondary validation ensures the command completes exactly as it would for the legitimate bot owner.

The primary consequence of this vulnerability is significant information disclosure. The /config show command outputs the bot operational configuration. This configuration data typically includes active API keys, database credentials, and internal system paths.

Beyond data exposure, an attacker leverages the /debug command to induce service disruption. This manipulation includes altering runtime state variables, modifying bot behavior, or redirecting system outputs to attacker-controlled channels.

If write permissions are enabled for the channel, the attacker uses /config set to implement persistent unauthorized modifications. This elevates the standard user to full administrative control over the bot functional parameters, yielding a CVSS v3.1 score of 8.8 (High severity).

The vulnerability is resolved in OpenClaw version v2026.3.12. Administrators must upgrade their instances to this version or later to enforce the new rejectNonOwnerCommand validation logic across all administrative handlers.

Following the upgrade, administrators verify the fix by attempting to execute an administrative command from a non-owner authorized account. The system blocks the execution and records an 'Ignoring from non-owner sender' event in the application logs.

Security teams analyze historical logs for anomalous access to the /config or /debug endpoints by non-owner users prior to the patch deployment. Evidence of such access indicates potential compromise of configuration secrets, requiring immediate credential rotation and an audit of backend systems.