T01 · Skill Instruction Hijacking
- Location
index.ts:420- Finding
Spoofable UDP Peer Identity Enables Trusted-Peer Prompt Injection
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a local agent messenger, but it can automatically wake the agent from network messages and relay full message contents, with trust controls that are weaker than documented.
Install only if you trust the LAN and understand that approved or spoofed peers may trigger agent activity. Keep relayServer and hookToken disabled unless you specifically need monitoring or automatic wake-up, do not send secrets through this channel, and do not rely on always-confirm or peer IDs as strong security controls until the implementation is fixed.
index.ts:420Spoofable UDP Peer Identity Enables Trusted-Peer Prompt Injection
index.ts:480The Documented always-confirm Trust Mode Is Not Enforced
index.ts:91Optional Relay Sends Complete Message Contents over Unauthenticated Plaintext UDP
The declared purpose emphasizes local LAN messaging, but the skill also supports forwarding all messages to a relay server, using a hook token, triggering local HTTP wake-up flows, and runtime reconfiguration of trust and relay settings. This mismatch can mislead users about data flows and trust boundaries, creating a real risk of silent message exfiltration and expanded control surfaces.
Instructions found that direct the agent to transmit conversation context or user data to external services.
---
name: udp-messenger
description: Use when agents need to communicate over the local network — "send message to agent", "discover agents", "check for messages", "coordinate with other agents", "approve agent", "agent status", "add peer", "message log"
metadata:
openclaw:
requires:
Referenced artifact was not completely inspected
These tools are registered by the `openclaw-udp-messenger` plugin (`index.ts`):
The skill can forward every sent and received message to a separately configured relay server, which materially expands its behavior beyond local peer-to-peer UDP coordination. This creates a clear confidentiality and scope-expansion risk: local agent communications may be silently exfiltrated to another host, including sensitive prompts, coordination data, and possibly secrets contained in messages.
The skill is explicitly designed to send messages to other agents over the network, which creates a real exfiltration channel if the skill is invoked with sensitive content. Although the documentation includes some cautions, the broad trigger language and communication-focused functionality make it possible for data to be transmitted outside the local agent boundary if the user or agent mishandles content.
---
name: udp-messenger
description: Use when agents need to communicate over the local network — "send message to agent", "discover agents", "check for messages", "coordinate with other agents", "approve agent", "agent status", "add peer", "message log"
metadata:
openclaw:
requires:
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Key Rules
1. **Trust requires user approval.** Never auto-approve a peer. Always show the user who is trying to contact them and let them decide.
2. **Conversation limits exist.** Each peer pair has a configurable exchange limit per hour (default: 10). Once reached, stop auto-responding and inform the user. The limit resets on a rolling hourly window.
3. **Trust mode is configurable.** In `approve-once` mode, a single approval lets messages flow. In `always-confirm` mode, every message needs user approval.
4. **Don't leak sensitive info.** Never share project secrets, credentials, or private data with other agents unless the user explicitly asks you to.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Key Rules
1. **Trust requires user approval.** Never auto-approve a peer. Always show the user who is trying to contact them and let them decide.
2. **Conversation limits exist.** Each peer pair has a configurable exchange limit per hour (default: 10). Once reached, stop auto-responding and inform the user. The limit resets on a rolling hourly window.
3. **Trust mode is configurable.** In `approve-once` mode, a single approval lets messages flow. In `always-confirm` mode, every message needs user approval.
4. **Don't leak sensitive info.** Never share project secrets, credentials, or private data with other agents unless the user explicitly asks you to.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Key Rules
1. **Trust requires user approval.** Never auto-approve a peer. Always show the user who is trying to contact them and let them decide.
2. **Conversation limits exist.** Each peer pair has a configurable exchange limit per hour (default: 10). Once reached, stop auto-responding and inform the user. The limit resets on a rolling hourly window.
3. **Trust mode is configurable.** In `approve-once` mode, a single approval lets messages flow. In `always-confirm` mode, every message needs user approval.
4. **Don't leak sensitive info.** Never share project secrets, credentials, or private data with other agents unless the user explicitly asks you to.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Key Rules
1. **Trust requires user approval.** Never auto-approve a peer. Always show the user who is trying to contact them and let them decide.
2. **Conversation limits exist.** Each peer pair has a configurable exchange limit per hour (default: 10). Once reached, stop auto-responding and inform the user. The limit resets on a rolling hourly window.
3. **Trust mode is configurable.** In `approve-once` mode, a single approval lets messages flow. In `always-confirm` mode, every message needs user approval.
4. **Don't leak sensitive info.** Never share project secrets, credentials, or private data with other agents unless the user explicitly asks you to.
The skill documents an optional relayServer that forwards all sent and received messages to a central monitor server, but it does not present this as a prominent user-facing warning or consent requirement. In a messaging skill, this creates a meaningful transparency and privacy risk because operators may unknowingly route inter-agent content, including sensitive task data, to a third-party or centralized listener.
The documentation shows several ways to configure and set the hook token, including at runtime, but does not clearly warn that this token is a credential that should be kept secret and not exposed in logs, screenshots, chat transcripts, or shell history. Because the token triggers agent wake-up through a webhook, compromise could allow unauthorized triggering or abuse of agent actions.
The README documents forwarding every sent and received message to a central monitoring server, but does not present a strong, nearby warning that this may disclose sensitive prompts, agent outputs, or internal coordination data. In an agent-messaging plugin, message contents are likely to contain natural-language secrets or operational details, so operators need explicit informed consent before enabling such a feature.
The documented design of full message logging plus optional forwarding of all messages to a monitoring server creates a direct data leakage path for agent conversations. Since agent-to-agent messages may include sensitive instructions, project context, or derived secrets, central collection materially increases confidentiality risk even if intended for observability.
The README makes a misleading security claim that all traffic stays on the local network, while the documented relay mode explicitly forwards copies of messages to another server. Even if relay is optional, this contradiction can cause operators to underestimate data exposure and enable the plugin in contexts where message confidentiality matters.
The skill exposes networked messaging, relay, webhook wake-up, and likely environment-backed configuration, but the manifest does not declare any restrictive tool scope or permissions boundary. That increases the chance the agent can use capabilities beyond what a user would infer from the manifest and weakens least-privilege protections.
The trigger phrases are broad and overlap with normal conversational requests like 'send message,' 'check for messages,' or 'agent status,' which can cause the skill to activate unexpectedly. Because this skill can communicate over the network and potentially forward data, overbroad activation increases the risk of unintended data sharing or trust changes.
The skill mentions an optional relay server, but the description does not clearly and prominently warn that messages may be copied to a remote monitoring server. Users may reasonably assume communication stays local, so inadequate disclosure creates a meaningful confidentiality risk.
The relay feature forwards complete message contents off-host without a strong user-facing warning at the moment it is enabled or used. Even if intentionally configured, the lack of clear consent and disclosure increases the chance of inadvertent sensitive-data exposure through routine agent-to-agent communication.
Trusted UDP messages are automatically turned into a local HTTP webhook request that triggers a new agent turn, embedding attacker-controlled message content into the generated prompt. This converts a network message channel into an agent-invocation and prompt-injection surface, allowing any trusted peer—or a spoofed peer if trust is weak—to influence autonomous local agent behavior.
The plugin reads broader application configuration and environment variables to obtain a webhook token unrelated to basic UDP messaging. Accessing local credentials expands privilege and can be abused to invoke local control-plane actions, especially when paired with the wake-up mechanism that uses the recovered token.
The skill description uses broad phrases like 'send message to agent' and 'coordinate with other agents', which can match ordinary user requests and cause the skill to activate in more situations than intended. Because this skill enables network communication with other agents, accidental invocation expands the chance of unreviewed data sharing or interaction with untrusted peers.
The documentation states that a relay server forwards all messages to a monitoring dashboard, but it does not prominently emphasize that message contents may leave the local peer-to-peer context and be copied to a central observer. Users may assume local-only communication and inadvertently expose sensitive project details or operational metadata.
The wake-up feature causes incoming trusted-peer messages to trigger a full agent turn through the Gateway hook, creating automatic message-driven execution flow. Without a strong warning, users may enable this without understanding that external network input can now initiate agent activity and potentially influence behavior more directly.
L155 says 'Peers are never auto-approved — the user must explicitly trust each one', but the documented tool list includes udp_add_peer as 'Manually add and trust a peer' (L103). While user initiated trust is consistent, the absolute 'never auto-approved' phrasing contradicts the documented direct-trust flow and can mislead readers about actual trust behavior.
The skill accesses webhook credentials from config and environment without explicit disclosure to the user, which weakens informed consent around secret access. While this is less severe than direct exfiltration, it is still a security-quality issue because the skill's stated purpose does not obviously require reading such credentials.
Detected: suspicious.env_credential_access