Repository navigation
Security Audit: 2 finding(s) in mcp-server-filesystem #3317
Description
AgentAudit Security Audit Report
| Metric | Value |
|---|---|
| Package | @modelcontextprotocol/server-filesystem |
| Version | 0.6.3 |
| Risk Score | 2/100 |
| Result | safe |
| Findings | 4 total (0 critical, 0 high, 0 medium, 2 low) |
Overall Assessment
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.
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.
cliffhall commentedon Oct 19, 2026
Triage: Priority Low (total 3)
This is a security report, so it is handled by the maintainers and the details aren't discussed here. If you have more to add, please use the advisory form rather than this thread.
Board: Servers V2 (#43), Status
Incoming, awaiting maintainer review (no milestone yet). Part of the backlog triage in #4875.cliffhall commentedon Oct 29, 2026
Thanks for the audit. We have reviewed both low findings against the current v2 code.
list_allowed_directories, and the specific reason is what lets the model correct its call. Tests pin these messages, and an earlier sanitizing PR (fix(filesystem): sanitize error messages to prevent path info disclosure #3371) was closed for the same reason.npxwithout a version. The README follows the convention all the reference servers use,npx -y <package>. A version written into the docs would go stale at every release. Packages are published from CI through npm trusted publishing with provenance, and anyone who wants a fixed version can append@<version>to the package name.Closing as not planned. Thanks again for the positive overall assessment.