T08 · Insecure Dependencies
- Location
SKILL.md:43- Finding
Unpinned Third-Party npm Package Is Downloaded and Executed Automatically
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 43–52
Vulnerability Type: Unpinned and automatically executed third-party dependency
Risk Level: Mediumjson { "mcpServers": { "n2-stitch": { "command": "npx", "args": ["-y", "n2-stitch-mcp"] } } }Technical Analysis
The documented MCP configuration invokes
npxwith the package namen2-stitch-mcpbut does not specify an exact version or package integrity hash. The-yoption suppresses confirmation, allowing npm to retrieve and execute the registry-selected package automatically.Consequently, the code executed when the MCP server starts can differ from the code that was originally reviewed. The submitted artifact contains only documentation and metadata; it does not include the package implementation, a dependency lockfile, or integrity information that would permit verification of the downloaded executable.
This creates a supply-chain trust boundary around the npm registry, the package publisher account, and future releases of the package.
Attack Path
- An attacker compromises the npm publisher account, the package publication workflow, or another relevant supply-chain component.
- The attacker publishes a malicious release under the existing
n2-stitch-mcppackage name. - A user starts an MCP host configured according to the documented example.
npx -y n2-stitch-mcpresolves and downloads the unpinned package without requesting confirmation.- The malicious package executes with the operating-system privileges and environment inherited from the MCP host.
- The payload can access resources available to that user and may read credentials exposed to the process, potentially including the documented
STITCH_API_KEY.
Impact Assessment
Successful exploitation could result in arbitrary code execution with the privileges of the user running the MCP host. The reachable scope may in ...[truncated 316 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the command to an exact, reviewed package version, for example
n2-stitch-mcp@1.0.0, rather than allowing npm to select a changing release. - Prefer installing dependencies through a committed lockfile and using a reproducible installation mechanism such as
npm ci. - Verify package integrity through lockfile integrity hashes, signed provenance, and trusted publication workflows.
- Avoid
npx -yfor security-sensitive automatic startup unless the resolved artifact has already been installed and verified. - Bundle or vendor auditable implementation source with the skill where practical.
- Run the MCP server under a dedicated, least-privileged account or sandbox with narrowly restricted filesystem and network access.
- Provide the process only the credentials it requires. Use narrowly scoped, revocable secrets rather than exposing unrelated environment variables.
- Document the reviewed package version and establish a controlled process for auditing and approving upgrades.
- Pin the command to an exact, reviewed package version, for example
