Skip to content

Security Audit: 2 finding(s) in mcp-server-filesystem #3317

Open
Limitless2023/servers
#2

Description

@starbuck100

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:

  1. Broad filesystem permissions - By design for an MCP filesystem server. Users control allowed directories via configuration.
  2. Arbitrary path operations - Necessary functionality for AI agent file operations. Protected by path validation.

Recommendations

  1. For Documentation: Add version pinning examples to README
  2. For Error Handling: Implement a debug mode flag to toggle verbose vs. sanitized errors
  3. 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

  1. lucamorettibuilds commented on Feb 12, 2026

    @lucamorettibuilds
  2. added a commit that references this issue on Feb 14, 2026
    2f51f4a
  3. aptsalt commented on Feb 22, 2026

    @aptsalt

    I'd like to work on both findings. My approach:

    1. 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.

    2. Version pinning in docs — Pin the npx examples in README.md to @0.6.3 to mitigate supply chain risk.

    3. Tests — Added 3 tests that explicitly verify error messages don't contain filesystem paths.

    PR incoming.

  4. starbuck100 commented on Feb 26, 2026

    @starbuck100
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions