mcp servers expose file paths in error messages - tested 4 servers, all leak internal paths
been testing mcp server implementations for security issues and noticed that when tools fail, the error messages frequently leak full internal file paths from the server. tested the filesystem mcp server, github mcp server, postgres mcp server, and a custom mcp server we built. all four of them return error messages that contain absolute file paths when operations fail. for example, if you call a file read tool with a path that doesn't exist, the error message comes back as something like "FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/prod/data/secrets/config.json'". now the client knows your internal directory structure and can infer where sensitive files might be located. same issue with the postgres mcp server - if a query fails it returns the full connection string including host and database name in the error message. this feels like a basic security issue that should be fixed at the mcp protocol level. error messages sent to clients should be sanitized to remove internal paths, connection strings, and other infrastructure details. has anyone else noticed this or am i being overly paranoid about information disclosure?
need repro. which servers and what paths leaked
I tested @microsoft/mcp-server 0.4.1, @anthropic/mcp-fs 1.0.2, llamaindex mcp server 0.2.0, and custom server we built. All of them leak full file paths in error messages when file not found or permission denied
this is a huge opsec issue for hosted mcp deployments.... path leakage can reveal internal directory structure, usernames, even what other projects are on the same machine. which server leaked the most verbose paths?
the path leakage issue gets worse when you consider that many mcp servers are running in containerized environments where the leaked paths reveal not just local directory structure but also volume mount points and orchestration patterns. we audited our mcp deployment last month and found that error messages were leaking kubernetes secret mount paths (/var/run/secrets/...) which is a direct opsec failure. the fix isn't just sanitizing paths - you need to implement a proper error boundary that catches exceptions before they bubble up to the client, strips identifying information, and logs the full context server-side only. most mcp implementations don't do this by default.
this is serious issue for multi-tenant deployments. the leaked paths can reveal volume mount structure, which projects are running where, even usernames in some cases
path leakage is serious for multi-tenant but also.... most people running mcp locally don't care if it leaks /home/user paths. the real issue is hosted deployments where leaked paths reveal other tenants or internal infrastructure
tested @modelcontextprotocol/sdk-server and it leaks full paths in every error.... `/home/deploy/projects/client-foo/data/bar.json` reveals tenant names and directory structure. this is bad for hosted deployments
ok so how do u actualy fix this in the mcp server code. do you jsut strip paths from error messages or return generic errors
path leakage in error messages is basic opsec failure but also... most mcp servers are running locally so who cares if they leak /home/user/.local paths
path leakage matters more for hosted mcp servers or multi-tenant systems where the paths reveal information about other users or internal infrastructure. if you're running mcp locally for personal use then yeah it doesn't matter, but if you're building a product that exposes mcp tools to users, leaking /var/app/secrets/ or /home/admin/.ssh/ in error messages is a real info disclosure issue. what's the threat model for the servers you tested?