Skip to content

Account: Restoring sign-in...

MCP VULNERABILITIES

MCP Vulnerabilities: Known Cases and Adoption Checks

An MCP vulnerability can let data or operations cross an intended boundary. Before connecting, identify the implementation, deployed release, permissions, and reachable operations together.

Sources reviewed:

What it can do, and which boundary failed

File writes and command execution can be intended server capabilities. The official trust model does not treat launching a configured stdio command as a vulnerability by itself. Distinguish a required capability, an unintended boundary crossing, and missing evidence to choose the appropriate response.

Observed conditionAction before connecting
Required capability with broad permissionsEnforce a dedicated account, necessary folders, and allowed destinations through the OS or connected service. Verify that out-of-scope operations are denied.
A defect crosses a configured boundaryMatch the official advisory to the deployed release. Stop the affected operation, install a fixed artifact, and verify that access outside the boundary is denied.
Implementation or inspection evidence is missingGather the missing provenance, authorization conditions, or version evidence before connecting business data to a boundary you cannot evaluate.
Official MCP security policy and trust model

Implementation defects in official advisories

These cases concern particular implementations and releases. They do not establish that every current MCP server has the same defect.

@modelcontextprotocol/server-filesystem

Filesystem: symlinks reach beyond an allowed directory

A symlink inside an allowed directory could reach unintended files. Both the requested path and the physical destination resolved by the OS matter.

GHSA-q66q-fx2p-7w4m · 2025-07-01Read the case analysis

mcp-server-git (pip)

Git: a reference becomes a command option

Inputs to git_diff and git_checkout could be interpreted as Git options and overwrite local files. The official advisory identifies versions before 2025.12.18 as affected and 2025.12.18 as patched.

GHSA-9xwc-hfwc-8w59 · 2025-12-17Read the case analysis

Four checks for your own deployment

  1. 1

    Match the artifact

    Record the exact package, publisher, launch command, and deployed version. A similar server name does not establish that an advisory applies.

  2. 2

    Establish reachability

    Identify the enabled tools, input sources, execution location, and network exposure. Merely configuring a connection differs from permitting an affected operation.

  3. 3

    Map the reachable resources

    Record files the runtime account can read, data it can change, credentials it receives, and network destinations it can contact.

  4. 4

    Verify the fix and controls

    Restart the updated artifact and use harmless test data to confirm that required operations work while out-of-scope operations are denied.

Questions about vulnerabilities and inspections

Is every MCP command-execution capability a vulnerability?

No. Launching a configured stdio server is an intended MCP feature. Identify the specific boundary failure, such as execution beyond granted authority, misinterpreted input, or an authorization bypass.

Does RESTRICT mean a known vulnerability exists?

Not necessarily. RESTRICT can also reflect high-risk behavior or permissions. Read the individual reason and required controls. NEED_REVIEW is separate: evidence needed for a determination is missing.

Does updating to the latest release finish the review?

A fix can address a defect while powerful intended capabilities and deployment settings remain. Verify the actual artifact, permissions, destinations, and enforcement of the required controls.