npm · n8n-mcp2.53.2

Evidence

private getSystemPrompt;

    private extractJson;

    private truncateArrayFields;

    private truncateReadme;

    private getDefaultSummary;

    testConnection(): Promise<{

        success: boolean;

RemediationAI

The problem is that generateSummary() uses a module-level OpenAI client initialized with baseUrl and apiKey from constructor config, which means all callers share the same credentials regardless of their identity or authorization level. Add a per-request caller identity parameter (e.g., userId, requestContext) to the generateSummary() method signature and pass it to a new OpenAI client instance created per-request with caller-specific credentials or a credential resolver function. This ensures each caller's API calls are isolated and auditable to their identity. Verify by adding logging that captures the caller identity for each API request and confirming different callers receive different client instances or credential contexts.

Evidence

username: string;

        email: string;

    };

    maintainers: Array<{

        username: string;

        email: string;

    }>;

RemediationAI

The problem is that getPackageTarballUrl() uses a module-level npmRegistryUrl credential without per-request caller identity, allowing all callers to access the npm registry with the same authentication context. Refactor the method to accept a caller identity parameter and resolve npm registry credentials per-request using a credential provider that maps caller identity to appropriate registry tokens or authentication headers. This isolates registry access by caller and enables per-caller rate limiting and audit trails. Verify by confirming that requests from different callers use different authentication tokens or headers in the npm registry HTTP calls.

Evidence

