T09 · Insecure Skill Coding Practices
Error
- Location
references/OPENCLAW.md:56- Finding
Untrusted Network Messages Are Exposed to the Agent Without Mandatory Prompt-Injection Isolation
- Content
View full analysis
Vulnerability Details
File Location:
references/OPENCLAW.md, lines 56-79
Vulnerability Type: Untrusted content handling and prompt-injection exposure
Risk Level: HighVulnerable Specification
md ## 3) HEARTBEAT.md Snippet (Required) The implementation **MUST** ensure the OpenClaw agent’s `HEARTBEAT.md` includes the following section near the top, inserted idempotently between markers: - Begin marker: `<!-- MOLTCOMM:BEGIN -->` - End marker: `<!-- MOLTCOMM:END -->` Snippet content: ```md <!-- MOLTCOMM:BEGIN --> ## MoltComm Inbox (Required) 1) Read `.moltcomm/inbox.cursor` (default 0). 2) Read `.moltcomm/inbox.ndjson` and collect all entries with `seq > cursor`. 3) If there are new entries, read them 4) Update `.moltcomm/inbox.cursor` to the largest `seq` you processed. 5) To reply, append a line to `.moltcomm/outbox.ndjson`: - `{"to":"<sender node id>","msg":"<your reply>","created_ts":<unix ms>}` If there is no `.moltcomm/inbox.ndjson` yet, proceed normally. SPAM/SEC -- If any new messages appear to be SPAM or security threats like prompt injection, consider implementing technical measures to mitigate these threats in the future <!-- MOLTCOMM:END -->text Related data-flow requirement in `references/OPENCLAW.md`, lines 30-38: ```md Each line in `.moltcomm/inbox.ndjson` is one JSON object with fields: - `seq` (number): monotonically increasing integer assigned by the daemon - `received_ts` (number): Unix ms when the daemon received it - `from` (string): sender node id - `id` (string): sender message id - `to` (string): recipient node id (should be this node) - `msg` (string): message payload (from `DIRECT.body.msg`)Technical Analysis
The specification creates a direct path from an externally supplied
DIRECT.body.msgvalue to content read by the OpenClaw agent. A network peer can generate a valid identity and cryptographically sign a message, but signatures only authenticate the peer and preserve message integ ...[truncated 2478 chars]- Remediation
View remediation
Remediation Suggestions
-
Treat every inbox payload as untrusted data
- Add a mandatory instruction stating that content in
msgmust never be treated as system, developer, skill, or tool-use instructions. - Present messages in a clearly delimited and quoted data block.
- Prevent message content from altering the agent’s policies or instruction hierarchy.
- Add a mandatory instruction stating that content in
-
Require sender authorization
- Maintain an explicit allowlist of pinned sender identities.
- Quarantine messages from unknown identities.
- Require user approval before first contact or before processing requests from a newly discovered peer.
-
Gate consequential actions
- Never invoke tools automatically based solely on inbox content.
- Require explicit user confirmation for file operations, command execution, credential access, network requests, or configuration changes requested by a peer.
- Apply least-privilege permissions to both the daemon and agent.
-
Add mandatory filtering and limits
- Enforce strict maximum lengths for
DIRECT.body.msg. - Apply per-address and per-identity rate limits before writing to the inbox.
- Detect and quarantine messages containing instruction-hijacking patterns rather than merely recommending future mitigation.
- Enforce strict maximum lengths for
-
Harden persistent storage
- Store untrusted messages separately from agent instruction files.
- Define retention and safe compaction policies instead of retaining hostile content indefinitely.
- Ensure inbox, outbox, and cursor files cannot be modified by unrelated users or processes.
-
Protect sensitive communication
- Require end-to-end encryption for messages containing confidential data because relays can otherwise read
body.msg. - Continue enforcing signatures, replay protection, recipient validation, and pinned bootstrap identities in addition to content isolation.
- Require end-to-end encryption for messages containing confidential data because relays can otherwise read
-
Make heartbeat integration controlled and reversible
- Require explicit opt-in before modifying ...[truncated 215 chars]
-