T09 · Insecure Skill Coding Practices
- Location
references/deployment.md:10- Finding
Wallet Private Key Exposed Through Command-Line Arguments
- Content
View full analysis
\ --private-key $PRIVATE_KEY \ --create \ # Or use forge create forge create --rpc-url \ --private-key $PRIVATE_KEY \ src/Contract.sol:ContractName \ --constructor-args ``` ### Technical Analysis The deployment guide instructs users to supply a wallet private key through the `--private-key` command-line option. The shell expands `$PRIVATE_KEY` before launching `cast` or `forge`, placing the actual secret in the child process's argument vector. Depending on operating-system controls and the execution environment, expanded process arguments may be observable through process-monitoring interfaces, diagnostic utilities, endpoint monitoring, command tracing, CI/CD logs, crash reports, or wrapper scripts. Shell tracing such as `set -x` can also print the expanded key. Although the shell history would ordinarily store the variable reference rather than its value in this exact example, copied commands containing literal keys and automated logging can further increase exposure. This handling exceeds the minimum privilege necessary for deployment because Foundry supports safer signer mechanisms that do not require exposing raw private-key material in process arguments. It also weakens the statement in the guide that Pentagonal never handles private keys: the service may not receive them, but the prescribed local workflow uses an unnecessarily observable secret channel. ### Attack Path 1. A user stores a funded deployment wallet key in `PRIVATE_KEY`. 2. The user follows the documented `cast send` or `forge create` command. 3. The shell expands `$PRIVATE_KEY` and passes the resulting secret as a command-line argument. 4. A l ...[truncated 1262 chars]- Remediation
View remediation
\ --account deployer \ --create \ ``` 3. Prefer hardware wallets, isolated signing services, or supported remote signers for production deployments. 4. Require interactive secret entry where a keystore cannot be used, ensuring that input is not echoed or placed in process arguments. 5. Add an explicit warning that users must not paste private keys into commands, source files, environment files committed to version control, CI variables exposed to untrusted jobs, or chat prompts. 6. Configure CI/CD deployments around protected secret stores and isolated signers. Prevent command tracing and redact sensitive output. 7. Use a dedicated deployment account with only the funds and roles required for the deployment. Transfer long-term administrative authority to a multisignature wallet or governance mechanism afterward. 8. Rotate any private key previously used through observable command-line arguments and migrate its funds and administrative roles to a new secure account. ]]>
