T09 · Insecure Skill Coding Practices
- Location
SKILL.md:267- Finding
Plaintext Storage of Reusable Mailbox Authorization Codes
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 267–273 and 303–311
Vulnerability Type: Plaintext sensitive credential storage
Risk Level: MediumVulnerable Code
The general configuration example stores a reusable mailbox authorization code in a plaintext JSON field:
json { "email": "enterprise@163.com", "password": "your_auth_code", "imap_server": "imap.163.com", "imap_port": 993, "smtp_server": "smtp.163.com", "smtp_port": 465, "pro": {The multi-account setup explicitly instructs users to create another plaintext credential file:
bash mkdir -p ~/.config/email-163-tool/accounts cat > ~/.config/email-163-tool/accounts/finance.json << 'EOF' { "name": "财务部邮箱", "email": "finance@company.com", "password": "finance_auth_code" } EOF email-163-tool accounts listTechnical Analysis
The documented setup places reusable 163 mailbox authorization codes directly in JSON configuration files. The multi-account command writes such a file without setting restrictive permissions on either the account directory or the resulting file. Consequently, access depends on the user's umask and surrounding system configuration.
Although the document states elsewhere that encrypted storage is supported, the actionable setup instructions do not use a keychain, secret manager, environment-variable reference, or encrypted credential store. They also do not enforce owner-only permissions. Users following these instructions with real credentials may therefore leave mailbox secrets exposed to other local accounts, compromised processes running with filesystem access, insecure backups, support bundles, or accidental configuration-file disclosure.
Attack Path
- A user follows the documented multi-account setup.
- The user replaces
finance_auth_codewith a genuine reusable mailbox authorization code. - The shell writes that code in plaintext to
~/.config/email-163-tool/accounts/finance.json. - The file receives ...[truncated 1277 chars]
- Remediation
View remediation
Remediation Suggestions
- Store authorization codes in an operating-system keychain, enterprise secret manager, or encrypted credential store. Configuration files should contain only secret identifiers or runtime references.
- Prefer runtime secret injection through a protected mechanism rather than placing credentials directly in JSON.
- If file-based storage is unavoidable, create the directory and file with owner-only permissions:
bash install -d -m 700 ~/.config/email-163-tool/accounts umask 077 install -m 600 /dev/null ~/.config/email-163-tool/accounts/finance.json- Validate permissions before loading a credential file and refuse to proceed when it is group-readable or world-readable.
- Update examples to use an explicit placeholder such as
${EMAIL_163_AUTH_CODE}and clearly warn users never to commit or share populated configuration files. - Exclude credential files from version control, diagnostics, support bundles, logs, and unencrypted backups.
- Document authorization-code rotation and immediate revocation procedures for suspected exposure.
- Apply least privilege where the provider supports scoped or application-specific credentials, and use separate credentials for each mailbox.