You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Security Audit: 2 finding(s) in mcp-server-filesystem #3317
The MCP filesystem server is well-designed with strong security practices. The codebase demonstrates professional security implementation including:
✅ Comprehensive path validation with symlink resolution
✅ Strict directory access control via allowlist
✅ Atomic file operations preventing race conditions
✅ Proper handling of null bytes and path traversal attempts
✅ Detailed security comments explaining design decisions
The 2 low-severity findings are minor improvements that don't represent exploitable vulnerabilities.
Real Findings (2 low-severity issues)
1. LOW: Error messages expose internal path information
File:src/filesystem/lib.ts:87 Issue: Error messages include full filesystem paths when validation fails Impact: Could leak directory structure in shared environments Remediation: Consider sanitizing error messages in production mode
2. LOW: NPX usage without version pinning in documentation
File:README.md:243 Issue: Documentation shows npx -y @modelcontextprotocol/server-filesystem without version pinning Impact: Supply chain risk if malicious version published Remediation: Update docs to recommend version pinning for production: npx -y @modelcontextprotocol/server-filesystem@0.6.3
By-Design Security Patterns (Informational)
These are intentional features that require careful user configuration but are not vulnerabilities:
Broad filesystem permissions - By design for an MCP filesystem server. Users control allowed directories via configuration.
Arbitrary path operations - Necessary functionality for AI agent file operations. Protected by path validation.
Recommendations
For Documentation: Add version pinning examples to README
For Error Handling: Implement a debug mode flag to toggle verbose vs. sanitized errors
For Users: Always restrict allowed directories to minimum necessary paths; use Docker read-only mounts where possible
Full Report
View the complete audit report with code-level details and evidence: AgentAudit Report
This audit was performed automatically by AgentAudit, the security registry for AI agent packages. The findings are based on code review of commit 70c549b.
Error message sanitization — Remove filesystem paths from validatePath() error messages in src/filesystem/lib.ts. The messages will still describe the denial reason (e.g. "Access denied - path outside allowed directories") but won't expose the absolute path or the allowed directory list.
Version pinning in docs — Pin the npx examples in README.md to @0.6.3 to mitigate supply chain risk.
Great to see community interest in addressing these findings. @aptsalt — your proposed approach sounds solid. Removing filesystem paths from error messages while keeping descriptive denial reasons is the right balance between security and usability. Happy to re-audit once the fix lands.
Activity
lucamorettibuilds commentedon Feb 12, 2026
docs(filesystem): add version pinning for npx usage
aptsalt commentedon Feb 22, 2026
I'd like to work on both findings. My approach:
Error message sanitization — Remove filesystem paths from
validatePath()error messages insrc/filesystem/lib.ts. The messages will still describe the denial reason (e.g. "Access denied - path outside allowed directories") but won't expose the absolute path or the allowed directory list.Version pinning in docs — Pin the
npxexamples inREADME.mdto@0.6.3to mitigate supply chain risk.Tests — Added 3 tests that explicitly verify error messages don't contain filesystem paths.
PR incoming.
starbuck100 commentedon Feb 26, 2026
Great to see community interest in addressing these findings. @aptsalt — your proposed approach sounds solid. Removing filesystem paths from error messages while keeping descriptive denial reasons is the right balance between security and usability. Happy to re-audit once the fix lands.