T09 · Insecure Skill Coding Practices
- Location
scripts/send_email.py:287- Finding
SMTP Credentials Exposed Through Command-Line Arguments
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This email-sending skill is mostly aligned with its purpose, but it handles email account secrets and a hardcoded default sender in ways users should review carefully before installing.
Install only if you are comfortable giving the agent SMTP credentials and letting it send emails and attachments externally. Prefer a user-owned, narrowly scoped app password or SMTP token entered through a secure secret mechanism, avoid the built-in default sender account, do not use `--no-tls`, and review recipients, attachments, and content before confirming any send.
scripts/send_email.py:287SMTP Credentials Exposed Through Command-Line Arguments
scripts/send_email.py:299Plaintext SMTP Authentication Can Be Explicitly Enabled
requirements.txt:1Third-Party Dependency Is Installed Without Version or Integrity Pinning
The skill explicitly tells the agent to solicit credentials for a built-in default sender account. This is dangerous because it normalizes secret collection in chat and may facilitate unauthorized use of a shared or non-user-owned mailbox, especially given the adversarial risk of hardcoded operational identities in skills.
The examples repeatedly instruct users to paste passwords, app passwords, and SMTP secrets directly into chat. In most agent systems, chat is not an appropriate secret-entry channel because prompts, transcripts, telemetry, or logs may retain those credentials and expose downstream accounts.
The example conversation demonstrates asking the user for the authorization code of the default agent mailbox, which directly trains the agent to collect and handle mailbox secrets in chat. Examples are operational guidance; here they reinforce insecure behavior and make accidental credential exfiltration more likely.
This second example repeats the insecure pattern of requesting the authorization code for the default sender after gathering content. Repetition across examples increases the likelihood the behavior is implemented consistently and exposes users to credential theft or misuse at scale.
The skill advertises capabilities that can read local files for attachments/templates but does not declare any tool scope or permissions boundaries. In an agent environment, this weakens reviewability and can enable unintended file access when the skill is invoked with user-supplied paths.
The skill omits a clear warning that email content and attachments are transmitted to external SMTP providers and recipients. Users may unknowingly send sensitive local files or confidential data outside the current system boundary.
The documentation directs the agent to default to a built-in sender address and then ask the user for credentials for that mailbox, implying operation of an account the user may not control. This can lead to credential harvesting, unauthorized account use, or users being tricked into supplying secrets for a third-party mailbox.
The instruction to automatically choose a sender identity without asking the user creates unauthorized autonomous decision-making for an externally visible action. In this context, the autonomy is more dangerous because it combines with a hardcoded mailbox and can cause emails to be sent from an unexpected identity or pressure users into providing credentials for that identity.
**IMPORTANT - Default Sender Email Behavior**:
**If the user does NOT specify a sender email in their initial request, AUTOMATICALLY use `agent_skill_test@126.com` as the default sender. DO NOT ask the user which email to send from.**
Only ask the user for a different sender email if they explicitly mention wanting to use their own email address.
The skill instructs collection of highly sensitive passwords, app passwords, API keys, and authorization codes without warning users about the sensitivity of those secrets or safer handling practices. In a chat-based agent context, prompting users to paste credentials directly is especially dangerous because transcripts may be logged, retained, or exposed to other components.
Earlier guidance says that if the user does not specify a sender email, the skill must automatically use agent_skill_test@126.com and must not ask which email to send from. In Example 1, the user omits the sender, but the skill asks for a sender email anyway, directly conflicting with the documented interaction policy.
Examples 2 and 3 switch the assistant's interaction entirely into Chinese, but the document does not state that language selection is user-driven or optional. This can violate language/locale policy when a skill implicitly forces a language rather than explicitly matching or offering the user's preference.
The dependency is specified as markdown>=3.4.0, which allows any newer release to be installed and makes builds non-reproducible. This increases supply-chain risk and can silently pull in vulnerable or incompatible versions over time, especially relevant in a skill that may process untrusted email/template content.
# Email sending dependencies
markdown>=3.4.0
The manifest references markdown without pinning to a specific version, while known advisories exist for some releases. Because the installed version is unconstrained above 3.4.0, the environment may resolve to an affected release, which is more concerning here because markdown processing in an email-sending skill could be exposed to untrusted template or message content and trigger denial-of-service or parsing issues.
No suspicious patterns detected.