T08 · Insecure Dependencies
- Location
SKILL.md:66- Finding
Unpinned and Inconsistent npm Packages Executed Through npx
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:10andSKILL.md:66-67
Vulnerability Type: Unpinned third-party executable dependency
Risk Level: MediumComplete Code Snippets:
yaml mcp_command: npx mcp-remote https://mcp.zu.lk/mcpjson { "mcpServers": { "zulk-url-shortener": { "command": "npx", "args": ["mcporter", "https://mcp.zu.lk/mcp"] } } }Technical Analysis
The Skill instructs users to launch an npm package through
npxwithout pinning an exact package version or verifying package integrity. Depending on the local npm configuration and cache,npxcan retrieve package code from the configured npm registry and execute it immediately.The package identity is also inconsistent: the metadata specifies
mcp-remote, while the stdio configuration example specifiesmcporter. The repository does not vendor, lock, or verify either package. Consequently, the locally executed code is not fully represented by the audited project and may change after this Skill has been reviewed.This creates a supply-chain risk if the selected package or one of its transitive dependencies is compromised, replaced, or publishes an unsafe update. The audit found no evidence that either named package is currently malicious; the vulnerability is the unsafe, mutable dependency execution mechanism.
Attack Path
- A user copies or activates the documented stdio MCP configuration.
- The MCP-compatible client starts
npx mcporter https://mcp.zu.lk/mcpor follows the metadata command usingmcp-remote. npxresolves the unpinned package from the user's configured npm registry, potentially downloading the latest available release.- A compromised or unexpectedly modified package, installation script, or transitive dependency executes on the user's machine.
- The package code runs with the operating-system privileges and environment access of the MCP clie ...[truncated 616 chars]
- Remediation
View remediation
Remediation Suggestions
- Select one verified MCP bridge package and use it consistently in both metadata and configuration examples.
- Pin the package to an exact reviewed version, such as
package-name@x.y.z, rather than allowingnpxto resolve a mutable latest release. - Prefer installing the dependency through a committed lockfile with npm integrity hashes and executing the locked local binary.
- Verify the package publisher, provenance, release signatures where available, and transitive dependency tree before recommending it.
- Disable or carefully review dependency lifecycle scripts where operationally feasible.
- Prefer the direct HTTPS MCP transport documented by the Skill when the client supports it, because that avoids executing an npm bridge locally.
- Document the dependency's trust boundary and advise users that stdio mode executes third-party code with their local account privileges.
