T08 · Insecure Dependencies
Error
- Location
- SKILL.md:8
- Finding
- Unpinned Third-Party Packages Execute with Exchange Credentials## Vulnerability Details **File Location**: `SKILL.md:8-12` and `SKILL.md:123-137` **Vulnerability Type**: Unpinned npm dependencies and unsafe supply-chain execution **Risk Level**: High ### Vulnerable Code ```yaml install: - kind: node package: "@3rd-eye-labs/openmm" bins: [openmm] ``` ```json { "mcpServers": { "openmm": { "command": "npx", "args": ["@qbtlabs/openmm-mcp"], "env": { "MEXC_API_KEY": "your_key", "MEXC_SECRET": "your_secret", "KRAKEN_API_KEY": "your_key", "KRAKEN_SECRET": "your_secret" } } } } ``` ### Technical Analysis The Skill instructs the environment to install `@3rd-eye-labs/openmm` without an exact version. It separately invokes `@qbtlabs/openmm-mcp` through `npx`, also without an exact version. Consequently, the package versions executed may change after the Skill has been reviewed. The MCP package is additionally launched with exchange API credentials in its environment. Code executed by that package can read all supplied environment variables. No malicious package content is present in the audited project, but the configuration creates a supply-chain trust boundary in which a compromised publisher account, malicious future release, registry compromise, or package ownership transfer could convert the dependency into a credential-stealing or unauthorized-trading payload. The differing package scopes also increase the need to verify that both dependencies are intentional, authentic components maintained by trusted publishers. ### Attack Path 1. An attacker compromises the npm publisher, package repository, release process, or another relevant supply-chain component. 2. The attacker publishes a malicious version under one of the referenced package names. 3. A user installs the unpinned OpenMM package or starts the MCP server using `npx`. 4. The package manager resolves and executes the a ...[truncated 1031 chars]
- Remediation
- ## Remediation Suggestions 1. Pin both npm dependencies to reviewed, exact versions rather than relying on the latest matching release. 2. Use a lockfile with verified integrity hashes and enforce immutable or reproducible installation behavior. 3. Avoid ad hoc `npx` resolution for credential-bearing services. Install a reviewed version explicitly and invoke its fixed local path. 4. Verify the ownership, source repository, release provenance, and maintenance status of both npm package scopes. 5. Review package contents, lifecycle scripts, transitive dependencies, and network behavior before providing exchange credentials. 6. Use npm provenance or signed release verification where available. 7. Run the MCP service as an isolated, unprivileged account or container with restricted filesystem and network access. 8. Supply only the credentials required for the selected exchange and avoid inheriting unrelated environment variables. 9. Use exchange API keys with no withdrawal or transfer rights, strict IP allowlisting, minimal trading permissions, and low account exposure. 10. Initially validate integrations with testnet or dedicated low-value accounts and rotate credentials after any suspected dependency compromise.
