send-email

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:50 AM UTC
• Version: 1.0.1

Overview

The skill appears to send email as advertised, but it can transmit arbitrary attachments with stored SMTP credentials and lacks important confirmation and TLS safeguards.

Review this before installing if the agent may handle sensitive files or email content. Use a limited SMTP app password, restrict who the agent may email, require user confirmation for recipients and attachments, and update the script to use a verifying TLS context before trusting it with valuable mail credentials.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: send_email.py:59

Finding

SMTP TLS connections do not explicitly enforce certificate verification

Content

View full analysis

Vulnerability Details

File Location: send_email.py, lines 59–64
Vulnerability Type: Improper TLS certificate validation
Risk Level: Medium

python

        # 连接SMTP服务器并发送
        if USE_TLS:
            server = smtplib.SMTP(SMTP_SERVER, SMTP_PORT)
            server.starttls()
        else:
            server = smtplib.SMTP_SSL(SMTP_SERVER, SMTP_PORT)

Technical Analysis

Both SMTP connection modes rely on the Python runtime's implicit SSL context. The implementation does not create an explicitly certificate-verifying SSLContext or pass one to SMTP_SSL and starttls.

Because the resulting certificate-validation behavior can depend on the Python version and runtime configuration, the code does not reliably guarantee that the SMTP endpoint's certificate and hostname will be authenticated before credentials are submitted. The connection also lacks an explicit timeout.

Attack Path

1. An attacker gains a position capable of manipulating DNS resolution or intercepting traffic between the host and the configured SMTP server.
2. The attacker redirects the SMTP connection to a fraudulent endpoint.
3. In a runtime where the implicit context does not adequately validate the certificate and hostname, the connection succeeds.
4. The script calls server.login(SENDER_EMAIL, AUTHORIZATION_CODE).
5. The fraudulent endpoint receives the SMTP account identifier and authorization code. Email content and attachments sent through that connection may also be disclosed.

Impact Assessment

Successful exploitation does not directly grant local operating-system privileges. It can disclose the configured SMTP credentials, potentially allowing the attacker to send email as the compromised account within the provider's authorization scope. Message bodies, recipient addresses, subjects, and attached local files may also be exposed in transit.

Remediation

View remediation

Remediation Suggestions

Create a certificate-verifying context with ssl.create_default_context() and use it for both connection modes:

python

import ssl

tls_context = ssl.create_default_context()

if USE_TLS:
    server = smtplib.SMTP(SMTP_SERVER, SMTP_PORT, timeout=30)
    server.ehlo()
    server.starttls(context=tls_context)
    server.ehlo()
else:
    server = smtplib.SMTP_SSL(
        SMTP_SERVER,
        SMTP_PORT,
        timeout=30,
        context=tls_context,
    )

Do not disable hostname checks or use an unverified SSL context. Require TLS before authentication, reject plaintext SMTP configurations, add a finite network timeout, and use a context manager or finally block to ensure the connection is closed on failure.

T09 · Insecure Skill Coding Practices

Note

• Location: send_email.sh:20

Finding

Email header injection through unvalidated shell-script arguments

Content

View full analysis

Vulnerability Details

File Location: send_email.sh, lines 20–27
Vulnerability Type: Email header injection
Risk Level: Low

bash

{
    echo "To: $TO"
    echo "Subject: $SUBJECT"
    echo "Content-Type: text/plain; charset=UTF-8"
    echo ""
    echo "$BODY"
} > "$TMP_MAIL"

Technical Analysis

The shell implementation inserts caller-controlled TO and SUBJECT values directly into RFC 5322 message headers without rejecting carriage-return or newline characters. A value containing embedded line breaks can therefore terminate the intended header and introduce additional headers or modify the message structure.

The variables are shell-quoted, so this code does not establish shell-command injection. The vulnerability is confined to construction of the email message. In addition, because msmtp is invoked with an explicit envelope recipient rather than recipient extraction mode, an injected Bcc header is not guaranteed to add an envelope recipient. Header forgery and MIME-structure manipulation remain possible.

