Attack Chain

1. Attacker sends a POST request to an MCP-enabled application using the mcp-sanitizer middleware.
2. The application passes an attacker-supplied file_path to sanitizer.sanitize().
3. The validateFilePath function normalizes the input and performs an allowlist check.
4. Because the malicious path (e.g., /home/victim/.ssh/id_rsa) matches the hardcoded /home/ prefix, the validator returns blocked=false.
5. The library returns the path to the consumer application as a "trusted" sanitized value.
6. The consumer application, trusting the sanitizer's output, performs a filesystem read operation (e.g., fs.readFile) on the attacker-controlled path.
7. The application returns the contents of the sensitive file to the attacker in the HTTP response.

Impact

Successful exploitation allows unauthenticated remote attackers to exfiltrate sensitive user-home directory files, including SSH private keys, cloud provider credentials, and application tokens. This results in complete confidentiality loss for the affected user's data and potential lateral movement into cloud infrastructure or remote systems.

Recommendation

• Update any application utilizing mcp-sanitizer to implement strict path validation that excludes sensitive home directory sub-paths, even if the library is not updated.
• Implement a secondary layer of path validation in the application logic that explicitly denies access to .ssh, .aws, .gnupg, .kube, .config, and .env files regardless of the sanitizer output.
• Audit all MCP server implementations for dependencies on mcp-sanitizer and restrict access to the /tool endpoint to authenticated and authorized users only.