forgex-cli

• Outcome: Review
• Latest audit: Sep 12, 2026 · 3:55 AM UTC
• Version: 1.0.3

Overview

The skill is a coherent wallet and trading CLI guide, but it asks users to install unaudited executable code and handle wallet secrets in risky ways that could expose funds.

Review this carefully before installing. Only use it if you trust the forgex-cli npm package and can verify the exact version/source. Do not paste real private keys or passwords into shell commands or agent chats, avoid plaintext wallet CSV exports, use dry runs first, and keep any wallet backups encrypted and outside cloud sync or source control.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Error

• Location: SKILL.md:38
• Finding: Unpinned Global Installation of Unverifiable Third-Party Executable Code<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 38–40 **Vulnerability Type**: Unsafe and unpinned third-party package installation **Risk Level**: High ### Vulnerable Code ```bash npm install -g forgex-cli ``` ### Technical Analysis The Skill directs users to globally install `forgex-cli` from the npm registry without specifying an exact version, package integrity hash, lockfile, or verified source revision. The project contains only `SKILL.md`; therefore, the package implementation and its dependency graph cannot be audited from the supplied artifact. An npm package can execute lifecycle scripts during installation. Global installation also places executable files in a shared command location. Because the installed CLI is subsequently entrusted with wallet passwords, private keys, signing operations, and fund transfers, compromise of either the package or one of its dependencies would create a direct path to credential and asset theft. This finding does not establish that the current npm package is malicious. It identifies a supply-chain boundary that the Skill leaves mutable and unverifiable. ### Attack Path 1. An attacker compromises the `forgex-cli` npm publisher account, package, or transitive dependency, or publishes a malicious future release. 2. The user runs the documented unpinned global installation command. 3. npm resolves the mutable package name to the compromised release. 4. Malicious lifecycle code may execute during installation with the invoking user's privileges, or malicious CLI code executes when `forgex` is invoked. 5. The installed CLI receives wallet credentials and transaction instructions during normal use. 6. The malicious implementation can read those secrets, alter transaction destinations, sign unauthorized transactions, or transmit sensitive material externally. ### Impact Assessment Code supplied by the package can execute with the operating-system privileges of the user who invokes npm or the CLI ...[truncated 278 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Include the CLI source code and dependency manifests in the auditable project. 2. Pin an exact package version rather than resolving the latest mutable release. 3. Verify npm integrity metadata and publish reproducible build instructions. 4. Commit and enforce a dependency lockfile for development or local installation. 5. Avoid global installation; use a project-local dependency or a verified, version-pinned execution mechanism. 6. Disable unnecessary npm lifecycle scripts during installation where operationally possible. 7. Audit the package and all transitive dependencies before allowing access to wallet keys. 8. Run the CLI in a sandbox with restricted filesystem and network access. 9. Require signed releases and document the expected package publisher, source repository, release hash, and verification procedure. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:118
• Finding: Wallet Credentials and API Secrets Passed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 118–121, 141–143, 179–188, and 198–206 **Vulnerability Type**: Sensitive information exposure through process arguments and shell history **Risk Level**: High ### Vulnerable Code ```bash Commands involving private keys require `--password` before the subcommand name: forgex --password "your-password" <command> [subcommand] [options] ``` ```bash # Set Codex API key for market data forgex config set codexApiKey "your-api-key" ``` ```bash # Generate new wallets (max 100 per group) forgex --password "pwd" wallet generate --group 1 --count 10 # Add an existing wallet by private key forgex --password "pwd" wallet add --group 1 --private-key "Base58Key..." --note "main wallet" # Remove a wallet from group forgex --password "pwd" wallet remove --group 1 --address "WalletAddress..." # Import from CSV (format: privateKey,note) forgex --password "pwd" wallet import --group 1 --file ./wallets.csv ``` ```bash # Export all groups as encrypted JSON forgex --password "pwd" wallet export-group \ --file ./all-groups.json \ --encrypt \ --password "file-encryption-password" # Import all groups from JSON backup forgex --password "pwd" wallet import-group \ --file ./all-groups.json \ --password "file-encryption-password" ``` ### Technical Analysis The documented interface places wallet passwords, raw private keys, API keys, and backup-encryption passwords directly in command-line arguments. Command arguments are not an appropriate secret transport mechanism because they may be exposed through: - Shell history files. - Process-listing and process-inspection interfaces. - Terminal session recording. - Debugging and observability tools. - Agent transcripts and command logs. - Wrapper scripts, audit logs, or error reports. The raw `--private-key` argument is particularly sensitive because possession of a Solana private key generally enables transaction signing without needing the accompanying ...[truncated 1686 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove all password, API-key, and private-key values from command-line arguments. 2. Read passwords and private keys from a hidden interactive prompt attached directly to the terminal. 3. Support secret input through standard input or a dedicated file descriptor that is not included in process arguments. 4. Integrate with an operating-system keychain, hardware wallet, or managed secret store. 5. For automation, accept references to permission-restricted secret files rather than literal secret values. 6. Mask secrets in logs, telemetry, errors, command previews, and agent transcripts. 7. Prevent sensitive commands from being persisted in shell history and document how users can remove previously recorded commands. 8. Use separate credentials for wallet storage and backup encryption so disclosure of one does not automatically compromise the other. 9. Prefer hardware-backed transaction signing so raw private keys never enter the CLI process. 10. Add explicit warnings that credentials must not be pasted into commands, scripts, chat messages, or terminal sessions that may be recorded. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:187
• Finding: Plaintext Export of Wallet Private-Key Material to CSV<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 187–195 **Vulnerability Type**: Plaintext storage of wallet private keys **Risk Level**: High ### Vulnerable Code ```bash # Import from CSV (format: privateKey,note) forgex --password "pwd" wallet import --group 1 --file ./wallets.csv ``` ```bash # Export group as CSV forgex --password "pwd" wallet export --group 1 --file ./backup.csv ``` ### Technical Analysis The documented CSV import format explicitly contains `privateKey,note`. The adjacent wallet-group export example writes a backup to `./backup.csv` without an encryption option or any documented file-permission controls. In this wallet-management context, the export is therefore reasonably expected to contain sensitive wallet material, potentially including private keys. A plaintext CSV file does not provide confidentiality or integrity protection. It can be exposed through ordinary filesystem reads, cloud synchronization, workstation backups, source-control commits, archive creation, malware, or accidental sharing. Default file-creation permissions may also permit access by other local users depending on the environment and active `umask`. Using a password to unlock the source wallet store does not protect the exported file after it has been written. ### Attack Path 1. A user runs the documented `wallet export` command. 2. Wallet material is written to `./backup.csv` without documented encryption. 3. The file is synchronized to cloud storage, included in a repository or backup, copied to another device, or read by another local process or user. 4. An attacker obtains the CSV file and extracts the private keys. 5. The attacker imports those keys into another wallet implementation. 6. The attacker signs valid transactions and transfers assets from the affected accounts. ### Impact Assessment Disclosure of exported private keys can grant full signing authority over every wallet represented in the CSV. The scope can extend to a ...[truncated 242 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove plaintext private-key export functionality, or require authenticated encryption for every export. 2. Use a modern authenticated-encryption construction with a memory-hard password-based key derivation function. 3. Generate exported files with owner-only permissions and fail safely if restrictive permissions cannot be guaranteed. 4. Store exports outside source repositories, shared directories, cloud-synchronized folders, and general-purpose temporary directories. 5. Clearly identify backups as highly sensitive and require explicit confirmation before export. 6. Prefer hardware wallets, seed custody systems, or encrypted keystores that do not expose raw private keys. 7. Add integrity and format-version metadata to encrypted backups. 8. Provide secure backup-rotation and deletion guidance, while noting that deletion may not remove copies from snapshots, synchronization services, or solid-state storage. 9. Add repository ignore rules for wallet CSV and backup filenames as defense in depth. 10. Document an incident-response procedure for immediate key rotation and fund migration if an export is exposed. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The skill repeatedly instructs users to pass wallet passwords and private keys directly on the command line, including examples like `--password` and `--private-key`. Command-line arguments are commonly exposed through shell history, process listings, logging, terminal scrollback, and orchestration telemetry, which can lead to wallet compromise and theft of on-chain funds.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The backup and export examples show writing wallet groups and CSV/JSON backups containing highly sensitive wallet material to local files, but do not clearly warn that these files may contain private keys and must be encrypted, access-restricted, and handled as secrets. If stored insecurely, copied into cloud sync folders, committed to repositories, or left with weak permissions, an attacker can recover wallet credentials and drain assets.

Static analysis

No suspicious patterns detected.