T08 · Insecure Dependencies
- Location
SKILL.md:75- Finding
Unpinned Third-Party MCP Package Executes with Access to a Wallet Private Key
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 75–83
Vulnerability Type: Unpinned third-party dependency with access to sensitive credentials
Risk Level: HighVulnerable Code:
json { "mcpServers": { "a2a": { "command": "npx", "args": ["-y", "@poisonpyf/a2a-mcp"], "env": { "A2A_NETWORK": "shasta", "A2A_PRIVATE_KEY": "your-tron-private-key" } } } }Technical Analysis
The configuration uses
npx -yto download and execute@poisonpyf/a2a-mcpwithout specifying an exact version or verifying an integrity digest. Consequently, the code executed can change after this Skill has been reviewed. The-yoption also suppresses the normal installation confirmation.The downloaded MCP server is explicitly provided
A2A_PRIVATE_KEYthrough its process environment. It therefore has direct access to a credential capable of signing TRON transactions. The external package's implementation is not included in this project, so the audit cannot verify whether it securely handles the key, avoids logging it, restricts transaction signing, or prevents transmission to external systems.This is a supply-chain weakness rather than proof that the named package is malicious. A compromised npm maintainer account, malicious future release, registry compromise, or dependency takeover could turn the documented setup into arbitrary third-party code execution with wallet access.
Attack Path
- An attacker compromises the npm package, its maintainer account, or a transitive dependency and publishes a malicious release.
- A user applies the documented configuration and starts the MCP server.
npx -y @poisonpyf/a2a-mcpresolves and executes the unpinned release without an interactive confirmation.- The malicious process reads
A2A_PRIVATE_KEYfrom its environment. - It exfiltrates the private key, signs unauthorized transactions, or e ...[truncated 934 chars]
- Remediation
View remediation
Remediation Suggestions
-
Pin the MCP package to an exact, reviewed version instead of resolving the latest release:
json "args": ["-y", "@poisonpyf/a2a-mcp@0.1.0"]The version shown is illustrative and must be replaced with a release that has actually undergone security review.
-
Use a lockfile and verify package integrity, npm provenance, publisher identity, and release signatures where available. Re-review the package and its transitive dependencies before every upgrade.
-
Prefer installing the reviewed dependency during a controlled deployment phase rather than downloading executable code dynamically whenever the MCP server starts.
-
Do not expose a long-lived, high-value wallet private key directly to a third-party process. Use an isolated signer, hardware-backed key, delegated session key, or restricted wallet that enforces spending limits, destination allowlists, network restrictions, and explicit approval for transactions.
-
Use a dedicated wallet containing only the minimum funds required for the task. Keep testnet and mainnet credentials strictly separated and rotate the key immediately if compromise is suspected.
-
Run the MCP server inside a sandbox or container under a dedicated unprivileged account. Restrict filesystem access, outbound network connectivity, environment variables, and operating-system permissions to the minimum required.
-
Review or vendor the package source so its handling of private keys, logging, telemetry, transaction authorization, and network communication can be independently verified.
-
