GHSA-792Q-QW95-F446: Authorization Bypass in OpenClaw Signal Reaction Handling

A logic error in the OpenClaw Signal integration module permits the bypass of authorization controls for specific inbound event types. The vulnerability specifically affects how the system handles 'reaction-only' messages—Signal events that consist solely of an emoji reaction to a previous message, without accompanying text body content. In affected versions, these events are ingested and processed by the system before the sender's authorization status is evaluated.

The core function of OpenClaw's Signal handler is to act as a gateway between the Signal network and the internal agent logic. It is responsible for filtering traffic based on strict policies, such as dmPolicy (which dictates whether direct messages are allowed), allowFrom lists (whitelisting specific phone numbers), and groupPolicy. By design, no event should propagate to the internal event bus unless the sender has been explicitly authorized according to these policies.

However, due to the ordering of operations in the event processing pipeline, reaction events trigger an early execution path. This path enqueues a Signal reaction added system notification and terminates the handler's execution immediately, skipping the subsequent code blocks responsible for policy enforcement. Consequently, any Signal user—regardless of their relationship to the bot or their presence on an allowlist—can trigger valid system events within the agent's context simply by reacting to a message.

The vulnerability resides in src/signal/monitor/event-handler.ts, specifically within the createSignalEventHandler function. The architectural flaw stems from a failure to centralize access control decisions at the entry point of the data ingress pipeline. Instead, access checks were interleaved with message type processing, leading to a scenario where certain message types were handled before security validation.

In the vulnerable implementation, the code iterates through incoming Signal envelopes. Upon receiving an envelope, the handler explicitly checks if the message is a reaction (if (reaction && !hasBodyContent)). If this condition evaluates to true, the handler executes a logic block that logs the reaction, resolves the target message, and emits a system event. Crucially, this block concludes with a return statement, intending to prevent double-processing of the event as a standard text message.

The security controls—verifying the sender against the allowFrom list, checking the dmPolicy state (e.g., ensuring the user is paired), and validating group membership—were implemented after this reaction handling block. This sequential error created a blind spot: the code assumed that if an event was 'just a reaction', it did not require the same level of scrutiny as a text message, or arguably, the developers simply ordered the logic based on functional priority rather than security dependency.

The following analysis illustrates the control flow logic error in src/signal/monitor/event-handler.ts and the subsequent remediation. The vulnerability is a classic case of "Check-Use-Time" ordering issues, where data is used (processed) before permissions are checked.

Vulnerable Logic

In the pre-patch version, the reaction handling block (marked with [!]) executes immediately, bypassing the policy checks located further down the function:

// src/signal/monitor/event-handler.ts (Vulnerable)
 
export function createSignalEventHandler(deps) {
  return async (envelope) => {
    const { source, dataMessage } = envelope;
    
    // [!] VULNERABILITY: Reaction check happens first
    if (dataMessage.reaction) {
      logger.info(`Processing reaction from ${source}`);
      deps.eventBus.emit('signal.reaction', { ... });
      return; // <--- Returns here, skipping auth checks below
    }
 
    // [!] Security checks are unreachable for reactions
    const isAllowed = checkAccessPolicy(source);
    if (!isAllowed) {
      logger.warn(`Blocked message from ${source}`);
      return;
    }
 
    // Process standard message...
  };
}

Patched Logic

The fix involves hoisting the access decision logic to the very top of the handler scope. The commit 2aa7842adeedef423be7ce283a9144b9f1a0a669 refactors the handler to use a centralized security utility, resolveDmGroupAccessDecision, ensuring a uniform decision is made regardless of message type.

// src/signal/monitor/event-handler.ts (Fixed)
 
export function createSignalEventHandler(deps) {
  return async (envelope) => {
    const { source, dataMessage } = envelope;
 
    // [1] FIX: Resolve access decision immediately
    // This uses shared logic from src/security/dm-policy-shared.js
    const accessDecision = resolveDmGroupAccessDecision(deps.config, source);
 
    // [2] FIX: Enforce decision on reactions
    if (dataMessage.reaction) {
      if (accessDecision.decision !== 'allow') {
        logger.info(`Blocked reaction from ${source}: ${accessDecision.reason}`);
        return; // Early exit if unauthorized
      }
      
      // Only process if allowed
      deps.eventBus.emit('signal.reaction', { ... });
      return;
    }
 
    // [3] Enforce decision on standard messages
    if (accessDecision.decision !== 'allow') {
       // ... blocking logic
       return;
    }
    
    // Process standard message...
  };
}

By moving the accessDecision resolution before any content processing, the system ensures that no telemetry or state changes occur for unauthorized entities.

Exploiting this vulnerability requires no special tools beyond a standard Signal client and knowledge of the target OpenClaw instance's phone number. The attack relies on the target running a vulnerable version of the software with the Signal integration enabled.

Prerequisites

1. Target Identification: The attacker must know the Signal phone number associated with the OpenClaw bot.
2. No Authentication: The attacker does not need to be on the allowFrom list, nor do they need to have completed any "pairing" handshake. They can be a completely unknown external user.

Attack Steps

1. Initiate Contact: The attacker opens a Signal conversation with the bot's number.
2. Send Reaction: The attacker sends an emoji reaction to a message (or potentially attempts to react to a non-existent message context, depending on Signal protocol handling). In a typical scenario, if the bot has ever sent a message (e.g., an error message or a broadcast), the attacker reacts to it.
3. Bypass Verification: The OpenClaw instance receives the envelope. It identifies the payload as a reaction. It immediately creates an internal Signal reaction added event.
4. Effect: The event is added to the agent's processing queue. If the agent is configured to log events or trigger logic on reactions, the unauthorized input is acted upon.

While this does not grant direct Remote Code Execution (RCE), it allows for Event Injection. An attacker could flood the system with reactions, filling logs and potentially confusing the agent's context window or state machine if it consumes reaction events as part of its reasoning loop.

The primary impact of GHSA-792Q-QW95-F446 is the violation of integrity regarding the system's input stream. Security controls are intended to create a trust boundary where only authorized signals (literally and figuratively) influence the agent's state. This vulnerability dissolves that boundary for reaction events.

Confidentiality

The impact on confidentiality is low but non-zero. By observing whether reactions are successfully processed (e.g., via delivery receipts or side-channel timing analysis), an attacker might infer the presence and operational status of the bot, even if the bot is configured to silently ignore unauthorized standard messages.

Integrity

The impact on integrity is moderate. The system accepts and processes input from untrusted sources. In automated systems, "reaction" events are often used as control signals (e.g., "thumbs up" to approve an action). If an attacker can inject these signals, they may be able to influence the bot's decision-making process, depending on how the agent interprets reactions.

Availability

There is a potential for availability impact through resource exhaustion. Because the reaction logic processes and logs events, a high-volume flood of reactions from multiple unauthorized numbers could saturate the event bus or fill disk space with logs, although this would require a sustained attack volume.