GHSA-RG8M-3943-VM6Q: Authorization Bypass in OpenClaw Matrix Extension via Reply Context

OpenClaw is a self-hosted AI personal assistant platform that integrates with various communication protocols. The Matrix extension allows users to interact with the AI agent within Matrix rooms and direct messages. To secure these interactions, OpenClaw implements access controls via the groupAllowFrom and roomsConfig settings. These mechanisms form an allowlist that dictates which Matrix users possess the authorization to invoke the AI agent.

The vulnerability, tracked as GHSA-RG8M-3943-VM6Q, represents an authorization bypass (CWE-285, CWE-863) within the message ingestion pipeline of the Matrix extension. While the application correctly validates the sender of an incoming message against the allowlist, it fails to perform the same validation on secondary message components. Specifically, when an incoming message is a reply or part of a thread, OpenClaw automatically fetches the original message content to provide the LLM with conversational context.

The core issue lies in the system's implicit trust of this fetched context. Because the system omits a sender validation check on the referenced message, content authored by non-allowlisted users enters the AI's processing pipeline. This architectural oversight provides a vector for unauthorized actors to interact with the underlying LLM, bypassing the intended perimeter controls defined by the administrator.

The root cause of this vulnerability exists in the logical flow of the Matrix event handler. When a new event triggers the webhook or polling mechanism, the system evaluates the primary senderId associated with the event. If the senderId matches an entry in the groupAllowFrom list, the application proceeds to construct the context object required by the language model.

During this context construction phase, the application attempts to resolve relational data to maintain conversational coherence. If the triggering event contains a m.thread or m.in_reply_to relation, OpenClaw executes a secondary fetch operation to retrieve the parent event. Prior to the fix, the application appended the parent event's body to the inbound context array without inspecting the parent event's senderId.

This discrepancy between primary event validation and secondary context validation creates an exploitable condition. The system incorrectly assumes that an authorized reply implies authorization of the original message content.

The official fix was implemented in commit 8a563d603b70ef6338915f0527bee87282c3bad5. The maintainers addressed the flaw by introducing an explicit authorization barrier for fetched contextual data. The core of the remediation resides in extensions/matrix/src/matrix/monitor/handler.ts, where a new helper function named shouldIncludeRoomContextSender was integrated into the processing logic.

The patch modifies the resolveReplyContext and resolveThreadContext utility functions to ensure they return not only the message body but also the senderId of the parent message. The handler.ts script then passes this senderId to the shouldIncludeRoomContextSender function. This function compares the parent sender against the effectiveRoomUsers and effectiveGroupAllowFrom arrays.

If the validation fails, the application gracefully drops the unauthorized context. The threadContext or replyContext variable is set to undefined, preventing the unauthorized text from being appended to the ThreadStarterBody or similar context properties. The system also logs the intervention: matrix: drop thread root context (sender allowlist).

// Regression Test Demonstrating the Fix
it("drops thread and reply context fetched from non-allowlisted room senders", async () => {
  const { handler, finalizeInboundContext } = createMatrixHandlerTestHarness({
    groupPolicy: "allowlist",
    groupAllowFrom: ["@alice:example.org"],
  });
 
  await handler("!room:example.org", createMatrixTextMessageEvent({
      sender: "@alice:example.org", 
      body: "@room follow up",
      relatesTo: {
        rel_type: "m.thread",
        event_id: "$thread-root", // Authored by unauthorized user
      },
  }));
 
  const finalized = vi.mocked(finalizeInboundContext).mock.calls.at(-1)?.[0];
  expect(finalized.ThreadStarterBody).toBeUndefined(); // Validates the drop
});

The fix is comprehensive for this specific attack vector. By enforcing uniform validation across both primary events and secondary relational contexts, the application closes the parsing loophole. Setting the context to undefined ensures no residual data fragments reach the LLM.

Exploiting this vulnerability requires a specific set of preconditions and passive user interaction (UI:P). The attacker must reside in a Matrix room where the OpenClaw agent operates and where at least one authorized user is present. The attacker does not need to be on the groupAllowFrom list, nor do they require elevated privileges within the Matrix server itself.

The attack sequence initiates when the attacker transmits a malicious message into the shared room. This message typically contains a prompt injection payload designed to manipulate the AI agent's instructions. Upon transmission, the OpenClaw agent receives the event, checks the sender against the allowlist, and silently discards the message due to the authorization failure.

The critical phase relies on interaction from an authorized user. The authorized user must reply to the attacker's message or start a thread based on it. This action generates a new Matrix event authored by a trusted sender. When OpenClaw processes this new event, the allowlist validation succeeds.

The application then traverses the relational data defined in the authorized user's message. It fetches the attacker's initial payload and loads it into the AI's processing context. The underlying language model ingests the attacker's payload as legitimate conversational context, executing the embedded prompt injection instructions within the operational scope of the authorized user.

The CVSS v4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N) assigns this vulnerability a base score of 5.1 (Medium). The score reflects the necessity of user interaction (UI:P) and the specific attack requirements (AT:P), specifically the presence of an authorized user willing to interact with the attacker's content.

The primary impact manifests as a loss of confidentiality (VC:L) and integrity (VI:L) localized to the AI agent's operational capabilities. An attacker successfully exploiting this bypass achieves indirect prompt injection. Depending on the tools and APIs exposed to the OpenClaw agent, the injected instructions force the agent to perform unauthorized actions or disclose sensitive information accessible to the authorized user's session.

The scope is constrained by the permissions granted to the AI model itself. The vulnerability does not provide the attacker with direct remote code execution on the host server running the OpenClaw binary, nor does it compromise the underlying Matrix infrastructure. The severity scales directly with the sensitivity of the integrations and data stores accessible to the OpenClaw agent within the targeted deployment.

The definitive remediation strategy requires upgrading the openclaw npm package to version 2026.3.31 or higher. This release integrates commit 8a563d603b70ef6338915f0527bee87282c3bad5, which introduces the required contextual sender validation logic. System administrators must restart the OpenClaw service following the package update to ensure the new application logic takes effect.

Organizations should review their Matrix extension configurations. Ensure the groupPolicy parameter is explicitly set to allowlist. Verify that the groupAllowFrom array contains only highly trusted Matrix IDs. Removing unnecessary or overly permissive entries from the allowlist reduces the overall attack surface and limits the number of users capable of inadvertently triggering the exploit chain.

Security teams can monitor for exploitation attempts by analyzing the application's runtime logs. Following the application of the patch, any attempt to inject context from an unauthorized sender generates a specific log entry: matrix: drop thread root context (sender allowlist). A high volume of these log messages originating from specific rooms indicates targeted prompt injection attempts or misconfigured authorized users repeatedly interacting with untrusted content.