T09 · Insecure Skill Coding Practices
- Location
index.js:158- Finding
RFC 822 Header Injection Through Unvalidated Recipient Fields
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a disclosed Gmail/Maton email-sending skill, but it needs review because it can send account-linked email without a confirmation gate and has weak recipient-header validation.
Review this before installing if the Gmail account or MATON_API_KEY can send sensitive or business email. Use --test first, verify every recipient and Bcc value, avoid passing untrusted recipient strings, and install only if you are comfortable routing email contents through Maton/Gmail.
index.js:158RFC 822 Header Injection Through Unvalidated Recipient Fields
The documented behavior exceeds the declared purpose by reading local files, using API-key-based outbound delivery, and apparently supporting additional message behaviors not disclosed in the summary. Undeclared capabilities are dangerous because users and reviewers may approve the skill for formatting only while it also gains access to local content and sends it externally.
The documented behavior exceeds the declared purpose by reading local files, using API-key-based outbound delivery, and apparently supporting additional message behaviors not disclosed in the summary. Undeclared capabilities are dangerous because users and reviewers may approve the skill for formatting only while it also gains access to local content and sends it externally.
The trigger list includes very broad phrases such as 'send email' and '寄信', which can activate on ordinary user requests without clearly signaling that this subagent will apply transformations, read files, and use an authenticated mail connection. Broad activation increases the chance of unintended invocation and unauthorized or surprising outbound data transmission.
The trigger description further expands activation to ambiguous requests like '幫我寄信', '寄給...', and formatting-related phrases, without defining clear boundaries for when the skill should only format versus when it should actually transmit email. In a mail-sending context, ambiguity is particularly risky because accidental activation can lead to data exfiltration or unintended communications from the user's account.
The skill metadata says it uses the current logged-in Gmail connection, but the implementation actually retrieves a MATON_API_KEY and sends mail through an external gateway. This creates a trust-boundary mismatch: users may believe mail is sent only via their local authenticated Gmail context, while message content and recipient data are transmitted to a third-party service under separate credentials.
The README promotes automatic sending through Gmail and an API gateway, but it does not clearly warn users that recipient addresses, subjects, and message bodies will be transmitted to external services. In an agent setting, this can cause unintentional disclosure of sensitive content because users may assume formatting-only behavior while the skill also performs outbound delivery using the current logged-in connection.
The skill describes access to environment variables and outbound network use to send email, but it does not declare any explicit tool scope such as permissions or allowed-tools. In an agent ecosystem, this weakens least-privilege boundaries and can let a broadly-triggered skill access secrets or make requests without clear operator visibility.
The skill description and operational instructions are presented as a fixed Chinese-language policy experience, and the file does not offer users a language or locale choice. For a general email-sending skill, this can violate language/locale policy expectations unless the locale restriction is explicit and justified.
The manifest description is written entirely in Chinese and presents the skill as a policy manager that automatically applies formatting behaviors, but it does not indicate any user language choice or opt-in. Under the stated policy, forcing a specific language or locale without user choice is a natural-language policy violation.
The skill metadata requires a MATON_API_KEY even though the stated functionality is email formatting and sending via the user's current Gmail connection. This creates an unjustified secret dependency that could enable unnecessary access to an external service, secret harvesting, or covert data exfiltration, especially because users would be prompted to provide a credential unrelated to the advertised behavior.
The top-level documentation presents the feature as RFC 822 formatting, but the generated message includes a literal Bcc header. In actual sent email construction, Bcc recipients are typically handled at transport/envelope level rather than exposed in message headers, so the documented implication of standards-compliant formatting conflicts with what the code emits.
The top-level description is written as an automatic policy application and specifies Chinese-language/Taiwan-oriented formatting behavior, including UTF-8 and newsletter formatting, without indicating that users can choose another language or locale. This is reinforced elsewhere by hard-coded zh-TW date formatting, making the skill's natural-language behavior locale-specific by default rather than opt-in.
The skill hard-codes toLocaleDateString('zh-TW', ...) for newsletter output, which forces a specific locale in generated user-facing text. There is no visible option allowing the user to select a different language or locale, so this conflicts with the language/locale policy requirement.
This skill reads a sensitive bearer credential from MATON_API_KEY even though its stated purpose is email formatting/policy application. Pulling in an unrelated high-privilege secret expands the blast radius: if the skill is invoked unexpectedly or modified later, it can use that credential to send or route data externally without the user's informed expectation.
The natural-language instructions and examples are presented exclusively in Traditional Chinese, and the README does not indicate that other languages are supported or that the language choice is intentional and optional. Under the language/locale policy, forcing a specific language without user opt-in can be a policy concern.
The single short trigger '寄信' is prone to matching many ordinary conversational requests and can invoke a privileged email-related skill too easily. On its own this is a lower-severity issue, but in combination with outbound network access and account-linked sending it contributes to accidental activation risk.
SQP-3 applies to all file types and covers natural-language policy violations such as forcing a specific language without user opt-in. This document presents all user-facing instructions and content in Traditional Chinese, with no indication that the skill is region-specific or that alternative languages are available.
The function formats dates with the explicit 'zh-TW' locale and also provides default Chinese-language editor/footer strings. This imposes a specific language/locale in the skill behavior with no opt-in or configurable language choice shown in the file.
The file is primarily written in Traditional Chinese, but line L10 uses the Simplified Chinese term "上线" instead of the Traditional form. This imposes a locale/script choice inconsistency without offering the user a language preference or documenting a reason for the variant.