T09 · Insecure Skill Coding Practices
- Location
scripts/send_email.py:16- Finding
SMTP Authentication Failure Silently Downgrades to Unauthenticated Delivery
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This email skill mostly does what it says, but it also creates mail accounts via Docker and handles passwords and authentication in ways that need review before installation.
Install only in a controlled mail-admin environment. Treat it as an email administration skill, not just a send/read helper: it needs mailbox passwords, can read inbox metadata, can send mail, and can create persistent accounts through Docker. Prefer revising it to prompt securely for passwords, fail closed on SMTP authentication errors, separate account creation into an admin-only workflow, and correct the metadata before use.
scripts/send_email.py:16SMTP Authentication Failure Silently Downgrades to Unauthenticated Delivery
scripts/send_email.py:27Mailbox Passwords Are Exposed Through Command-Line and Process Arguments
_meta.json:7Metadata Incorrectly Declares That No Credentials or Docker Dependency Are Required
The top-level description says the skill is for sending and receiving mail, but the documentation also includes creating new email accounts, which is a more privileged administrative action. Hiding or omitting account-management capability increases the risk of misuse because users may invoke a seemingly routine mail skill without realizing it can provision identities on the mail system.
The top-level description says the skill is for sending and receiving mail, but the documentation also includes creating new email accounts, which is a more privileged administrative action. Hiding or omitting account-management capability increases the risk of misuse because users may invoke a seemingly routine mail skill without realizing it can provision identities on the mail system.
The top-level description says the skill is for sending and receiving mail, but the documentation also includes creating new email accounts, which is a more privileged administrative action. Hiding or omitting account-management capability increases the risk of misuse because users may invoke a seemingly routine mail skill without realizing it can provision identities on the mail system.
The skill documents use of Python scripts for sending, reading, and creating email accounts, which clearly implies shell execution and network access, but the manifest does not declare any tool scope or permissions. This weakens containment and review because operators cannot easily see that the skill can perform external communications and account-management actions.
The manifest/description frames the skill as mail sending/receiving, but the documentation instructs users to create new email accounts. This is a sensitive identity-management action that changes system state and can be abused for persistence, impersonation, or unauthorized service access if not clearly disclosed and controlled.
The example shows a password directly on the command line, which can leak through shell history, process listings, terminal logs, and audit systems. Because this skill deals with mail credentials, exposure could let an attacker send mail as the user, read mailbox contents, or reuse the password elsewhere if it is shared.
The IMAP example also places plaintext credentials on the command line, creating the same exposure through process arguments, shell history, and logging. In this case the impact includes unauthorized mailbox access and disclosure of potentially sensitive email contents.
The account-creation instructions describe a sensitive administrative operation without warning about authorization, audit, naming policy, or downstream security consequences. In context, creating mailbox accounts can enable unauthorized identities, persistence, spam abuse, or accidental creation of weakly protected accounts.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
def create_email(user: str, password: str):
"""在 DMS 容器内创建邮箱账号。user 格式: name@domain.com"""
result = subprocess.run(
['docker', 'exec', 'mailserver', 'setup', 'email', 'add', user, password],
capture_output=True, timeout=30
)
This code logs into an IMAP server and reads messages from the inbox, which is a privacy-sensitive operation involving user data. Although the script prints message metadata after retrieval, there is no prior warning, confirmation, or explicit disclosure in the code that it will access mailbox contents when run.
The module docstring at L02 states the script can be run directly as-is. However, the argument check at L27 only rejects fewer than 5 argv entries, while the code unconditionally reads sys.argv[5] at L34, which requires 6 argv entries including the program name. Invoking it per the documented usage can therefore raise an IndexError instead of working directly.
The script connects with plain SMTP and attempts authentication without requiring TLS, so credentials and message contents may be exposed if the connection is not protected. More seriously, if authentication fails it silently falls back to unauthenticated sending, which can cause mail to be transmitted insecurely or through a misconfigured trusted relay without the user's knowledge.
The natural-language instructions are written as a fixed Chinese-only workflow, including support guidance to contact '小爪子', with no indication that another language is supported or that the locale restriction is intentional. This can violate language/locale policy when no user opt-in or justification is provided.
The module docstring is written only in Chinese and states the script should be executed directly, with no alternative language or opt-in. This can violate language/locale policy when a skill forces a specific language without documented justification or user choice.
The module docstring is written in Chinese and instructs direct execution, and the CLI usage/output strings are also Chinese-only. This imposes a specific language on users without opt-in or explanation, which matches the locale-policy violation criteria.
The command-line help and success output are presented only in Chinese, with no mechanism for user language selection. This is a natural-language policy concern because it forces a locale choice rather than offering or documenting it.
No suspicious patterns detected.