Use with caution. Address findings before production.
Scanned 5/29/2026, 7:38:51 AM·Cached result·Deep Scan·91 rules·View source ↗·How we decide ↗
AIVSS Score
Medium
Severity Breakdown
0
critical
7
high
2
medium
0
low
MCP Server Information
Findings
This package receives a C grade with a safety score of 68/100 due to seven high-severity prompt injection vulnerabilities that could allow attackers to manipulate model behavior through crafted inputs. Additionally, two medium-severity server configuration issues were identified that may expose the service to operational risks. You should address these vulnerabilities before deployment, particularly the prompt injection flaws which represent the primary attack surface.
AIPer-finding remediation generated by bedrock-claude-haiku-4-5 — 4 of 9 findings. Click any finding to read.
No known CVEs found for this package or its dependencies.
Path traversal in git_add allows staging files outside repository boundaries in mcp-server-git
Unrestricted git_init tool allows repository creation at arbitrary filesystem locations in mcp-server-git
Argument injection in git_diff and git_checkout functions for mcp-server-git allows overwriting local files
Missing path validation when using --repository flag in mcp-server-git
Scan Details
Done
Sign in to save scan history and re-scan automatically on new commits.
Building your own MCP server?
Same rules, same LLM judges, same grade. Private scans stay isolated to your account and never appear in the public registry. Required for code your team hasn’t shipped yet.
9 of 9 findings
9 findings
Tool 'read_file' shadows filesystem reserved tool name without server-specific prefix
Evidence
| 1 | #!/usr/bin/env node |
| 2 | import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 3 | import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; |
| 4 | import { RootsListChangedNotificationSchema, } from "@modelcontextprotocol/sdk/types.js"; |
RemediationAI
The tool 'write_file' uses a generic filesystem reserved name that conflicts with standard MCP filesystem server implementations, creating namespace collision and potential tool shadowing. Rename the tool to include a server-specific prefix such as 'custom_write_file' or 'myapp_write_file' in the tool registration call. This prefix ensures the tool name is globally unique and prevents accidental override of standard filesystem tools that clients may already depend on. Verify the fix by checking the MCP manifest or introspection output to confirm the new prefixed tool name appears and the old generic name is gone.
Tool 'search_files' shadows filesystem reserved tool name without server-specific prefix
Evidence
| 1 | #!/usr/bin/env node |
| 2 | import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 3 | import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; |
| 4 | import { RootsListChangedNotificationSchema, } from "@modelcontextprotocol/sdk/types.js"; |
RemediationAI
The tool 'write_file' uses a generic filesystem reserved name that conflicts with standard MCP filesystem server implementations, creating namespace collision and potential tool shadowing. Rename the tool to include a server-specific prefix such as 'custom_write_file' or 'myapp_write_file' in the tool registration call. This prefix ensures the tool name is globally unique and prevents accidental override of standard filesystem tools that clients may already depend on. Verify the fix by checking the MCP manifest or introspection output to confirm the new prefixed tool name appears and the old generic name is gone.
Tool 'list_files' shadows filesystem reserved tool name without server-specific prefix
Evidence
| 1 | #!/usr/bin/env node |
| 2 | import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 3 | import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; |
| 4 | import { RootsListChangedNotificationSchema, } from "@modelcontextprotocol/sdk/types.js"; |
RemediationAI
The tool 'write_file' uses a generic filesystem reserved name that conflicts with standard MCP filesystem server implementations, creating namespace collision and potential tool shadowing. Rename the tool to include a server-specific prefix such as 'custom_write_file' or 'myapp_write_file' in the tool registration call. This prefix ensures the tool name is globally unique and prevents accidental override of standard filesystem tools that clients may already depend on. Verify the fix by checking the MCP manifest or introspection output to confirm the new prefixed tool name appears and the old generic name is gone.
Tool 'write_file' shadows filesystem reserved tool name without server-specific prefix
Evidence
| 1 | #!/usr/bin/env node |
| 2 | import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 3 | import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; |
| 4 | import { RootsListChangedNotificationSchema, } from "@modelcontextprotocol/sdk/types.js"; |
RemediationAI
The tool 'write_file' uses a generic filesystem reserved name that conflicts with standard MCP filesystem server implementations, creating namespace collision and potential tool shadowing. Rename the tool to include a server-specific prefix such as 'custom_write_file' or 'myapp_write_file' in the tool registration call. This prefix ensures the tool name is globally unique and prevents accidental override of standard filesystem tools that clients may already depend on. Verify the fix by checking the MCP manifest or introspection output to confirm the new prefixed tool name appears and the old generic name is gone.
ReadMultipleFiles tool reads multiple arbitrary filesystem files and returns their contents verbatim to the LLM without provenance markers, enabling indirect prompt injection via crafted file contents.
Evidence
| 1 | #!/usr/bin/env node |
| 2 | import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 3 | import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; |
| 4 | import { RootsListChangedNotificationSchema, } from "@modelcontextprotocol/sdk/types.js"; |
| 5 | import fs from "fs/promises"; |
| 6 | import { createReadStream } from "fs"; |
| 7 | import path from "path"; |
| 8 | import { z } from "zod"; |
| 9 | import { minimatch } from "minimatch"; |
| 10 | import { normalizePath, expandHome } from './path-utils.js'; |
| 11 | import { getValidRoo |
RemediationAI
The SearchFiles tool returns matching file contents verbatim to the LLM without provenance delimiters, allowing an attacker to craft malicious file contents that inject prompt instructions directly into the LLM context. Wrap each matched file's content with clear provenance markers such as `[FILE: <path>]\n<content>\n[END FILE: <path>]` in the search results before returning to the client. These markers create a clear boundary between file data and LLM instructions, making prompt injection attempts visible and easier for the LLM to distinguish from legitimate instructions. Test by creating files with LLM instructions in their content, running a search, and verifying that the tool output clearly marks each result with file path and content delimiters.
ReadTextFile tool reads arbitrary filesystem content authored by third parties and returns it verbatim to the LLM without provenance delimiters, enabling indirect prompt injection via crafted file contents.
Evidence
| 1 | #!/usr/bin/env node |
| 2 | import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 3 | import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; |
| 4 | import { RootsListChangedNotificationSchema, } from "@modelcontextprotocol/sdk/types.js"; |
| 5 | import fs from "fs/promises"; |
| 6 | import { createReadStream } from "fs"; |
| 7 | import path from "path"; |
| 8 | import { z } from "zod"; |
| 9 | import { minimatch } from "minimatch"; |
| 10 | import { normalizePath, expandHome } from './path-utils.js'; |
| 11 | import { getValidRoo |
RemediationAI
The SearchFiles tool returns matching file contents verbatim to the LLM without provenance delimiters, allowing an attacker to craft malicious file contents that inject prompt instructions directly into the LLM context. Wrap each matched file's content with clear provenance markers such as `[FILE: <path>]\n<content>\n[END FILE: <path>]` in the search results before returning to the client. These markers create a clear boundary between file data and LLM instructions, making prompt injection attempts visible and easier for the LLM to distinguish from legitimate instructions. Test by creating files with LLM instructions in their content, running a search, and verifying that the tool output clearly marks each result with file path and content delimiters.
SearchFiles tool returns matching file contents from arbitrary filesystem locations verbatim to the LLM without provenance delimiters, enabling indirect prompt injection via crafted file contents.
Evidence
| 1 | #!/usr/bin/env node |
| 2 | import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; |
| 3 | import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; |
| 4 | import { RootsListChangedNotificationSchema, } from "@modelcontextprotocol/sdk/types.js"; |
| 5 | import fs from "fs/promises"; |
| 6 | import { createReadStream } from "fs"; |
| 7 | import path from "path"; |
| 8 | import { z } from "zod"; |
| 9 | import { minimatch } from "minimatch"; |
| 10 | import { normalizePath, expandHome } from './path-utils.js'; |
| 11 | import { getValidRoo |
RemediationAI
The SearchFiles tool returns matching file contents verbatim to the LLM without provenance delimiters, allowing an attacker to craft malicious file contents that inject prompt instructions directly into the LLM context. Wrap each matched file's content with clear provenance markers such as `[FILE: <path>]\n<content>\n[END FILE: <path>]` in the search results before returning to the client. These markers create a clear boundary between file data and LLM instructions, making prompt injection attempts visible and easier for the LLM to distinguish from legitimate instructions. Test by creating files with LLM instructions in their content, running a search, and verifying that the tool output clearly marks each result with file path and content delimiters.
Package declares an install-time hook (npm postinstall/preinstall/prepare, setup.py cmdclass override, custom setuptools install class, or non-default pyproject build-backend). Anyone installing this package runs the hook. Confirm the hook is necessary and review its contents; prefer shipping a plain library without install-time execution.
Evidence
| 20 | ], |
| 21 | "scripts": { |
| 22 | "build": "tsc && shx chmod +x dist/*.js", |
| 23 | "prepare": "npm run build", |
| 24 | "watch": "tsc --watch", |
| 25 | "test": "vitest run --coverage" |
| 26 | }, |
RemediationAI
The package.json declares a 'prepare' npm lifecycle hook that runs `npm run build` automatically during installation, executing arbitrary code (TypeScript compilation and chmod) on every developer's machine and CI system without explicit consent. Remove the 'prepare' hook from the scripts section and instead document the build step in the README with instructions for developers to run `npm run build` manually before use, or move the build to a pre-commit hook using husky if build artifacts must be committed. Removing the install-time hook eliminates the attack surface where a compromised dependency could execute malicious code during installation and makes the build process transparent and auditable. Verify the fix by running `npm install` in a clean environment and confirming that dist/ files are not automatically generated; then manually run `npm run build` and confirm it works as expected.
MCP manifest declares tools but no authentication field is present (none of: auth, authorization, bearer, oauth, mtls, apiKey, api_key, basic, token, authToken). Absence is a weak signal — confirm whether the server relies on network-layer or host-level auth, or declare the real mechanism explicitly so reviewers can audit it.
Evidence
| 1 | # Filesystem MCP Server |
| 2 | |
| 3 | Node.js server implementing Model Context Protocol (MCP) for filesystem operations. |
| 4 | |
| 5 | ## Features |
| 6 | |
| 7 | - Read/write files |
| 8 | - Create/list/delete directories |
| 9 | - Move files/directories |
| 10 | - Search files |
| 11 | - Get file metadata |
| 12 | - Dynamic directory access control via [Roots](https://modelcontextprotocol.io/docs/learn/client-concepts#roots) |
| 13 | |
| 14 | ## Directory Access Control |
| 15 | |
| 16 | The server uses a flexible directory access control system. Directories can be specified via command-line arguments or dyn |
RemediationAI
The MCP manifest and README do not declare any authentication or authorization mechanism, making it unclear whether the server relies on network-layer security (e.g., localhost-only, TLS mutual auth), host-level access control (e.g., file permissions), or no authentication at all. Add an explicit 'auth' or 'authorization' field to the manifest (or a dedicated section in README) documenting the security model, such as 'auth: "host-level file permissions"' or 'auth: "localhost-only, no authentication"' depending on the actual deployment model. Explicit documentation of the authentication model allows reviewers and operators to understand the security assumptions and make informed decisions about where and how to deploy the server. Verify the fix by reviewing the updated manifest or README with a security reviewer to confirm the declared auth mechanism matches the actual implementation and deployment constraints.