Fix mCP server declaration resolves code at run time in Cursor

An MCP server is launched with `npx -y`, `uvx`, `bunx`, or a container image with no digest, or is reached over a remote transport. The code that gets a tool call today is not necessarily the code that got one yesterday, and there is no version in the repository to review.

medium likely Cursor CWE-1357 / ASI ASI04

The vulnerable pattern in Cursor

MEDIUM likely active MCP server declaration resolves code at run time ASI04 .cursor/mcp.json:4:18 2 │ "mcpServers": { 3 │ "gh": { 4 │ "command": "npx", │ ~~~~~ resolves the package when the server starts 5 │ "args": [ 6 │ "-y",

This finding comes from the Cursor fixture in the owlwarden test suite. `gh` resolves its package at run time with no version pinned, so today's code is whatever the registry serves. Whoever controls what that name resolves to controls a process holding tool access to this workspace.

The corrected configuration

Pin the version in `.cursor/mcp.json`, or point the entry at a binary from `devDependencies`. An unpinned entry means every teammate may be running a different server.

// .cursor/mcp.json
"args": ["-y", "@scope/mcp-server@1.4.2"]

If you are not using Cursor

Pin the version or the digest, and prefer a dependency in `devDependencies` over a run-time resolve. For a remote transport, state the trust decision in the config - a comment naming who runs the endpoint - rather than leaving it implicit.

Check your own repository

npx owlwarden scan
npx owlwarden explain agent-mcp-unpinned-remote

Runs on your machine. No account, no telemetry, no network unless you ask. In CI, SARIF uploads to code scanning and the exit code is the gate.

Other Cursor checks

Rules with a tested Cursor example.

agent-mcp-unpinned-remote for every agent host / All rules / owlwarden