T09 · Insecure Skill Coding Practices
- Location
store.js:15- Finding
Mailbox credentials and access tokens are stored in plaintext despite an encryption claim
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This email assistant is purpose-aligned, but it handles mailbox credentials and private email contents with materially under-disclosed and unsafe security controls.
Review before installing. This skill can read private email, store reusable mailbox and OAuth credentials, run a web admin UI, and send email contents to an external AI provider. Use only in a trusted local environment, prefer OAuth over app passwords, avoid custom IMAP servers until TLS validation is fixed, and do not rely on the current encrypted/local-only privacy claims.
store.js:15Mailbox credentials and access tokens are stored in plaintext despite an encryption claim
imap.js:61TLS certificate validation is disabled for every custom IMAP server
ai.js:8Email content and API credentials can be transmitted to an unrestricted AI endpoint
server.js:44Web mailbox API can be exposed over plaintext HTTP using a reusable URL bearer token
cli.js:245Mailbox passwords and API keys are accepted as command-line arguments
The public description frames the skill as a chat-based email assistant, but the documentation also exposes a standalone web UI, HTTP administration surface, persistent credential storage, and token-based access URL. This mismatch is security-relevant because reviewers and users may authorize the skill without realizing it opens an additional remotely reachable management interface and stores sensitive tokens.
The skill does not clearly warn users that email contents may be sent to an external AI service for summarization. Because email often contains highly sensitive personal or business information, omission of this disclosure undermines informed consent and can lead to unintended third-party data sharing.
The setup flow explicitly instructs users to provide email passwords or app passwords through chat. Collecting mailbox credentials in a chat-mediated workflow is highly dangerous because chat systems, bot logs, intermediaries, or compromised clients can capture reusable secrets that grant direct access to the user's email account.
The documentation claims all data stays local and is not uploaded, yet AI summarization necessarily sends email content to an external AI API. This is a direct privacy and trust violation: users may expose confidential emails under the false belief that no third party receives them.
The function sends full email-derived content, including sender, subject, and body, to a third-party AI endpoint configured by ai_api_base. In an email-assistant context this can expose sensitive personal, business, financial, or authentication-related content to an external processor without any visible consent, minimization, or trust restriction in this file, creating a significant privacy and data-governance risk.
The batch summarization path transmits snippets from multiple emails in one request to an external LLM API, amplifying the amount and variety of sensitive data disclosed in a single call. Because this skill is specifically designed to process inbox contents across providers and chat platforms, a compromise, misconfiguration, or untrusted API endpoint could expose a broad set of private communications at once.
The read command always summarizes the full message body, meaning simply reading an email causes its contents to be transmitted to the AI service automatically. In an email assistant context this is especially dangerous because it turns a basic viewing action into undisclosed third-party exfiltration of potentially highly sensitive correspondence.
Disabling TLS verification for custom IMAP connections without any user-facing disclosure removes an important security guarantee while giving users no indication their credentials and mailbox contents may be exposed to interception. Because this skill processes highly sensitive email data, the lack of warning increases the likelihood of unsafe use and silent compromise.
The lockfile pins ip-address 10.1.0, which the provided advisory data identifies as affected by parsing inconsistencies and an HTML-emitting XSS issue. In this email skill, the package is pulled in via socks and is likely not a primary UI surface, so exploitability depends on whether untrusted IP strings or rendered HTML output are exposed; however, keeping a known vulnerable transitive dependency is still a real supply-chain risk.
The lockfile includes nodemailer 8.0.2, and the referenced advisories indicate multiple known issues including header injection, denial of service in address parsing, and content resolution bypasses. This is especially concerning in an email assistant skill that processes and may generate email-related content across chat platforms, because untrusted message metadata, addresses, or attachments could flow into vulnerable mail-handling paths and enable spoofing, abuse of outbound mail generation, or service disruption.
The code stores plaintext account passwords directly in SQLite and returns full account rows through retrieval helpers, making credential disclosure trivial if the database file or process memory is accessed. Because this skill handles email accounts, exposed passwords may enable direct login to mailboxes and potentially other services where users reuse credentials.
Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.
<body>
<div class="container" id="app">
<!-- Login -->
<div id="login-view" class="login-box" style="display:none">
<h2>📧 Email Assistant</h2>
<p style="color:var(--text2);margin-bottom:20px">输入访问令牌登录</p>
The application accepts an access token through both a password field and, more critically, a URL query parameter via getToken()/init(). Tokens in URLs are commonly exposed through browser history, logs, screenshots, copied links, and Referer headers, making credential leakage much more likely in a chat-integrated email assistant.
<div id="login-view" class="login-box" style="display:none">
<h2>📧 Email Assistant</h2>
<p style="color:var(--text2);margin-bottom:20px">输入访问令牌登录</p>
<input type="password" id="login-token" placeholder="Access Token" onkeydown="if(event.key==='Enter')doLogin()">
<button class="btn btn-primary" style="width:100%" onclick="doLogin()">登录</button>
</div>
The skill declares no explicit tool scope or permission boundaries even though its documented behavior requires network access and likely reads configuration or environment-derived secrets. Missing scope declarations increase the chance that a host agent invokes the skill with broader privileges than users expect, weakening containment for a credential-handling email integration.
The skill instructions and reply-format guidance are written to operate in Chinese, including trigger phrases, setup flow, and output recommendations, but do not offer users a language choice. This can violate language/locale policy expectations when the skill is presented to multilingual users or integrated into non-Chinese chat environments.
The trigger phrases are broad enough to overlap with ordinary conversation, which can cause unintended invocation of a skill that accesses sensitive email data. In a chat environment, accidental activation can reveal inbox contents or start setup flows without clear user intent.
The prompt explicitly instructs the model to summarize emails in Chinese, and the batch prompt also requires Chinese output. This is a natural-language locale policy issue because the file imposes a specific language without any opt-in, configuration, or documented regional justification.
The batch prompt ends with an instruction to output in Chinese, with no indication that the user can choose another language. This creates a locale-policy concern because the skill hardcodes a language preference rather than offering a configurable or opt-in choice.
When --summarize is used, full email body content is sent to the summarization backend without any visible consent, warning, or data-classification check. Because emails routinely contain sensitive personal, financial, or corporate information, silent transfer to an external AI provider creates a real confidentiality and compliance risk.
Digest generation sends batches of email data to the AI summarizer without an obvious warning that message contents may leave the local environment. Batch processing can amplify exposure by transmitting many emails at once, increasing both privacy impact and regulatory risk.
The setup flow accepts direct email passwords/app passwords and persists them for later mailbox access. For a chat-integrated assistant, storing reusable mailbox credentials expands the blast radius of any compromise and is riskier than delegated OAuth, especially when users may provide secrets through chat or automation layers not designed for credential handling.
The remove command deletes a configured account immediately after receiving the email argument, with no confirmation or cautionary message. Removing stored account configuration can be irreversible from the user's perspective and should have some disclosure or confirmation.
The config command can return arbitrary stored configuration values by key, and the single-key read path does not mask sensitive entries. In a chat-facing email assistant, this creates a direct secret-disclosure primitive for items like API keys, OAuth client settings, or other stored credentials if an untrusted user can invoke the CLI through the agent.
The function accepts either an access token or password and uses it to connect to a mailbox, then fetches sender, recipient, subject, date, and body content from unread emails. This is sensitive account and message access, but this code includes no prompt, logging, or explanatory comment warning users that mailbox contents and credentials are being used.
For custom IMAP hosts, the code sets tls.rejectUnauthorized to false, which disables certificate validation and permits man-in-the-middle interception of email credentials and message contents. In an email assistant handling sensitive inbox data, this materially weakens transport security and expands trust to arbitrary, potentially spoofed servers.
No suspicious patterns detected.