GHSA-57R2-H2WJ-G887: Trust Boundary Violation in OpenClaw Isolated Cron Awareness Events

OpenClaw utilizes isolated cron agents to manage periodic tasks and process external webhook deliveries from third-party services. These agents generate summaries and awareness updates that are subsequently mirrored into the primary session stream. The system classifies events within this stream using provenance labels, distinguishing between untrusted external inputs and authoritative system instructions. This distinction dictates how downstream Large Language Models (LLMs) and user interfaces process the corresponding data.

A flaw in the delivery dispatch mechanism allowed isolated cron agents to promote untrusted data into the session stream without appropriate provenance labels. Specifically, the system defaulted to treating events as authoritative system events unless explicitly flagged otherwise. The lack of explicit trust downgrading for external webhook inputs constitutes a violation of the trust boundary between the isolated agent and the core session logic.

This trust-labeling failure manifests as Insufficient Verification of Data Authenticity (CWE-345) and User Interface Misleading of Content Origin (CWE-451). Untrusted inputs bypass provenance checks, inheriting high-integrity system status within the application state. The vulnerability facilitates prompt injection scenarios where an LLM processes external attacker-controlled data as trusted system instructions.

The vulnerability originates from a missing trust flag in the OpenClaw cron delivery pipeline. The underlying event architecture operates on an implicit trust model where the trusted boolean property defaults to true when omitted from the options object. The enqueueSystemEvent function relies on this property to establish the provenance of ingested events.

Within src/cron/isolated-agent/delivery-dispatch.ts, the isolated agent's delivery dispatch logic invokes enqueueSystemEvent to process awareness updates. Prior to version 2026.4.17, this invocation did not specify a trusted field. Consequently, the core session logic applied the default high-integrity trust state to data originating from untrusted webhook payloads.

The gateway cron wrapper in src/gateway/server-cron.ts exacerbated this issue by failing to forward trust metadata through the pipeline. The wrapper design did not capture or persist the trusted flag during session-key scoping and translation. This architectural oversight ensured that even if an upstream component successfully downgraded the event's trust level, the downgrade would not survive the forwarding process to the final event queue.

The flawed implementation allowed external inputs to traverse the delivery pipeline without explicit trust definitions. The queueCronAwarenessSystemEvent function processed these inputs and dispatched them directly to the event queue. The omission of the trusted parameter instructed the system to fall back to its default authoritative state.

The patch introduces three distinct modifications to enforce trust-label preservation. First, the CronServiceDeps interface in src/cron/service/state.ts was updated to explicitly require or allow an optional trusted boolean within the enqueueSystemEvent options. Second, the buildGatewayCronService function in src/gateway/server-cron.ts was modified to capture and forward the trusted flag, ensuring metadata persistence across translation boundaries.

The most critical change occurs within src/cron/isolated-agent/delivery-dispatch.ts. The invocation of enqueueSystemEvent now hardcodes the trusted property to false for cron awareness events.

// src/cron/isolated-agent/delivery-dispatch.ts
async function queueCronAwarenessSystemEvent(params: { ... }) {
  // ...
  await enqueueSystemEvent(text, {
    sessionKey: params.sessionKey,
    contextKey: params.deliveryIdempotencyKey,
    trusted: false, // Explicitly downgrades trust level
  });
}

Exploitation requires an active webhook integration linked to an OpenClaw isolated cron job. The attacker must possess the ability to send messages or payloads to the linked integration, such as a connected Telegram bot or Discord channel. No authentication to the OpenClaw management interface is required, as the attack leverages the intended external input channels.

The attacker initiates the exploit sequence by transmitting a crafted message containing prompt injection payloads to the external integration. The isolated cron agent processes this message, generating an awareness event designed to summarize the external interaction. The agent then invokes enqueueSystemEvent, promoting the attacker-controlled summary to the main session queue without the trusted: false flag.

Upon promotion, the application treats the payload as an authoritative system instruction. If the application utilizes an LLM to process session events, the model prioritizes the injected instructions over standard user inputs. Simultaneously, the application's user interface renders the event using system-level visual indicators, masking the external origin of the data.

The primary security impact involves the subversion of downstream LLM processing mechanisms. By inheriting the system provenance label, attacker-controlled data gains elevated priority within the LLM's context window. The model interprets the injected payload as a high-integrity instruction rather than untrusted user input, resulting in successful prompt injection.

The secondary impact concerns user interface integrity. OpenClaw relies on provenance labels to visually distinguish between system events and external inputs. The failure to mark cron awareness events as untrusted forces the UI to render attacker payloads as legitimate system actions. This misleads human operators regarding the system's current state and historical actions.

The overall severity is classified as Low. Exploitation does not directly yield arbitrary code execution, unauthorized data exfiltration, or denial of service. The impact is constrained to logic subversion within the LLM context and UI spoofing, requiring specific webhook configurations to be present and active within the target environment.

The vendor addressed this vulnerability in OpenClaw version 2026.4.17. System administrators must upgrade the openclaw package to this version or later to deploy the corrected trust-labeling logic. The patch applies explicit trust downgrades to isolated cron events and ensures metadata forwarding through the gateway wrapper.

Development teams should audit all custom cron jobs and webhook integrations that interact with the enqueueSystemEvent API. Any implementation accepting data from external sources must be updated to explicitly include the trusted: false flag in the options object. This defensive practice prevents regressions if default trust states change in future framework revisions.

For environments where immediate patching is not feasible, implement frontend rendering validations. Custom user interfaces processing OpenClaw session events should independently verify the context keys or source origins of system messages before rendering them as authoritative. Discrepancies between expected system origins and webhook delivery identifiers can be used to flag anomalous events.