Attack Path

1. An attacker or untrusted caller obtains control over the recipient or subject argument passed to send_email.sh.
2. The attacker supplies a value containing a newline followed by a forged header, such as a modified Reply-To, Content-Type, or other message metadata.
3. The script writes the injected line into the temporary message without validation.
4. msmtp or mutt processes the attacker-modified message.
5. If the selected mail client accepts the malformed structure, the delivered message contains forged headers or attacker-controlled MIME interpretation.

Impact Assessment

Exploitation does not provide local command execution or additional operating-system privileges. It may allow a caller to forge email metadata, create misleading reply behavior, alter content interpretation, or evade assumptions made by downstream mail processing. The practi ...[truncated 95 chars]

Remediation

View remediation

Remediation Suggestions

Remove send_email.sh if it is obsolete, because the documented Skill workflow uses send_email.py and explicitly states that ~/.msmtprc is not used.

If the shell implementation must remain:

1. Reject carriage-return and newline characters in every header-derived argument.
2. Validate recipient addresses with a dedicated email-address parser.
3. Avoid manually assembling RFC 5322 messages with echo.
4. Generate messages through Python's structured email.message.EmailMessage API.
5. Keep envelope recipients separate from message headers.
6. Fail closed when an attachment path is supplied but invalid, rather than silently sending a message without the requested attachment.

At minimum, apply explicit validation before creating the message:

bash

case "$TO$SUBJECT" in
    *$'\r'*|*$'\n'*)
        echo "Invalid newline in email header input" >&2
        exit 1
        ;;
esac

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (7)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The README describes a skill that sends message bodies and optional attachments to external SMTP infrastructure using stored credentials, but it does not warn users that potentially sensitive data will leave the local environment. In an agent setting, this omission increases the chance of inadvertent data exfiltration, especially if the agent is asked to email reports, logs, or files without the operator appreciating the privacy and security implications.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 89% confidence

Finding

The skill declares and relies on injected environment variables containing SMTP credentials, but it does not explicitly declare tool scope or permissions. This weakens security transparency and policy enforcement because an agent may access secret-bearing env at runtime without a clear manifest-level declaration or restriction.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 80% confidence

Finding

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.

Content

Scanner excerpt · SKILL.md (reported line 40)May include surrounding context.

Agent instructions

1. Credentials: Never read config files. OpenClaw injects skills.entries.send-email.env when the script runs — do not use the read tool on ~/.openclaw/openclaw.json or workspace/openclaw.json (exposes secrets). If the skill is enabled, assume env is configured; do not ask the user for passwords. Do not use ~/.msmtprc.
2. Send mail: Run the script under workspace (do not use the path under node_modules):

   bash

   python3 ~/.openclaw/workspace/skills/send-email/send_email.py "recipient" "Subject" "Body"
   

Description-Behavior Mismatch

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The skill description says it sends email via SMTP, but the implementation also reads an arbitrary local path and attaches that file to the outgoing message. In an agent-skill context, this creates a data exfiltration primitive: any caller able to influence the attachment path can cause local files to be sent off-host, which is more dangerous than ordinary email sending because it expands capability from messaging to filesystem access and transmission.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 89% confidence

Finding

The script will send arbitrary body content and optional attachments immediately once invoked, with no disclosure prompt, preview, or confirmation step. In a skill ecosystem, this makes accidental or induced exfiltration easier because sensitive text or files can be transmitted externally without a meaningful guardrail at the point of send.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The script's docstring, CLI usage text, and status/error messages are written only in Chinese. Under the policy, hard-coding a specific language without opt-in or clear justification is a natural-language policy issue.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

This shell script includes its descriptive comments and runtime usage/error messages only in Chinese, which imposes a specific language on users without any opt-in or explanation of a region-specific requirement. The policy for this review flags language or locale constraints when they are forced rather than optional or justified.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.