T03 · Remote Payload Retrieval and Execution
- Location
scripts/tokenmail_cli.js:10- Finding
Automatic Retrieval and Execution of Unverified Remote JavaScript
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill performs its stated email purpose, but it handles private identity keys and runtime code loading in ways users should review carefully before installing.
Review before installing. Use only throwaway TokenMail-specific keys, do not reuse valuable wallet credentials, avoid workflows that print or pass secrets in command arguments, install a local reviewed ethers dependency instead of using the CDN fallback, and assume message contents and metadata are sent to the configured TokenMail API and may be plaintext unless separately encrypted.
scripts/tokenmail_cli.js:10Automatic Retrieval and Execution of Unverified Remote JavaScript
scripts/tokenmail_cli.js:166Mnemonic Phrases and Private Keys Stored in Unencrypted Files
scripts/tokenmail_cli.js:278Reusable Private Credentials Exposed Through Standard Output and Documented Logging Workflows
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
Referenced artifact was not completely inspected
- Use `scripts/tokenmail_cli.js` as the primary entry
The read-only fallback explicitly instructs the agent to auto-generate a temporary private key and continue, then tell the user to save it. Generating and operationally using secret key material without an upfront security gate encourages insecure key lifecycle handling, especially in sandboxed or logged environments where the key may be exposed through process history, transcripts, or monitoring.
The documentation tells the agent to print a generated private key in plain output, which is a direct secret disclosure pattern. In agent systems, stdout, chat transcripts, shell history, logs, and telemetry are often retained, so revealing a private key can immediately compromise the associated identity and any messages or actions tied to it.
The skill advertises capabilities that involve environment-variable access and network communication, but it declares no explicit tool scope or permissions boundary. In an agent ecosystem, this increases the chance that the skill is invoked with broader-than-expected authority and performs external communication or secret access without clear user/operator awareness.
The skill is positioned for external email sending and includes temporary key workflows, but it does not present a prominent user-facing warning about privacy, message delivery to third parties, key exposure risk, and account/identity consequences. This can cause users or downstream agents to send sensitive data externally or handle cryptographic material unsafely without informed consent.
The API reference explicitly allows messages to be sent and retrieved with encrypted: false, but it does not prominently warn users that payload contents may traverse the service and be returned in plaintext. In an AI-agent email system, this creates a realistic risk that developers will treat the channel as confidential by default and transmit sensitive prompts, credentials, reports, or attachments without end-to-end protection.
The phrase 'Read-only + no key' actively contradicts the described action of generating a private key and then sending mail. Sending email is not read-only behavior, so this wording misrepresents the operation's effect and intent.
The heading says 'Read-only sandbox with no key: auto-generate and send,' yet the commands create new key material and perform an outbound send. That is an active, state-changing workflow, so the documentation contradicts the actual behavior shown.
The examples instruct users to generate a private key and then print it directly to the terminal with 'Save this private key offline now', which creates a real secret exposure risk through shell history, terminal scrollback, logs, session recording, and shared sandbox telemetry. In a skill meant for AI-agent and sandbox usage, this is especially dangerous because secrets may be captured by orchestration systems, transcripts, or other tooling outside the user's control.
If the local ethers module is unavailable, the CLI fetches JavaScript from a remote CDN and executes it via vm.runInNewContext. Because this library handles wallet creation and signing, a compromised CDN, manipulated URL environment variable, or MITM in a weak trust environment could execute attacker-controlled code and exfiltrate private keys or alter signatures.
The usage text presents the tool as 'sandbox-friendly' with 'no mandatory local file writes', but the default behavior for create/ensure/import/alias/export/delete uses a keystore under the user's home directory and writes or removes files. While writes can be avoided for some workflows using direct key arguments, the implementation still performs substantial local file persistence as a normal operating mode.
This is not just incomplete documentation: the help text advertises 'No local file writes' as an operating mode tip, yet the program's standard agent-management commands persist secrets to disk under ~/.tokenmail and export can write arbitrary output files. The wording creates a misleading impression of broadly write-free behavior that contradicts actual default command behavior.
The help text softens a dangerous behavior: 'auto-loads ethers from CDN in memory' actually means downloading and executing remote code. In this skill context, that code runs in the same process that handles seed phrases and private keys, so misleading messaging increases the chance operators will unknowingly accept a severe supply-chain risk.
The keystore writes mnemonic or private key material in plaintext JSON under the user's home directory without encryption or an explicit interactive confirmation at the write site. In a sandbox or multi-user environment, filesystem exposure, backups, or accidental sharing could disclose long-lived wallet secrets and enable account takeover.
This POST sends recipient address, subject, body, and optional HTML content to the configured remote service. The command output confirms success after sending, but there is no prior disclosure in this command path that message contents will be transmitted to an external API endpoint.
The skill manifest frames the tool as an email communication CLI, but the code reconstructs a wallet from a mnemonic and reveals blockchain identity material such as addresses and public keys. While signing may support TokenMail, direct wallet/account derivation and export is a stronger capability than the stated purpose makes clear.
The manifest describes an email communication skill implemented via a Node.js CLI, which makes sending and retrieving messages expected. However, this file also exposes additional identity-management capabilities such as publishing blockchain public keys and registering aliases, which are materially broader than basic email communication as described.
Detected: suspicious.env_credential_access, suspicious.exposed_secret_literal, suspicious.secret_argv_exposure