github · serversacedea0c24b3

Evidence

import { describe, it, expect, vi } from 'vitest';

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

import { registerEchoTool, EchoSchema } from '../tools/echo.js';

import { registerGetSumTool } from '../tools/get-sum.js';

RemediationAI

The problem is that 'gzip-file-as-resource' performs filesystem I/O (reading and compressing files) without fully documenting these operations in its description. Update the tool description to state 'This tool reads files from the filesystem and creates gzip-compressed versions' to fully disclose the I/O operations. This transparency allows clients to understand the security and performance implications. Verify by inspecting the tool metadata returned from `server.listTools()` to confirm filesystem operations are documented.

Evidence

import { describe, it, expect, vi } from 'vitest';

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

import { registerEchoTool, EchoSchema } from '../tools/echo.js';

import { registerGetSumTool } from '../tools/get-sum.js';

RemediationAI

The problem is that 'gzip-file-as-resource' performs filesystem I/O (reading and compressing files) without fully documenting these operations in its description. Update the tool description to state 'This tool reads files from the filesystem and creates gzip-compressed versions' to fully disclose the I/O operations. This transparency allows clients to understand the security and performance implications. Verify by inspecting the tool metadata returned from `server.listTools()` to confirm filesystem operations are documented.

Evidence

import { describe, it, expect, vi } from 'vitest';

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

import { registerEchoTool, EchoSchema } from '../tools/echo.js';

import { registerGetSumTool } from '../tools/get-sum.js';

RemediationAI

The problem is that 'gzip-file-as-resource' performs filesystem I/O (reading and compressing files) without fully documenting these operations in its description. Update the tool description to state 'This tool reads files from the filesystem and creates gzip-compressed versions' to fully disclose the I/O operations. This transparency allows clients to understand the security and performance implications. Verify by inspecting the tool metadata returned from `server.listTools()` to confirm filesystem operations are documented.

Evidence

import { describe, it, expect, vi } from 'vitest';

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

import { registerEchoTool, EchoSchema } from '../tools/echo.js';

import { registerGetSumTool } from '../tools/get-sum.js';

RemediationAI

The problem is that the tool name 'search' collides with a reserved search tool name, creating namespace pollution. Rename the tool from 'search' to a server-specific variant like 'my-search' or 'custom-search' in the tool registration. This prevents shadowing of standard search functionality and clarifies tool ownership. Verify by running `server.listTools()` and confirming the new name is present and unique.

Evidence

import { describe, it, expect, vi } from 'vitest';

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

import { registerEchoTool, EchoSchema } from '../tools/echo.js';

import { registerGetSumTool } from '../tools/get-sum.js';

RemediationAI

The problem is that the tool name 'search' collides with a reserved search tool name, creating namespace pollution. Rename the tool from 'search' to a server-specific variant like 'my-search' or 'custom-search' in the tool registration. This prevents shadowing of standard search functionality and clarifies tool ownership. Verify by running `server.listTools()` and confirming the new name is present and unique.

Evidence

await fs.writeFile(legitFile, 'PUBLIC CONTENT', 'utf-8');

      // Create secret file in forbidden directory

      await fs.writeFile(secretFile, 'SECRET CONTENT', 'utf-8');

      // Step 1: validatePath would pass for legitimate file

      expect(isPathWithinAllowedDirectories(legitFile, allowed)).toBe(true);

RemediationAI

The problem is that the variable name 'SECRET CONTENT' suggests sensitive data but is written to a file without redaction, and the test file itself may leak secrets in logs or test output. Either rename the variable to 'PUBLIC_TEST_CONTENT' if it is genuinely non-sensitive, or wrap the value with a redaction helper before logging/writing (e.g., `redact(secretFile)` or `[REDACTED]`). This fix prevents accidental secret exposure in test artifacts and logs. Verify by running the test suite and confirming no unredacted secret strings appear in console output or test reports.

