GHSA-57R2-H2WJ-G887: Root-Cause Trust Propagation Fix for OpenClaw Cron Events
Summary
The patch addresses a trust-boundary violation in OpenClaw's isolated cron event flow by explicitly preserving and forwarding the optional trusted flag across dispatch and gateway wrapper layers. Previously, mirrored cron awareness events and gateway-enqueued system events could lose an explicit trusted:false downgrade, allowing externally influenced content to be represented as authoritative system-originated events. The changes are small but directly target the trust metadata propagation failure identified in the advisory.
Analysis
Vulnerability
GHSA-57R2-H2WJ-G887 describes a trust boundary violation in OpenClaw's isolated cron awareness event handling. The issue is not raw event creation alone, but loss of trust metadata as events cross subsystem boundaries. In the vulnerable code path, isolated cron awareness events mirrored into the main session were emitted with an explicit untrusted designation, but downstream interfaces did not consistently preserve that downgrade. Separately, the gateway cron wrapper accepted enqueue options without a trust field, so calls that intended to mark events as trusted: false could not carry that state through session-key scoping.
This creates a semantic integrity problem: externally influenced or lower-trust inputs can be surfaced as if they were authoritative system events. In systems that feed these events into LLM prompts, agent memory, or operator-facing UI, that trust confusion can enable prompt injection, misleading automation behavior, or spoofed system-originated messaging. The advisory and patch summary both frame the bug as a missing trust-label propagation issue rather than a parser or authentication flaw.
// Vulnerable interface omitted trust metadata entirely
opts?: { agentId?: string; sessionKey?: string; contextKey?: string },
// Vulnerable gateway wrapper dropped any explicit trust downgrade
enqueueSystemEvent(text, { sessionKey, contextKey: opts?.contextKey });Sources: patch commit, official advisory, report summary.
Patch
The patch makes two targeted changes to restore trust-label continuity across the affected paths.
First, the cron service state interface is expanded so callers can provide an optional trusted boolean alongside existing routing metadata. This is the key contract change that allows trust state to survive intermediate wrappers.
Second, the gateway cron wrapper now forwards trusted: opts?.trusted when calling enqueueSystemEvent, instead of reconstructing the options object with only sessionKey and contextKey. The patch also updates isolated-agent dispatch behavior and tests to ensure mirrored awareness events remain explicitly untrusted where intended.
// Patched interface
opts?: { agentId?: string; sessionKey?: string; contextKey?: string; trusted?: boolean },
// Patched gateway forwarding
enqueueSystemEvent(text, {
sessionKey,
contextKey: opts?.contextKey,
trusted: opts?.trusted,
});The added tests are important because they validate the exact failure mode: an explicit trust downgrade survives session-key rewriting in the gateway, and isolated cron double-announce behavior retains trusted: false. This aligns with the changelog entry in the patch commit: preserving trusted: false on isolated cron awareness events mirrored into the main session and forwarding the optional trust flag through the gateway wrapper. See the commit and advisory.
Review
Pros
The fix is tightly scoped to the actual root cause: trust metadata was being dropped at API boundaries. By extending the options type and forwarding the field through the gateway wrapper, the patch repairs the trust propagation contract instead of merely special-casing one call site. The explicit test coverage is also strong for a one-shot patch: it verifies preservation of trusted: false during cron enqueue and session-key transformation, which is the exact trust-boundary crossing implicated by the advisory. The isolated-agent dispatch updates further reduce ambiguity by ensuring mirrored awareness events are explicitly marked untrusted.
Cons
The patch appears intentionally minimal, which is good for safety, but it also means assurance is limited to the reviewed paths. The provided snippets do not show a broader audit of other wrappers, serializers, event buses, or UI renderers that may also default missing trust metadata to a higher-trust interpretation. Because trusted remains optional, any remaining call paths that omit it may still rely on implicit defaults elsewhere in the system. The patch therefore fixes the identified propagation bug, but the overall security posture still depends on consistent downstream handling of absent versus explicit trust labels.
Verdict
Root-cause.
This patch directly addresses the underlying defect: loss of trust-state across subsystem boundaries. It updates the type contract, forwards the field through the gateway wrapper, and adds regression tests for the exact downgrade-preservation scenario described in GHSA-57R2-H2WJ-G887. Based on the supplied diff, this is not a superficial bandaid; it repairs the trust propagation mechanism that allowed untrusted cron-derived content to be represented as authoritative system events. Engineers should still consider a follow-up audit for other event ingress and mirroring paths, but the patch itself is source-grounded and appropriately targeted.
Recommended Labs
Try this vulnerability pattern yourself with hands-on labs.
- Confusable.js
Best fit for the advisory’s core issue: externally influenced data being treated as authoritative system-originated input. This lab maps to spoofing/confusion and trust-boundary validation themes that are directly relevant to missing trust labels on cron-dispatched events.
- Pollution.js
Useful for practicing defensive handling of untrusted input that can silently alter downstream application behavior. While not event-label specific, it reinforces boundary enforcement, input integrity, and defense-in-depth patterns relevant to trust propagation flaws.
- BadFunc.js
Recommended as a nearby defensive lab for the advisory’s prompt-injection angle. It helps build secure coding instincts around preventing untrusted input from being interpreted in privileged ways, which is conceptually aligned with LLM prompt injection and unsafe event-to-action flows.