GHSA-9WQX-G2CW-VC7R: Authorization Bypass in OpenClaw Matrix Verification Router

OpenClaw operates as a personal AI assistant that integrates with the Matrix protocol for messaging and interaction. The application implements a Direct Message (DM) policy engine to restrict which Matrix users are authorized to communicate with the bot. This engine supports multiple configuration states, including open, pairing, allowlist, and disabled, which dictate the ingress filtering rules for incoming messages.

The vulnerability, tracked as GHSA-9WQX-G2CW-VC7R, constitutes an authorization bypass within this Matrix integration. The application successfully filters standard text and command messages through the DM policy engine. However, specific protocol-level events related to encryption verification evade these checks.

By exploiting this oversight, unauthorized users bypass the intended access controls. Attackers communicate with the bot using specific Matrix Key Verification events, prompting the application to process the requests and generate responses despite the sender being excluded by the pairing or allowlist policies.

The root cause of this vulnerability lies in the architectural separation of standard message routing and verification event handling. OpenClaw utilizes a dedicated module, createMatrixVerificationEventRouter, to process end-to-end encryption verification flows. This router handles events such as m.key.verification.request and updates to Short Authentication String (SAS) summaries.

Standard room messages are evaluated against the DM policy engine before being processed by the application logic. The verification event router, however, operated independently of these ingress filters. When a verification event arrived, the application routed it directly to the verification handler without invoking the authorization policy checks.

This behavior exemplifies CWE-288: Authentication Bypass Using an Alternate Path or Channel. The application trusts the event type over the established session authorization state. Because the verification path lacked the requisite gating mechanisms, the system processed the payload and initiated the state machine for device verification, resulting in unauthorized interaction.

The vulnerable implementation resided in extensions/matrix/src/matrix/monitor/verification-events.ts. The original functions responsible for routing verification events, specifically routeVerificationEvent and routeVerificationSummary, lacked authorization enforcement. They accepted incoming payloads and immediately processed the verification state machine without validating the sender's identity against the configured access lists.

Commit 2383daf5c4a4e08d9553e0e949552ad755ef9ec2 resolves this flaw by introducing a comprehensive gating function named isVerificationNoticeAuthorized. This function acts as a mandatory authorization checkpoint before any verification logic executes. It explicitly checks the global dmEnabled boolean and the current dmPolicy state.

The patched code evaluates the sender's identity against the configured access controls. If the policy is not set to open, the function retrieves the allowFrom list and the pairing store data. It utilizes resolveMatrixMonitorAccessState to determine if the specific sender holds authorization to interact with the bot. Unauthorized events are dropped, and a verbose log message is generated, closing the alternate execution path.

async function isVerificationNoticeAuthorized(params: {
  senderId: string;
  allowFrom: string[];
  dmEnabled: boolean;
  dmPolicy: "open" | "pairing" | "allowlist" | "disabled";
  readStoreAllowFrom: () => Promise<string[]>;
  logVerboseMessage: (message: string) => void;
}): Promise<boolean> {
  if (!params.dmEnabled || params.dmPolicy === "disabled") {
    params.logVerboseMessage(
      `matrix: blocked verification sender ${params.senderId} (dmPolicy=${params.dmPolicy}, dmEnabled=${String(params.dmEnabled)})`,
    );
    return false;
  }
  if (params.dmPolicy === "open") {
    return true;
  }
  const storeAllowFrom = await params.readStoreAllowFrom();
  const accessState = resolveMatrixMonitorAccessState({
    allowFrom: params.allowFrom,
    storeAllowFrom,
    groupAllowFrom: [],
    roomUsers: [],
    senderId: params.senderId,
    isRoom: false,
  });
  if (accessState.directAllowMatch.allowed) {
    return true;
  }
  params.logVerboseMessage(
    `matrix: blocked verification sender ${params.senderId} (dmPolicy=${params.dmPolicy})`,
  );
  return false;
}

Exploiting this vulnerability requires network access to the Matrix federation and a valid Matrix user account. The attacker does not require prior authentication or authorization with the target OpenClaw instance. The attacker must know the Matrix ID of the target bot to initiate the communication.

The exploitation process begins with the attacker crafting a specific Matrix protocol message. Instead of sending a standard text message (m.room.message), the attacker constructs a payload with the msgtype field set to m.key.verification.request. This event signals an intent to verify the end-to-end encryption keys between the devices.

Upon receiving this crafted event, the OpenClaw Matrix integration processes the payload through the vulnerable verification router. The bot responds to the attacker with verification guidance or Short Authentication String (SAS) summaries, such as emoji or decimal strings. This interaction confirms that the attacker successfully bypassed the DM policy restrictions and elicited a state-changing response from the application.

The vulnerability carries a CVSS 3.1 base score of 5.3, categorized as Moderate severity. The associated vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N reflects a network-based attack vector requiring no privileges or user interaction, with a low impact on system integrity.

The primary consequence of this flaw is the circumvention of intended access controls. Unauthorized entities communicate with the application, forcing it to process cryptographic verification routines. This unauthorized interaction consumes application resources and alters the internal state of the verification handler, polluting the session data with unauthenticated requests.

The impact remains restricted to the Matrix communication layer. The vulnerability does not expose arbitrary command execution capabilities or grant access to the bot's core configuration files. Confidentiality is preserved, as the attacker cannot access the stored data or interaction history of legitimate, authorized users.

The definitive remediation for GHSA-9WQX-G2CW-VC7R is upgrading OpenClaw to version 2026.3.26 or later. This release incorporates commit 2383daf5c4a4e08d9553e0e949552ad755ef9ec2, which integrates the isVerificationNoticeAuthorized gating function into the verification event routing pipeline.

System administrators should implement log monitoring to detect attempted exploitation. Following the patch, OpenClaw emits specific verbose log entries when dropping unauthorized verification requests. Monitoring systems should alert on the string matrix: blocked verification sender, which indicates an external entity attempting to initiate the verification flow against policy.

In environments where immediate patching is unfeasible, administrators can mitigate the risk at the network level. Restricting the bot's underlying Matrix homeserver federation to trusted domains prevents unauthorized external users from discovering and interacting with the bot's Matrix ID. This architectural defense limits the attack surface to the local, trusted homeserver population.