Evidence

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import { dirname, join } from "path";

import { fileURLToPath } from "url";

import { readdirSync, readFileSync, statSync } from "fs";

/**

 * Register static file resources

 * - Each file in src/everything/docs is exposed as an individual static resource

 * - URIs follow the pattern: "demo://static/docs/<filename>"

 * - Markdown (.md) files are served as mime type "text/markdown"

 * - Text (.txt) files are served as mime type "t

RemediationAI

The problem is that the resource handler in `src/everything/resources/files.ts` opens files based on a client-supplied URI without canonicalizing the path, allowing directory traversal attacks via `../` or absolute paths. Add path canonicalization using `path.resolve()` followed by `path.relative()` and a prefix check to ensure the resolved path stays within the allowed root directory. This fix prevents escape from the intended directory boundary. Test by attempting to access a file outside the allowed root (e.g., `../../../etc/passwd`) and confirming the request is rejected.

Evidence

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import {

  resourceTypeCompleter,

  resourceIdForPromptCompleter,

} from "../resources/templates.js";

import {

  textResource,

  textResourceUri,

  blobResourceUri,

  blobResource,

  RESOURCE_TYPE_BLOB,

  RESOURCE_TYPE_TEXT,

  RESOURCE_TYPES,

} from "../resources/templates.js";

/**

 * Register a prompt with an embedded resource reference

 * - Takes a resource type and id

 * - Returns the corresponding dynamically created resou

RemediationAI

The problem is that the prompt handler in `src/everything/prompts/resource.ts` interpolates untrusted handler arguments directly into the prompt template using template literals or string concatenation, allowing prompt injection. Wrap untrusted parameters in `<untrusted>...</untrusted>` XML tags or use a sanitization function before interpolation to mark user input as non-instructional. This fix prevents the LLM from interpreting attacker-controlled text as part of its system instructions. Verify by passing a malicious prompt argument (e.g., containing 'ignore previous instructions') and confirming it is treated as data, not instructions.

Evidence

import { z } from "zod";

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

/**

 * Register a prompt with arguments

 * - Two arguments, one required and one optional

 * - Combines argument values in the returned prompt

 *

 * @param server

 */

