GHSA-39MP-545Q-W789: Improper Authorization in OpenClaw /send Command

OpenClaw is an open-source personal AI assistant ecosystem that supports multi-user interaction and shared sessions. The platform implements a command gateway that parses and executes administrative instructions, such as /restart, /config, and /send. The /send command specifically dictates how messages are delivered within a given session, accepting parameters like on, off, and inherit to control the gateway's output behavior.

The vulnerability exists within the authorization logic of the /send command handler. While OpenClaw maintains a distinct privilege boundary between a session "owner" and a "command-authorized" user, the /send command handler fails to enforce the stricter owner requirement. It incorrectly categorizes session delivery management as a standard operational command rather than an administrative privilege.

Consequently, any user granted generic command access within a shared session can invoke the /send command. This represents a clear instance of CWE-285 (Improper Authorization), where the software incorrectly performs an authorization check when an actor attempts to access a protected resource. The impact is restricted to the modified session, allowing localized tampering without affecting global platform integrity.

This architectural oversight breaks the intended access control model. Session owners expect their delivery policies to remain immutable by standard participants. The vulnerability undermines this guarantee, exposing the session state to unauthorized modification by lower-privileged users.

The root cause of GHSA-39MP-545Q-W789 stems from a missing context-specific validation check in the command dispatch pipeline. OpenClaw relies on a dual-tier authorization model defined in config.json via the commands.allowFrom and ownerAllowFrom arrays. The former permits general interaction with the agent, while the latter grants full administrative control over the session configuration.

When a command is received, the gateway router parses the input and maps it to a specific command handler. Administrative commands invoke an isOwner() middleware function that cross-references the sender's identifier against the ownerAllowFrom list. However, the /send command was implemented without this middleware, relying solely on the base isAuthorized() function that checks the broader commands.allowFrom list.

The /send command directly mutates the deliveryPolicy property on the active session context object. Because the handler executes the state mutation immediately after the inadequate isAuthorized() check, the gateway accepts the state change as legitimate. The updated deliveryPolicy is then committed to the in-memory session store.

The absence of the isOwner() verification constitutes CWE-863 (Incorrect Authorization). The control mechanism fails to align the sensitivity of the action—modifying persistent session delivery routing—with the privilege level required to execute it. The system correctly identifies the user but applies the wrong authorization policy to the requested action.

The vulnerability resides in the command routing configuration, likely located within packages/gateway-chat/src/commands/send.ts or the central command registry. In the vulnerable implementation, the command registration explicitly omits the ownerOnly flag.

// Vulnerable Implementation
export const sendCommand: Command = {
  name: 'send',
  description: 'Manage message delivery policy',
  // Missing ownerOnly: true enforcement
  execute: async (context, args) => {
    const policy = args[0];
    if (['on', 'off', 'inherit'].includes(policy)) {
      context.session.deliveryPolicy = policy;
      await context.session.save();
      return `Delivery policy updated to ${policy}`;
    }
    return 'Invalid policy';
  }
};

The patch rectifies this logic flaw by introducing the required privilege enforcement mechanism. By setting the appropriate metadata or invoking the ownership middleware directly, the handler ensures the command is rejected if the sender lacks owner privileges.

// Patched Implementation
export const sendCommand: Command = {
  name: 'send',
  description: 'Manage message delivery policy',
  ownerOnly: true, // Patch enforces ownership verification
  execute: async (context, args) => {
    const policy = args[0];
    if (['on', 'off', 'inherit'].includes(policy)) {
      context.session.deliveryPolicy = policy;
      await context.session.save();
      return `Delivery policy updated to ${policy}`;
    }
    return 'Invalid policy';
  }
};

The fix is complete and correctly mitigates the authorization bypass for the /send command. Analysis of the broader command registry indicates that similar state-mutating commands (such as /restart) already possessed the ownerOnly enforcement. Developers must ensure any future commands that alter session state apply this flag consistently.

Exploitation of GHSA-39MP-545Q-W789 requires the attacker to meet specific preconditions. The attacker must be an authenticated participant in an active OpenClaw session, such as a multi-user chat or shared workspace. Furthermore, the attacker's identifier must be present in the commands.allowFrom configuration, granting them baseline command execution rights.

Once positioned, the attacker initiates the exploit by sending the crafted payload to the gateway. The payload consists of the literal command /send off. The gateway receives this string, parses the command primitive, and routes it to the vulnerable /send handler.

Upon execution, the handler updates the session's deliveryPolicy to off and persists the change. Subsequent outputs generated by the OpenClaw agent within that session will be suppressed by the gateway's egress filters, effectively silencing the agent. This state persists until the owner or another authorized user issues a corrective /send on or /send inherit command.

The vulnerability carries a Moderate severity rating with an estimated CVSS v3.1 base score of 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L). The impact is tightly constrained to the session in which the attacker is participating, preventing broader systemic compromise or cross-tenant contamination.

The Integrity impact is categorized as Low. The attacker can modify the deliveryPolicy state variable, representing an unauthorized alteration of system configuration. However, this modification is superficial and does not allow the injection of arbitrary code, the alteration of persistent databases outside the session context, or the modification of the agent's core operational logic.

The Availability impact is also categorized as Low. By issuing the /send off command, the attacker triggers a localized denial-of-service condition for the agent's output within the targeted session. This disrupts workflows and collaborative tasks relying on the agent, but the OpenClaw service itself remains entirely operational and responsive to other sessions.

Confidentiality is unaffected (None), as the vulnerability does not expose sensitive data, session transcripts, or configuration files to the attacker. The flaw strictly concerns the authorization of a state-mutating command rather than an information disclosure vector.

The primary remediation for GHSA-39MP-545Q-W789 is to upgrade the openclaw npm package to version 2026.3.27 or later. The patch implements the necessary ownerOnly enforcement within the command handler, ensuring that non-owner users are categorically denied access to the /send functionality.

For deployments where immediate patching is not operationally feasible, administrators can implement a configuration-based mitigation. By reviewing the config.json file, administrators should strictly limit the entries in the commands.allowFrom array. Removing untrusted users from this array entirely strips their command execution privileges, neutralizing the attack vector at the gateway ingress level.

Additionally, security teams should audit any custom command handlers developed for the OpenClaw ecosystem. Custom plugins that modify session state must explicitly implement the isOwner() middleware or equivalent privilege checks. Relying solely on the base isAuthorized() validation is insufficient for administrative actions.