NVIDIA's RAG Blueprint had a path traversal in its MCP server. We got the fix merged in three days.

NVIDIA's RAG Blueprint ships with an MCP server that lets AI agents upload documents into a retrieval-augmented generation pipeline. That server had a path traversal vulnerability: any MCP client with network access could read arbitrary files from the host and ingest them into the RAG collection, where they became queryable by the LLM. We found it, submitted a fix and NVIDIA merged it as PR #465 on 9 April 2026.

The severity is real but bounded. This is not remote code execution. It requires MCP client access to a server that binds 0.0.0.0:8000 with no authentication. In a default deployment on a shared network, that is a meaningful precondition but not a difficult one.

What the MCP server does

NVIDIA's RAG Blueprint is a reference architecture for building retrieval-augmented generation systems on NVIDIA infrastructure. The MCP server component, found in examples/nvidia_rag_mcp/mcp_server.py, exposes tools that let MCP clients manage documents in the RAG pipeline. Two of those tools are tool_upload_documents and tool_update_documents, which accept a list of file paths, read them from the local filesystem and forward the contents to the ingestor service for indexing into the RAG collection.

The design intention is straightforward: an AI agent calls the upload tool, the server reads the specified files and pushes them into the pipeline. The problem is what happens when those file paths are not what the server expects.

The vulnerability

Both tool_upload_documents and tool_update_documents passed the file_paths parameter directly to Python's open() with no validation. The vulnerable pattern looked like this:

for path in file_paths:
    with open(path, "rb") as f:
        file_content = f.read()
        # ... forward to ingestor

There was no check on what path contained. A client could supply ../../../../etc/passwd, an absolute path like /etc/shadow, or a symlink pointing outside any intended directory. The server would dutifully open it, read the contents and feed them into the RAG collection. This is a textbook CWE-22 (Improper Limitation of a Pathname to a Restricted Directory).

The data flow makes this more than a simple file read. Once a file's contents are ingested into the RAG collection, they become queryable through the LLM interface. An attacker could ingest /etc/passwd, SSH keys or application configuration files, then retrieve their contents by asking the right questions in natural language. The filesystem contents are laundered through the RAG pipeline into conversational responses.

The server binds to 0.0.0.0:8000 by default and requires no authentication. Any MCP client on the network can call these tools.

The prompt injection angle

The direct attack vector requires an adversary with MCP client access to the server. But there is a second path: prompt injection through the LLM agent itself.

If an LLM agent is configured to use this MCP server, an adversary does not need direct access to the server at all. They need to get the agent to call tool_upload_documents with a malicious path. This could happen through a poisoned document already in the RAG collection, a crafted user message or a manipulated upstream data source.

Invariant Labs demonstrated that MCP tool descriptions can contain hidden instructions that hijack agent behaviour, causing agents to call tools with attacker-controlled parameters without the user's knowledge. Pillar Security's MCP threat model catalogues this as a known attack class: an agent acts as an unwitting proxy, and the tool's lack of input validation turns a prompt injection into a filesystem read.

Lohn et al.'s MCP safety audit confirmed that leading LLMs can be coerced through MCP tools into performing malicious actions including file access and credential theft, reinforcing that this is not a theoretical concern.

The fix

The fix adds a _validate_file_path() function that canonicalises each path using os.path.realpath() (which resolves ../ sequences and symlinks to an absolute path) and then checks that the resolved path starts with the allowed base directory. That base directory is configurable via the MCP_UPLOAD_DIR environment variable and defaults to the current working directory.

def _validate_file_path(file_path: str) -> str:
    real_path = os.path.realpath(file_path)
    if not real_path.startswith(UPLOAD_DIR):
        raise ValueError(f"Path traversal blocked: {file_path}")
    return real_path

Both tool_upload_documents and tool_update_documents now call this function before opening any file. The PR includes five new test cases covering relative traversal, absolute path escape, symlink escape and legitimate access within the allowed directory. NVIDIA collaborator niyatisingal approved the changes and the PR was merged on 9 April.

This is a known remediation pattern. It is the same approach used in most path traversal fixes: resolve the real path, check it against an allowlist of base directories, reject anything outside the boundary. The realpath() step is critical because it defeats ../ traversal and symlink-based escapes in a single operation.

A pattern across the ecosystem

This is not unique to NVIDIA. Path traversal is a class-level problem in MCP server implementations. The GitHub Advisory Database contains multiple CVEs for MCP servers with the same issue, including mcp-server-git and fast-filesystem-mcp. The vulnerability pattern is nearly identical each time: a tool accepts a file path from the MCP client, passes it to a filesystem operation and fails to validate that the path stays within an intended boundary.

We covered the broader MCP security landscape in a previous post, which looks at tool poisoning, rug pulls and supply chain risks across the MCP ecosystem. The NVIDIA finding is a concrete instance of one of those risks playing out in a high-profile project.

What makes MCP path traversals worth paying attention to is the direction of travel. MCP adoption is accelerating. AI agents are being granted filesystem access through these tool interfaces as a standard integration pattern. Every MCP server that opens files based on client-supplied paths without validation is carrying the same bug, and the protocol itself does nothing to prevent it. The specification has no built-in mechanism for restricting tool parameters to safe values. That responsibility falls entirely on individual server implementations, and as the NVIDIA case shows, it is easy to miss even in well-maintained projects from major vendors. As MCP servers become the default way AI agents interact with infrastructure, the number of these quiet file-read vulnerabilities is only going to grow.