export const registerArgumentsPrompt = (server: McpServer) => {

  // Prompt arguments

  const promptArgsSchema = {

    city: z.string().describe("Name of the city"),

    state: z.string().describe("Name of the state").optional(),

  };

RemediationAI

The problem is that the prompt handler in `src/everything/prompts/args.ts` interpolates untrusted arguments directly into the prompt template, enabling prompt injection attacks. Wrap all user-supplied arguments in `<untrusted>...</untrusted>` tags or pass them through a prompt sanitization function before template interpolation. This ensures the LLM treats user input as data rather than instructions. Test by injecting a prompt-breaking string and confirming the LLM does not execute it as a directive.

Evidence

import { z } from "zod";

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import { completable } from "@modelcontextprotocol/sdk/server/completable.js";

/**

 * Register a prompt with completable arguments

 * - Two required arguments, both with completion handlers

 * - First argument value will be included in context for second argument

 * - Allows second argument to depend on the first argument value

 *

 * @param server

 */

export const registerPromptWithCompletions = (serve

RemediationAI

The problem is that the prompt handler in `src/everything/prompts/completions.ts` interpolates untrusted completion arguments directly into the prompt, allowing injection of malicious instructions. Wrap all user-provided arguments in `<untrusted>...</untrusted>` XML markers or sanitize them with a prompt-safe escaping function before interpolation. This prevents the LLM from executing attacker-supplied instructions embedded in argument values. Verify by submitting a completion argument with embedded instructions and confirming the LLM ignores it as a directive.

Evidence

import {

  StreamableHTTPServerTransport,

  EventStore,

} from "@modelcontextprotocol/sdk/server/streamableHttp.js";

import express, { Request, Response } from "express";

import { createServer } from "../server/index.js";

import { randomUUID } from "node:crypto";

import cors from "cors";

// Simple in-memory event store for SSE resumability

class InMemoryEventStore implements EventStore {

  private events: Map<string, { streamId: string; message: unknown }> =

    new Map();

  async storeEvent(s

RemediationAI

The problem is that the HTTP route handling MCP `tools/list` in `src/everything/transports/streamableHttp.ts` has no authentication middleware, allowing anonymous enumeration of all tools. Add an authentication middleware (e.g., `app.use(requireAuth)` or `app.post('/mcp', authenticate, ...)`) before the route handler to enforce identity verification. This fix prevents unauthenticated clients from discovering the attack surface. Test by making an unauthenticated request to the `/mcp` endpoint and confirming it returns a 401 or 403 error.

Evidence

from typing import Annotated, Tuple

from urllib.parse import urlparse, urlunparse

import markdownify

import readabilipy.simple_json

from mcp.shared.exceptions import McpError

from mcp.server import Server

from mcp.server.stdio import stdio_server

from mcp.types import (

    ErrorData,

    GetPromptResult,

    Prompt,

    PromptArgument,

    PromptMessage,

    TextContent,

    Tool,

    INVALID_PARAMS,

    INTERNAL_ERROR,

)

from protego import Protego

from pydantic import BaseModel, Field, AnyUr

RemediationAI

The problem is that a tool description contains imperative language directing the LLM to invoke other tools (e.g., 'call the write_file tool'), creating cross-tool chaining injection. Rewrite the description to focus on what the tool does rather than what other tools to call (e.g., change 'invoke write_file to save' to 'saves data to a file'). This prevents the LLM from being manipulated into unauthorized tool composition. Verify by reviewing the tool description in `server.listTools()` and confirming no imperative 'invoke' or 'call' directives appear.

Evidence

import { describe, it, expect, beforeEach, afterEach } from 'vitest';

import * as fs from 'fs/promises';

import * as path from 'path';

import * as os from 'os';

import { Client } from '@modelcontextprotocol/sdk/client/index.js';

import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';

import { spawn } from 'child_process';

/**

 * Integration tests to verify that tool handlers return structuredContent

 * that matches the declared outputSchema.

 *

 * These tests address i

RemediationAI

The problem is that a tool file performs destructive operations (file deletion, database drops, etc.) without emitting audit events, leaving no trail for forensic investigation. Add audit logging before the destructive operation using a logging function like `logger.audit({action: 'delete', resource: path, user: userId, timestamp})` or similar. This fix enables post-incident investigation and compliance reporting. Test by performing a destructive operation and confirming an audit log entry is created with the action, resource, and timestamp.

Evidence

FROM node:22.12-alpine AS builder

WORKDIR /app

COPY src/filesystem /app

COPY tsconfig.json /tsconfig.json

RUN --mount=type=cache,target=/root/.npm npm install

RUN --mount=type=cache,target=/root/.npm-production npm ci --ignore-scripts --omit-dev

FROM node:22-alpine AS release

WORKDIR /app

COPY --from=builder /app/dist /app/dist

COPY --from=builder /app/package.json /app/package.json

COPY --from=builder /app/package-lock.json /app/package-lock.json

ENV NODE_ENV=production

RUN npm ci --i

RemediationAI

The problem is that the Dockerfile in `src/filesystem/Dockerfile` does not specify a non-root USER directive, so the container runs as root by default, amplifying the impact of any RCE vulnerability. Add `USER 1000` (or `USER nonroot` on distroless images) before the final `CMD` or `ENTRYPOINT` directive in the release stage. This fix limits privilege escalation from container breakout. Verify by building the image and running `docker run --rm <image> id` to confirm the process runs as UID 1000, not 0.

Evidence

# Use a Python image with uv pre-installed

FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim AS uv

# Install the project into `/app`

WORKDIR /app

# Enable bytecode compilation

ENV UV_COMPILE_BYTECODE=1

# Copy from the cache instead of linking since it's a mounted volume

ENV UV_LINK_MODE=copy

# Install the project's dependencies using the lockfile and settings

RUN --mount=type=cache,target=/root/.cache/uv \

    --mount=type=bind,source=uv.lock,target=uv.lock \

    --mount=type=bind,source=py

RemediationAI

The problem is that the Dockerfile in `src/git/Dockerfile` lacks a non-root USER directive, allowing root execution of the container. Add `USER 1000` before the `CMD` or `ENTRYPOINT` in the final stage to drop privileges. This mitigates privilege escalation from container escape. Test by building and running the image, then executing `id` to verify the process runs as a non-root user.

Evidence

FROM node:22.12-alpine AS builder

COPY src/memory /app

COPY tsconfig.json /tsconfig.json

WORKDIR /app

RUN --mount=type=cache,target=/root/.npm npm install

RUN --mount=type=cache,target=/root/.npm-production npm ci --ignore-scripts --omit-dev

FROM node:22-alpine AS release

COPY --from=builder /app/dist /app/dist

COPY --from=builder /app/package.json /app/package.json

COPY --from=builder /app/package-lock.json /app/package-lock.json

ENV NODE_ENV=production

WORKDIR /app

RUN npm ci --ignore

RemediationAI

The problem is that the Dockerfile in `src/memory/Dockerfile` does not set a non-root USER, causing the container to run as root. Insert `USER 1000` before the `CMD` or `ENTRYPOINT` in the release stage to enforce least privilege. This reduces the blast radius of container compromises. Verify by building the image and confirming `docker run --rm <image> id` shows a non-zero UID.

Evidence

# Use a Python image with uv pre-installed

FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim AS uv

# Install the project into `/app`

WORKDIR /app

# Enable bytecode compilation

ENV UV_COMPILE_BYTECODE=1

# Copy from the cache instead of linking since it's a mounted volume

ENV UV_LINK_MODE=copy

# Install the project's dependencies using the lockfile and settings

RUN --mount=type=cache,target=/root/.cache/uv \

    --mount=type=bind,source=uv.lock,target=uv.lock \

    --mount=type=bind,source=py

RemediationAI

The problem is that the Dockerfile in `src/time/Dockerfile` lacks a non-root USER directive, running the container as root. Add `USER 1000` before the final `CMD` or `ENTRYPOINT` to enforce non-root execution. This fix prevents root-level exploitation of container vulnerabilities. Test by building and running the image, then checking that `id` returns a non-root UID.

Evidence

# Use a Python image with uv pre-installed

FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim AS uv

# Install the project into `/app`

WORKDIR /app

# Enable bytecode compilation

ENV UV_COMPILE_BYTECODE=1

# Copy from the cache instead of linking since it's a mounted volume

ENV UV_LINK_MODE=copy

# Install the project's dependencies using the lockfile and settings

RUN --mount=type=cache,target=/root/.cache/uv \

    --mount=type=bind,source=uv.lock,target=uv.lock \

    --mount=type=bind,source=py

RemediationAI

The problem is that the Dockerfile in `src/fetch/Dockerfile` does not specify a non-root USER, allowing root execution. Add `USER 1000` before the `CMD` or `ENTRYPOINT` in the final stage to drop privileges. This limits the impact of RCE vulnerabilities. Verify by building the image and running `docker run --rm <image> id` to confirm non-root execution.

Evidence

FROM node:22.12-alpine AS builder

COPY src/everything /app

COPY tsconfig.json /tsconfig.json

WORKDIR /app

RUN --mount=type=cache,target=/root/.npm npm install

FROM node:22-alpine AS release

WORKDIR /app

COPY --from=builder /app/dist /app/dist

COPY --from=builder /app/package.json /app/package.json

COPY --from=builder /app/package-lock.json /app/package-lock.json

ENV NODE_ENV=production

RUN npm ci --ignore-scripts --omit-dev

CMD ["node", "dist/index.js"]

RemediationAI

The problem is that the Dockerfile in `src/everything/Dockerfile` lacks a non-root USER directive, causing root execution. Add `USER 1000` before the `CMD` or `ENTRYPOINT` in the release stage to enforce least privilege. This mitigates privilege escalation from container escape. Test by building and running the image to confirm the process executes as a non-root user.

Evidence

FROM node:22.12-alpine AS builder

COPY src/sequentialthinking /app

COPY tsconfig.json /tsconfig.json

WORKDIR /app

RUN --mount=type=cache,target=/root/.npm npm install

RUN --mount=type=cache,target=/root/.npm-production npm ci --ignore-scripts --omit-dev

FROM node:22-alpine AS release

COPY --from=builder /app/dist /app/dist

COPY --from=builder /app/package.json /app/package.json

COPY --from=builder /app/package-lock.json /app/package-lock.json

ENV NODE_ENV=production

WORKDIR /app

RUN npm

RemediationAI

The problem is that the Dockerfile in `src/sequentialthinking/Dockerfile` does not set a non-root USER, running the container as root. Insert `USER 1000` before the `CMD` or `ENTRYPOINT` in the final stage to enforce non-root execution. This reduces the severity of container compromises. Verify by building the image and confirming `docker run --rm <image> id` shows a non-zero UID.

Evidence

return;

  }

  console.log(`Received session termination request for session ${sessionId}`);

  try {

    const transport = transports.get(sessionId);

RemediationAI

The problem is that the sessionId variable is printed directly to console without ANSI escape sanitization, allowing terminal injection attacks. Replace `console.log(\`Received session termination request for session ${sessionId}\`)` with `console.log('Received session termination request for session', sanitizeAnsi(sessionId))` using a library like `strip-ansi` or a custom sanitizer. This fix prevents cursor control sequences from rewriting terminal output. Test by passing a sessionId containing ANSI escape codes (e.g., `\x1b[2J`) and confirming the terminal is not cleared.

Evidence

await updateAllowedDirectoriesFromRoots(response.roots);

    }

  } catch (error) {

    console.error("Failed to request roots from client:", error instanceof Error ? error.message : String(error));

  }

});

RemediationAI

The problem is that the error message interpolates user-controlled error text without ANSI sanitization, enabling terminal injection. Replace the template literal with `console.error('Failed to request roots from client:', sanitizeAnsi(error instanceof Error ? error.message : String(error)))` using an ANSI sanitizer. This prevents malicious error messages from injecting terminal control sequences. Verify by triggering an error with embedded ANSI codes and confirming the terminal output is not manipulated.

Evidence

console.error("Client returned no roots set, keeping current settings");

      }

    } catch (error) {

      console.error("Failed to request initial roots from client:", error instanceof Error ? error.message : String(error));

    }

  } else {

    if (allowedDirectories.length > 0) {

RemediationAI

The problem is that the error message directly interpolates unsanitized error text, allowing ANSI injection. Change `console.error('Failed to request initial roots from client:', error instanceof Error ? error.message : String(error))` to `console.error('Failed to request initial roots from client:', sanitizeAnsi(error instanceof Error ? error.message : String(error)))` using a sanitization function. This prevents terminal hijacking via error messages. Test by injecting ANSI escape sequences in an error and confirming they are neutralized.

Evidence

);

        }

      } catch (error) {

        console.error(

          `Failed to request roots from client ${sessionId}: ${

            error instanceof Error ? error.message : String(error)

          }`

        );

      }

RemediationAI

The problem is that the sessionId and error message are interpolated into a template literal without ANSI sanitization, enabling terminal injection. Refactor to `console.error('Failed to request roots from client:', sanitizeAnsi(sessionId), sanitizeAnsi(error instanceof Error ? error.message : String(error)))` using an ANSI escape sanitizer. This prevents cursor control injection. Verify by passing a malicious sessionId and confirming terminal output is not corrupted.

Evidence

// The existing transport is already connected to the server

    await transport.handleRequest(req, res);

  } catch (error) {

    console.log("Error handling MCP request:", error);

    if (!res.headersSent) {

      res.status(500).json({

        jsonrpc: "2.0",

RemediationAI

The problem is that the error object is logged directly without ANSI sanitization, allowing terminal injection. Replace `console.log('Error handling MCP request:', error)` with `console.log('Error handling MCP request:', sanitizeAnsi(String(error)))` using an ANSI sanitizer. This prevents error messages from injecting terminal control sequences. Test by triggering an error with embedded ANSI codes and confirming the terminal is not manipulated.

Evidence

// Handle POST requests for client messages

app.post("/mcp", async (req: Request, res: Response) => {

  console.log("Received MCP POST request");

  try {

    // Check for existing session ID

    const sessionId = req.headers["mcp-session-id"] as string | undefined;

RemediationAI

The problem is that user-controlled input (sessionId from headers) is logged without ANSI sanitization, enabling terminal injection. Replace `console.log('Received MCP POST request')` and subsequent logging with sanitized versions: `console.log('Received MCP POST request'); if (sessionId) console.log('Session:', sanitizeAnsi(sessionId))`. This prevents header-based terminal hijacking. Verify by sending a request with a malicious `mcp-session-id` header and confirming the terminal is not corrupted.

Evidence

// Swap labels

            try {

              await github.rest.issues.removeLabel({ owner, repo, issue_number: prNumber, name: 'readme: pending' });

            } catch (e) {}

            await github.rest.issues.addLabels({ owner, repo, issue_number: prNumber, labels: ['readme: ready for review'] });

            // Find the bot's original comment

RemediationAI

The problem is that the catch block silently swallows the exception from `removeLabel()` with no logging or error handling, hiding failures in label removal. Replace `catch (e) {}` with `catch (e) { console.warn('Failed to remove label:', e); }` to log the error. This enables incident response and debugging. Test by simulating a label removal failure and confirming a warning is logged.

Evidence

} catch (error) {

      try {

        await fs.unlink(tempPath);

      } catch {}

      throw error;

    }

  }

RemediationAI

The problem is that the catch block in the cleanup code silently swallows the exception from `fs.unlink()` with no logging, hiding cleanup failures. Replace `catch {}` with `catch (cleanupError) { console.warn('Failed to clean up temp file:', cleanupError); }` to log the error. This prevents silent data accumulation and aids debugging. Verify by triggering a cleanup failure and confirming a warning is logged.

Evidence

path = root.uri.path

                try:

                    git.Repo(path)

                    repo_paths.append(str(path))

                except git.InvalidGitRepositoryError:

                    pass

            return repo_paths

        def by_commandline() -> Sequence[str]:

RemediationAI

The problem is that the except clause silently discards `git.InvalidGitRepositoryError` with no logging, hiding repository detection failures. Replace `except git.InvalidGitRepositoryError: pass` with `except git.InvalidGitRepositoryError as e: logger.debug(f'Skipping non-git path {path}: {e}')` to log the event. This enables troubleshooting of repository discovery. Test by running the function and confirming debug logs appear for non-git directories.

Evidence

} catch (renameError) {

        try {

          await fs.unlink(tempPath);

        } catch {}

        throw renameError;

      }

    } else {

RemediationAI

The problem is that the catch block silently swallows the cleanup exception with no logging, hiding failures in temporary file removal. Replace `catch {}` with `catch (cleanupError) { console.warn('Failed to clean up temp file during rename:', cleanupError); }` to log the error. This prevents silent resource leaks and aids debugging. Verify by simulating a cleanup failure and confirming a warning is logged.