T08 · Insecure Dependencies
- Location
SKILL.md:6- Finding
Mutable npm Dependency Executed During Wallet and Trading Operations
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 6-13
Vulnerability Type: Unpinned third-party executable dependency
Risk Level: HighVulnerable Code
yaml allowed-tools: ["Bash(npx awal@latest status*)", "Bash(npx awal@latest trade *)", "Bash(npx awal@latest balance*)"]bash npx awal@latest statusThe same mutable
awal@latestpackage reference is used throughout the file for wallet status, balance, and token-trading commands.Technical Analysis
The skill executes the third-party
awalnpm package throughnpxusing the mutablelatestdistribution tag. No exact package version, cryptographic integrity value, lockfile, or locally reviewable implementation is provided.Because npm distribution tags can be changed after this skill has been audited, the code executed by these commands may differ from the code that existed during review. A compromise of the package publisher, npm account, package dependencies, or publishing pipeline could cause subsequent skill invocations to download and run attacker-controlled code.
This is particularly sensitive because the dependency is used for authenticated wallet operations and token swaps. The skill itself contains no evidence of credential harvesting, transaction-address substitution, persistence, or other directly malicious behavior; the risk arises from trusting a mutable executable dependency in a financial context.
Attack Path
- An attacker compromises the
awalpackage publisher, its npm credentials, or a transitive dependency and publishes a malicious release. - The malicious release is assigned to the npm
latesttag. - A user invokes the skill to check wallet status, inspect a balance, or trade tokens.
- The agent executes an allowed command such as
npx awal@latest statusornpx awal@latest trade .... npxresolves and executes the attacker-controlled package release.- The malicious package runs w ...[truncated 914 chars]
- An attacker compromises the
- Remediation
View remediation
Remediation Suggestions
- Replace every
awal@latestreference with an exact, security-reviewed version, such asawal@X.Y.Z. - Manage the CLI as a declared project dependency using a lockfile rather than downloading a mutable release at invocation time.
- Enforce package integrity verification through the package manager lockfile, verified registry metadata, and trusted package provenance.
- Review the pinned package and its transitive dependencies before each upgrade. Do not automatically advance to new releases.
- Run the CLI in a restricted environment with only the filesystem, network, environment-variable, and wallet permissions required for the requested operation.
- Require explicit user confirmation immediately before transaction submission. The confirmation should show the source and destination token addresses, exact amount, network, slippage, recipient, expected output, and relevant fees.
- Where supported, separate read-only wallet status and balance operations from transaction-signing capabilities.
- Restrict outbound network access to documented and trusted registry, RPC, and API endpoints, and log package versions and transaction parameters for security review.
- Replace every