T09 · Insecure Skill Coding Practices
- Location
scripts/receive_mail.py:136- Finding
Attachment Filename Path Traversal Allows Arbitrary File Overwrite
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
Emailbox is a disclosed email tool, but attachment downloads can write outside the chosen folder and scheduled emails are stored in plaintext, so it needs careful review before use.
Install only if you are comfortable giving the skill access to an email account and sending message content, attachments, and downloaded mailbox data through your provider. Avoid downloading attachments from untrusted senders until filenames are sanitized, and treat scheduled emails in ~/.emailbox/queue as sensitive plaintext that should be protected and cleaned up.
scripts/receive_mail.py:136Attachment Filename Path Traversal Allows Arbitrary File Overwrite
scripts/schedule_mail.py:39Scheduled Email Contents Are Persisted in Plaintext Without Enforced Private Permissions
声明描述的是“收发与数据处理一体化工具”,核心能力包括发送与接收邮件、搜索、定时发送、HTML 模板、附件、转发和数据集成。实际代码仅是 receive_mail.py,功能集中在 IMAP 收信侧:登录邮箱、列出邮件、读取正文、搜索、识别并保存附件,以及在 --forward 模式下打印原邮件的转发元信息。代码中虽包含 SMTP 服务器配置字段,但没有任何 SMTP 连接、发信、计划任务、模板渲染或外部数据联动逻辑。因此,代码行为只覆盖声明中的一部分接收类功能,且缺失多项被重点宣称的能力。没有发现明显超出声明范围的敏感未声明能力,但描述显著高估了该代码块的实际功能范围,因此应判定为不匹配。
The declared description presents a broad all-in-one email platform covering send/receive/search/schedule, multi-provider IMAP/SMTP support, templates, attachments, forwarding, and data integration. However, the supplied code chunk is narrowly focused on scheduled sending workflow management. It parses scheduling arguments, writes queued email jobs to ~/.emailbox/queue as JSON, lists/cancels queued jobs, and when due, calls send_mail.py via subprocess to send messages. It supports attachment and forwarding-related metadata as pass-through fields, but it does not itself implement SMTP/IMAP connectivity, inbox retrieval, message search, or document/data integration. There is no evidence of undeclared harmful behavior; the issue is that the description materially overstates the capabilities represented by this specific code chunk.
The declared description presents a broader all-in-one email system covering both IMAP and SMTP workflows, including receiving, searching, scheduling, and data integration. The supplied code only implements SMTP sending functionality. It does not contain IMAP logic, inbox retrieval, message search, scheduling, or broader data-linking behavior. The implemented features that do align are sending mail, HTML content, attachments, reply/forward formatting, and multi-provider SMTP configuration. Because the declared purpose materially overstates the capabilities actually present in this code chunk, this is a description-behavior mismatch.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
export EMAIL_ADDRESS="your@qq.com"
export EMAIL_AUTH="your_auth_code"
# Option B: Keychain / secret manager
# macOS: Use `security add-internet-password`
# Linux: Use `secret-tool store` (libsecret)
# Windows: Use Windows Credential Manager
Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.
def setup_system_scheduler(schedule_id, scheduled_time, schedule_file):
"""Print instructions for the user to manually set up scheduling.
This function does NOT modify crontab or system scheduler automatically.
Users must explicitly confirm and add any entries themselves.
The skill declares broad operational capabilities involving environment variables, filesystem access, shell commands, and networked email actions, but provides no explicit tool-scope or permission boundaries. In an agent setting, this increases the risk of over-privileged execution, especially because the documented workflows include reading local files, writing queue data, and transmitting email content and attachments externally.
The document first warns against storing credentials in plaintext files, but then offers a workflow that places email credentials in ~/.emailbox/credentials and sources them later. Even with mode 600, this creates a recoverable plaintext secret on disk, increasing exposure through backups, endpoint compromise, malware, accidental inclusion in archives, or misuse by later processes.
The documented creation of ~/.emailbox/credentials establishes persistent storage of sensitive authentication material. Persistence makes compromise more likely because secrets remain available across sessions, may be swept into backups, and can be exfiltrated by local malware or other tooling long after the immediate task completes.
# Windows: Use Windows Credential Manager
# Option C: Restricted file (if persistent config is required)
# Create a file with restricted permissions that only you can read:
mkdir -p ~/.emailbox && touch ~/.emailbox/credentials
chmod 600 ~/.emailbox/credentials
# Then add your credentials:
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
# Option C: Restricted file (if persistent config is required)
# Create a file with restricted permissions that only you can read:
mkdir -p ~/.emailbox && touch ~/.emailbox/credentials
chmod 600 ~/.emailbox/credentials
# Then add your credentials:
# EMAIL_ADDRESS=your@qq.com
# EMAIL_AUTH=your_auth_code
The crontab guidance establishes persistent automated execution of the queue processor, which can cause unattended outbound email activity and persistent access to queued content. In an agent/security context, persistence mechanisms increase risk because they outlive the immediate user session and can continue transmitting data if misconfigured or abused.
# Step 1: Check your current crontab first
crontab -l > ~/crontab_backup.txt
# Step 2: Add the emailbox processor manually (review before adding!)
# Add this line to your crontab ONLY if you want auto-processing:
The privacy guidance suggests avoiding plaintext storage, yet scheduled sending persists queued email data under ~/.emailbox/queue/. Depending on implementation, that queue may contain message bodies, recipient addresses, subjects, and possibly attachment metadata or paths, leaving sensitive outbound content at rest on disk and potentially exposed to local compromise or backups.
The file is primarily written in Chinese and presents the workflow instructions in Chinese without indicating that users may interact in other languages. Under the policy, forcing a specific language without user opt-in can be a natural-language policy violation unless the locale restriction is explicitly justified.
The documentation directs users to place email addresses and authorization codes/app passwords in environment variables, but does not warn that these values are sensitive secrets. In many setups, export commands can be captured in shell history, exposed to other local processes, inherited by child processes, or leaked through CI logs and shared terminal sessions, which could allow attackers to send/read email as the user.
This markdown file includes operational instructions to save completed email bodies to a local file and then send them with a command-line mail script. Because the templates cover business reports, invoices, meeting details, and formal letters that may contain sensitive organizational or personal data, the documentation should include a user-facing warning about reviewing recipients/content and handling local files carefully.
This code saves email attachments to a local directory using mkdir and file writes, but the function itself provides no warning comment, prompt, or other disclosure that it will modify the filesystem. Although the CLI implies downloading attachments, the safety-relevant local write behavior is not explicitly disclosed near the operation.
The function accesses authentication material from environment variables such as EMAIL_AUTH and provider-specific auth variables, but there is no comment, docstring, or user-facing disclosure that sensitive credentials will be read from the environment. Accessing credentials is safety-relevant and should be clearly disclosed to users.
The scheduler stores full email metadata and content, including message body and potentially recipient lists or attachment references, in plaintext JSON under the user's home directory. In an email-handling skill, this creates a real confidentiality risk because sensitive business or personal email contents may persist on disk longer than users expect and may be readable by other local processes or backups.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
"1. Manual processing:\n"
f" {python_path} {schedule_script} --process-queue\n\n"
"2. Add to crontab manually (review before adding!):\n"
f" crontab -l > ~/crontab_backup.txt\n"
f" crontab -e\n"
f" # Add this line:\n"
f" * * * * * {python_path} {schedule_script} --process-queue\n\n"
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
f" {python_path} {schedule_script} --process-queue\n\n"
"2. Add to crontab manually (review before adding!):\n"
f" crontab -l > ~/crontab_backup.txt\n"
f" crontab -e\n"
f" # Add this line:\n"
f" * * * * * {python_path} {schedule_script} --process-queue\n\n"
"3. Use --process-queue in your own automation pipeline."
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
f" {python_path} {schedule_script} --process-queue\n\n"
"2. Add to crontab manually (review before adding!):\n"
f" crontab -l > ~/crontab_backup.txt\n"
f" crontab -e\n"
f" # Add this line:\n"
f" * * * * * {python_path} {schedule_script} --process-queue\n\n"
"3. Use --process-queue in your own automation pipeline."
When processing queued mail, the script writes plaintext body and HTML content into temporary sidecar files next to the queue entry and does not remove them afterward. This expands the persistence window of sensitive content and may leave recoverable artifacts on disk beyond the scheduled message record itself.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
for att in email_data["attach"]:
send_args.append(str(att))
result = subprocess.run(send_args, capture_output=True, text=True)
if result.returncode == 0:
info["status"] = "sent"
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
for att in email_data["attach"]:
send_args.append(str(att))
result = subprocess.run(send_args, capture_output=True, text=True)
if result.returncode == 0:
info["status"] = "sent"
subprocess.run(send_args, ...) triggers actual email delivery through send_mail.py, which will transmit stored message data to an email provider. While sending is part of the tool's purpose, the queue-processing path lacks a direct user-facing disclosure that invoking --process-queue or --process-one performs live outbound delivery immediately.
This code performs a network operation that transmits user-provided message content, recipient lists, and any attached files, but there is no confirmation prompt immediately before sending. The success/failure prints occur only after the transmission attempt, so users are not warned at the point of the safety-relevant action.