T08 · Insecure Dependencies
- Location
SKILL.md:100- Finding
Unpinned npm Packages Executed Automatically by MCP Configuration
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 100–110
Vulnerability Type: Unpinned third-party dependency execution
Risk Level: Mediumjson { "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"] }, "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "ghp_xxx" } } } }Technical Analysis
The example invokes two npm packages through
npx -ywithout pinning exact package versions or enforcing package integrity. The-yoption suppresses the installation confirmation, while the absence of version constraints allows npm registry resolution to select package code at execution time.If a package release, maintainer account, registry response, or transitive dependency is compromised, users who copy this configuration could execute attacker-controlled code under their local account. The effective executable may change after the Skill has been reviewed because the executable packages are not included in the audited project.
The
ghp_xxxvalue is a placeholder and is not an exposed credential. Nevertheless, the GitHub MCP process would receive any real token substituted by the user, and the filesystem process would receive access to the configured directory.Attack Path
- A user copies the documented MCP configuration into
.cursor/mcp.json. - The user replaces the placeholder path or token with operational values.
- Cursor launches the configured server using
npx -y. - npm resolves and, when necessary, downloads the unpinned package and its dependency tree.
- A compromised resolved package executes with the privileges of the Cursor user.
- The malicious process accesses files under the configured filesystem path or reads the GitHub token supplied to its environment.
- It may then modify accessible files, misuse the token within its grante ...[truncated 591 chars]
- A user copies the documented MCP configuration into
- Remediation
View remediation
Remediation Suggestions
- Pin every MCP package to an exact, reviewed version rather than relying on registry-selected versions.
- Install approved dependencies explicitly and retain a lockfile with integrity hashes where the deployment model permits it.
- Avoid
npx -yfor security-sensitive integrations; require an explicit review or approval step before installation and first execution. - Verify package provenance, maintainers, release signatures or attestations, and integrity before deployment.
- Prefer a controlled internal registry or allowlisted artifact repository for MCP server packages.
- Run MCP servers in a sandbox or container with restricted filesystem and network permissions.
- Replace
/path/to/dirwith the narrowest required directory rather than a home directory or project collection. - Use a dedicated, short-lived GitHub token with only the minimum repository and operation scopes required.
- Keep secrets outside committed configuration files and inject them through an approved secret-management mechanism.
- Periodically re-review pinned updates and monitor package advisories before upgrading.
