T09 · Insecure Skill Coding Practices
- Location
SKILL.md:233- Finding
Persistent Plaintext Storage of Mailbox Authorization Code
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 233-254
Vulnerability Type: Plaintext sensitive credential storage
Risk Level: MediumVulnerable Documentation Snippet
markdown A: The default path is `~/.config/email-163-com/config.json`. It contains `email`, `password` (authorization code), `imap_server` (`imap.163.com`), `imap_port` (993), `smtp_server` (`smtp.163.com`), and `smtp_port` (465). The environment variables `EMAIL_163_USER` and `EMAIL_163_PASS` may be used instead. It is recommended to execute `chmod 600 config.json` to set file permissions. - The configuration file stores the authorization code in plaintext and requires the user to set file permissions to mode 600 manually.Technical Analysis
The Skill documentation instructs users to persist a reusable 163 Mail authorization code in the
passwordfield of a plaintext JSON file. File mode0600restricts access by other local accounts, but it does not encrypt the credential or protect it from processes running under the mailbox owner's account. It also relies on the user to apply the restriction manually, creating a risk that the file may initially or permanently retain broader permissions.A local process operating with the user's privileges can read the authorization code directly. The credential may also be exposed through unencrypted backups, copied home directories, diagnostic archives, accidental publication, or improperly configured synchronization and version-control workflows.
No executable implementation is included in the audited project, so configuration creation behavior, permission enforcement, secret redaction, and credential lifecycle controls cannot be verified.
Attack Path
- A user follows the documented configuration procedure.
- The user writes the mailbox address and reusable authorization code to
~/.config/email-163-com/config.json. - The user omits
chmod 600, applies it in ...[truncated 1199 chars]
- Remediation
View remediation
Remediation Suggestions
- Store authorization codes in an operating-system credential manager, platform secret store, or agent-managed encrypted vault rather than a plaintext JSON file.
- Prefer secret references in the configuration file so that the file contains only non-sensitive settings.
- If environment variables are supported, warn that they can be inherited by child processes and may be exposed through process diagnostics; use a dedicated secret-injection facility where available.
- If file-based storage is unavoidable, create the credential file atomically with mode
0600from the outset rather than asking the user to correct permissions afterward. - Refuse to use credential files that are owned by another account, are symbolic links, or have group or world permissions.
- Exclude credential files from version control, cloud synchronization, backups, logs, crash reports, and support archives.
- Redact authorization codes from command output, errors, telemetry, and debug logs.
- Document credential rotation and revocation procedures, and instruct users to revoke the authorization code immediately after suspected disclosure.
- Add automated tests verifying restrictive file creation, permission validation, secret redaction, and safe failure behavior.