private extractJson;

    private truncateArrayFields;

    private truncateReadme;

    private getDefaultSummary;

    testConnection(): Promise<{

        success: boolean;

        message: string;

RemediationAI

The problem is that generateBatch() uses a module-level OpenAI client with baseUrl and apiKey from constructor config, creating a shared credential context for all batch operations regardless of caller identity. Modify generateBatch() to accept a caller identity parameter and instantiate a new OpenAI client per-batch using caller-specific credentials resolved from a credential provider, or wrap the batch call with caller context that is logged and audited. This ensures batch operations are isolated by caller and traceable to their identity. Verify by adding request context logging to each batch API call and confirming that different callers' batches are processed with distinct credential contexts.

Evidence

publisher?: {

        username: string;

        email: string;

    };

    maintainers: Array<{

        username: string;

        email: string;

RemediationAI

The problem is that fetchPackageJson() uses a module-level npmRegistryUrl credential without per-request caller identity, allowing all callers to fetch package metadata with the same authentication. Add a caller identity parameter to fetchPackageJson() and resolve npm registry credentials per-request using a credential provider that returns caller-specific tokens or headers. This isolates package metadata access by caller and enables per-caller audit trails. Verify by confirming that different callers' fetchPackageJson() calls use different authentication tokens in the HTTP headers sent to the npm registry.

Evidence

};

    publisher?: {

        username: string;

        email: string;

    };

    maintainers: Array<{

        username: string;

RemediationAI

The problem is that fetchNpmPackages() uses module-level npmSearchUrl and npmRegistryUrl credentials without per-request caller identity, creating a shared authentication context for all npm registry and search API calls. Refactor fetchNpmPackages() to accept a caller identity parameter and resolve both search and registry credentials per-request using a credential provider that maps caller identity to appropriate tokens. This ensures npm API access is isolated and auditable by caller. Verify by instrumenting the HTTP calls to npmSearchUrl and npmRegistryUrl and confirming that different callers use different authentication credentials.

Evidence

username?: string;

    };

    publisher?: {

        username: string;

        email: string;

    };

    maintainers: Array<{

RemediationAI

The problem is that fetchVerifiedNodes() uses a module-level strapiBaseUrl credential (environment-dependent) without per-request caller identity, allowing all callers to access the Strapi API with the same authentication context. Add a caller identity parameter to fetchVerifiedNodes() and resolve Strapi credentials per-request using a credential provider that returns caller-specific API keys or authentication headers based on the caller identity. This isolates Strapi API access by caller and enables per-caller audit logging. Verify by confirming that different callers' Strapi API requests include different authentication tokens or headers.

Evidence

const validated = exports.DocumentationSummarySchema.parse(truncated);

            return {

                nodeType: input.nodeType,

                summary: validated,

            };

        }

        catch (error) {

RemediationAI

The problem is that the OpenAI chat.completions.create() call in generateSummary() does not pass the max_tokens parameter, even though maxTokens is available in the constructor config, allowing the LLM to generate unbounded responses that may exceed expected limits. Modify the chat.completions.create() call to explicitly include max_tokens: this.maxTokens in the request parameters. This ensures responses are bounded by the configured token limit, preventing cost overruns and resource exhaustion. Verify by calling generateSummary() and confirming that the OpenAI API request includes the max_tokens field set to the configured maxTokens value.

Evidence

"use strict";

var __importDefault = (this && this.__importDefault) || function (mod) {

    return (mod && mod.__esModule) ? mod : { "default": mod };

};

Object.defineProperty(exports, "__esModule", { value: true });

exports.DocumentationGenerator = exports.DocumentationSummarySchema = void 0;

exports.createDocumentationGenerator = createDocumentationGenerator;

const openai_1 = __importDefault(require("openai"));

const zod_1 = require("zod");

const logger_1 = require("../utils/logger");

exports.D

RemediationAI

The problem is that extractJson() parses arbitrary JSON responses from the remote OpenAI API without validation, allowing an attacker who controls the LLM endpoint (via baseUrl injection) to embed malicious code or redefinitions in the JSON that are later executed. Replace the generic JSON.parse() call with strict schema validation using the existing DocumentationSummarySchema (via zod parse()), and reject any JSON that does not conform to the expected schema structure. This ensures only expected fields are accepted and prevents injection of arbitrary code. Verify by attempting to inject a malicious JSON structure into the LLM response and confirming that extractJson() throws a validation error.

Evidence

"use strict";

var __importDefault = (this && this.__importDefault) || function (mod) {

    return (mod && mod.__esModule) ? mod : { "default": mod };

};

Object.defineProperty(exports, "__esModule", { value: true });

exports.CommunityNodeFetcher = void 0;

const axios_1 = __importDefault(require("axios"));

const logger_1 = require("../utils/logger");

const FETCH_CONFIG = {

    STRAPI_TIMEOUT: 30000,

    NPM_REGISTRY_TIMEOUT: 15000,

    NPM_DOWNLOADS_TIMEOUT: 10000,

    RETRY_DELAY: 1000,

    MAX_R

RemediationAI

The problem is that fetchPackageJson() fetches and returns arbitrary package.json from npm without validation, and if combined with dynamic require or eval patterns, enables remote code execution via malicious package metadata. Implement strict schema validation on the returned package.json using zod or a similar validator that only allows expected fields (name, version, description, etc.) and rejects any fields that could trigger code execution (e.g., scripts, bin, require hooks). This prevents malicious package metadata from being used in code execution contexts. Verify by attempting to fetch a package with malicious fields and confirming that the validation rejects it.

Evidence

"use strict";

var __importDefault = (this && this.__importDefault) || function (mod) {

    return (mod && mod.__esModule) ? mod : { "default": mod };

};

Object.defineProperty(exports, "__esModule", { value: true });

exports.DocumentationGenerator = exports.DocumentationSummarySchema = void 0;

exports.createDocumentationGenerator = createDocumentationGenerator;

const openai_1 = __importDefault(require("openai"));

const zod_1 = require("zod");

const logger_1 = require("../utils/logger");

exports.D

RemediationAI

The problem is that DocumentationGenerator fetches remote LLM endpoint configuration (baseUrl, model, apiKey) at construction time and uses it to make dynamic LLM calls, allowing an attacker to steer summarization behavior by controlling the baseUrl parameter. Implement strict validation of the baseUrl parameter using a whitelist of allowed LLM endpoints, and move credential resolution to a secure credential provider that is not user-configurable. This prevents remote steering of the LLM endpoint. Verify by attempting to pass a malicious baseUrl and confirming that the constructor rejects it or that the credential provider overrides it with a whitelisted endpoint.

Evidence

const content = completion.choices[0]?.message?.content;

            if (!content) {

                throw new Error('No content in LLM response');

            }

            const jsonContent = this.extractJson(content);

            const parsed = JSON.parse(jsonContent);

            const truncated = this.truncateArrayFields(parsed);

            const validated = exports.DocumentationSummarySchema.parse(truncated);

            return {

                nodeType: input.nodeType,

                s

RemediationAI

The problem is that generateSummary() builds dynamic prompts from input documentation and sends them to a remote LLM endpoint without delimiters or clear separation between system instructions and user-provided content, enabling prompt injection attacks. Refactor the prompt construction to use explicit delimiters (e.g., XML tags or structured prompt templates) that clearly separate the system prompt from the user-provided documentation, and validate that user input does not contain prompt injection patterns. This prevents malicious documentation from breaking out of the intended prompt context. Verify by attempting to inject LLM instructions into the readme field and confirming that the LLM treats them as data rather than instructions.

Evidence

import { z } from 'zod';

export declare const DocumentationSummarySchema: z.ZodObject<{

    purpose: z.ZodString;

    capabilities: z.ZodArray<z.ZodString, "many">;

RemediationAI

The problem is that generateSummary() accepts the untrusted readme field from DocumentationInput and includes it directly in the LLM prompt without delimiters or escaping, enabling prompt injection attacks via malicious package documentation. Wrap the readme content in explicit delimiters (e.g., <README>...content...</README>) and escape any special characters that could break the prompt structure, or use a structured prompt template that treats readme as data. This prevents malicious documentation from injecting instructions into the LLM prompt. Verify by creating a test package with prompt injection payloads in the README and confirming that the LLM treats them as literal text.

Evidence

export interface StrapiCommunityNodeAttributes {

    name: string;

    displayName: string;

    description: string;

RemediationAI

The problem is that fetchPackageWithReadme() returns untrusted npm package README content directly into LLM context without provenance markers or delimiters, enabling indirect prompt injection via malicious package documentation. Wrap the README content in clear provenance delimiters (e.g., <EXTERNAL_SOURCE source="npm" package="name">...content...</EXTERNAL_SOURCE>) and add a validation step that sanitizes or escapes the README before returning it. This makes the external origin explicit and prevents injection attacks. Verify by confirming that the returned README includes provenance markers and that malicious content in the README does not affect LLM behavior.

Evidence

import { NodeRepository } from '../database/node-repository';

import { CommunityNodeFetcher } from './community-node-fetcher';

import { DocumentationGenerator } from './documentation-generator';

export interface BatchProcessorOptions {

RemediationAI

The problem is that fetchReadmes() fetches untrusted README content from npm packages and stores it in the repository without sanitization or provenance markers, which is later returned to LLM context without clear attribution. Add a sanitization step that escapes or validates README content before storage, and add provenance metadata (source, package name, timestamp) to each stored README. When returning README content to LLM context, include the provenance markers. This ensures untrusted content is clearly marked and cannot inject malicious instructions. Verify by confirming that stored READMEs include provenance metadata and that malicious content is escaped or rejected.

RemediationAI

The problem is that @modelcontextprotocol/sdk version 1.20.1 has 3 known HIGH-severity CVEs (GHSA-345p-7cg4-v4c7, GHSA-8r9q-7v3j-jr4g, GHSA-w48q-cv73-mx4w) that could enable remote code execution or other attacks. Upgrade the package to the latest patched version by running npm update @modelcontextprotocol/sdk or manually updating the version in package.json to a version >= the first patched release for each CVE. This eliminates the known vulnerabilities. Verify by running npm audit and confirming that no HIGH-severity vulnerabilities are reported for this package.

Evidence

# Templates are processed in batches using OpenAI's Batch API for 50% cost savings

# OPENAI_BATCH_SIZE=100

# Enable metadata generation during template fetch (default: false)

# Set to true to automatically generate metadata when running fetch:templates

# METADATA_GENERATION_ENABLED=false

RemediationAI

The problem is that network, IO, and subprocess calls throughout the codebase lack explicit timeouts, allowing malicious or hung upstream services (HTTP hosts, npm registry, Strapi API, OpenAI API) to pin threads and exhaust connection pools, making the MCP server unresponsive. Add explicit timeout parameters to all HTTP client calls (axios, OpenAI client), npm registry calls, and subprocess operations; set reasonable defaults (e.g., 30 seconds for HTTP, 60 seconds for batch operations) in the configuration and environment variables. This prevents hung connections from blocking the server. Verify by simulating a hung upstream service and confirming that the MCP server times out and recovers within the configured timeout window.