T01 · Skill Instruction Hijacking
- Location
scripts/check_email.sh:102- Finding
Untrusted Email Content Can Hijack a Privileged Agent
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This mail skill needs Review because unread emails can trigger persistent memory writes, cross-channel outreach, queued outbound email, and a send-script code-injection risk.
Install only after reviewing the scripts and adding approval gates. At minimum, disable automatic memory writes from inbound email, require explicit confirmation before notifications or sends, fix the unquoted heredoc in email_send.sh, protect ~/.config/lel-mail with owner-only permissions, and avoid storing reusable mail passwords in plaintext when a safer secret store is available.
scripts/check_email.sh:102Untrusted Email Content Can Hijack a Privileged Agent
scripts/check_email.sh:158Remote Email Can Poison Persistent Agent Memory
scripts/email_send.sh:114Email Fields Can Inject Arbitrary Python Code
scripts/email_send.sh:161Email Credentials and Queued Messages Lack Enforced Restrictive Permissions
scripts/email_sender_daemon.sh:54Unknown Queue Sender Can Terminate the Email Sender Daemon
This inverse mismatch finding is also security-relevant because the skill description advertises sensitive capabilities that may not be present in the reviewed chunk, making the true trust boundary unclear. Such inconsistency can mislead operators into granting permissions or deploying automation under false assumptions about what is implemented and audited.
This inverse mismatch finding is also security-relevant because the skill description advertises sensitive capabilities that may not be present in the reviewed chunk, making the true trust boundary unclear. Such inconsistency can mislead operators into granting permissions or deploying automation under false assumptions about what is implemented and audited.
Unread email contents are forwarded to an external agent process for classification without user-facing disclosure or consent. Because email often contains sensitive or confidential data, this creates a clear privacy and data-handling risk, especially when the agent backend may log, retain, or further process the content.
The script automatically asks an agent to create or modify memory files based on model interpretation of untrusted email content. This enables prompt-injected or misleading messages to poison persistent memory, alter future agent behavior, and retain sensitive data without review.
The script gives a general-purpose agent authority to act on email content by modifying memory files, contacting the user through arbitrary channels, and initiating follow-up actions. This breaks containment for an email-processing utility and allows untrusted email text to trigger broad side effects through an LLM, creating a prompt-injection-to-action path.
The prompt explicitly instructs the agent to log email-derived information into MEMORY.md or shared files, which can persist sensitive personal, financial, or confidential information far beyond the original email context. In this skill context, that is more dangerous because arbitrary senders can influence what gets retained in the agent's long-term memory.
The script can cause unsolicited outbound contact based on email-derived summaries and even direct the agent to proceed through any available or new channel. This creates an externally triggerable communication primitive that can leak sensitive information, spam the user, or be abused for social-engineering workflows.
The script tells the agent to contact the user through any existing or newly created channel with a summary derived from email content. That broad dissemination path can expose sensitive message details outside the original medium and increases the blast radius of both accidental disclosure and adversarially crafted emails.
The response workflow directs the agent to relay email-derived needs and then send email afterward, effectively turning inbound content into a trigger for multi-channel disclosure and action. Because the data originates from untrusted email, this creates a strong risk of sensitive-data propagation and manipulation of subsequent communications.
The skill exposes broad capabilities including shell, file access, environment access, and network use, but does not declare any explicit tool scope or permission boundaries. For an email-handling skill that can read messages, queue outbound mail, and modify local state, this lack of scoping increases the chance of unintended data access, command execution, or misuse by the agent beyond the user's expectations.
The skill explicitly states that it can write to memory based on received email and act on those messages later, creating persistent influence from untrusted external input. This is dangerous because malicious or misleading emails can poison memory, shape future agent decisions, and propagate sensitive or false information across sessions.
---
name: lel-mail
description: Send and read email via a combination of python and bash scripts which makes use of the main agent for reasoning and logic. This skill enables the agent to write to memory based on contents in the email and to reach out to the user either to notify them of happenings or to request inputs to respond. This skill also contains a python script to read and manage the email queue containing functionality to list pending outgoing emails and delete emails before they can be sent out. Please note that this skill enables the agent to act upon received emails by adding to agent memory and sending responses
metadata: {"clawdbot":{"emoji":"📧","requires":{"bins":["python3"]}}}
---
The skill handles highly sensitive data by reading email and writing derived content into agent memory, but the documentation does not present a clear privacy warning or consent model. Email often contains credentials, personal data, financial details, and confidential business content, so silent ingestion into persistent memory can cause significant privacy and retention risks.
The documentation recommends bypassing cloud-provider email restrictions using Tailscale, which introduces an additional tunneling channel unrelated to the core email feature. Guidance to evade provider controls can weaken network governance, create shadow connectivity, and expand the attack surface in environments where outbound email is intentionally blocked.
The skill queues emails for automatic sending after a delay, enabling autonomous external communication without a just-in-time confirmation step. In the context of an agent that may reason over incoming content and act on it, delayed autonomous sending raises the risk of data exfiltration, phishing-like behavior, or unauthorized messaging if prompts, memory, or queue contents are manipulated.
3. Run the following command ```~/.openclaw/workspace/skills/lel-mail/scripts/check_email.sh <USER_EMAIL>```
### Send Email
# Note, this script does not send the data directly but sends it to a scheduler which will automatically send it in approximately 5.5 minutes
1. Make sure you have the necessary data to send the email from the user, that includes sender, recipient and body, everything else is optional
2. Run the following command ```~/.openclaw/workspace/skills/lel-mail/scripts/email_send.sh --sender <sender> --recipient <recipient> --subject <subject> --body <body> [--cc ...] [--bcc ...]``` Note: if using BCC/CC note that CC/BCC are comma-separated lists
The queue management documentation includes deletion of pending emails without a clear warning that the action is destructive and may be irreversible. In an agentic workflow, this can lead to accidental loss of queued communications, denial of intended notifications, or silent interruption of business processes.
The safety-oriented header is misleading because the actual prompts authorize broad actions, including file creation, memory updates, and cross-channel contact. Misstated safety guarantees increase operational risk by causing reviewers or operators to underestimate the script's real capabilities.
The code loads auth.user and auth.password from the mail config and immediately uses them to authenticate. There is no user-facing disclosure, confirmation, or warning in this file that the skill accesses stored credentials to connect to the mailbox.
The skill context is especially dangerous because incoming email is untrusted external input, yet the script lets that input drive workspace memory manipulation and outreach beyond the stated role of checking email. That creates an authority expansion where a message sender can indirectly influence local state and communications outside the email channel.
Persisting email-derived information into user or shared MEMORY.md files creates long-lived state that can influence future agent decisions and expose historical sensitive data. In an email-ingestion context, this is risky because untrusted external messages can directly shape persistent memory without validation.
memory_to_add = llm_response_data.get("payload")
prompt_for_agent = f"""
You are to write in the corresponding MEMORY.md file(s) for the user with the email: {user} however if it is a general non-specific event or piece of information it is ok to write it in the general MEMORY.md or other shared files
Before writing to said file, make sure the directory and file exist and create them if necessary. If you can't determine which user in your memory banks this is, start asking questions to clarify.
The following information needs to be logged: {memory_to_add}
The script persists full email metadata and content, including sender, recipient, subject, body, CC, and BCC, to a local JSON queue file under the user's home directory without any notice, consent prompt, retention policy, or permission hardening visible in the script. In the context of a mail skill that can act on received emails and write to memory, silently storing potentially sensitive communications on disk increases the risk of privacy leakage, forensic exposure, and unintended access by other local processes or users.
This daemon sends queued emails automatically with no user-facing confirmation, approval gate, or audit checkpoint at send time. In the context of a skill that can act on received emails, write to memory, and send responses, this creates a real risk of unauthorized, accidental, or prompt-induced outbound communication using stored credentials.
No suspicious patterns detected.