Vulnerabilidades de la pila Node.js · Página 102

@vitejs/plugin-rsc has a Denial of Service Vulnerability in React Server Components

### Impact `@vitejs/plugin-rsc` vendors `react-server-dom-webpack`, which contained a vulnerability in versions prior to 19.2.6. See details in React repository's advisory https://github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh ### Patches Upgrade immediately to `@vitejs/[email protected]` or later.

• Actualiza a 0.5.26

Next.js Vulnerable to Denial of Service with Server Components

A vulnerability affects certain React Server Components packages for versions 19.x and frameworks that use the affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using the App Router. The issue is tracked upstream as [CVE-2026-23870](https://github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh). A specially crafted HTTP request can be sent to any App Router Server Function endpoint that, when deserialized, may trigger excessive CPU usage. This can result in denial of service in unpatched environments.

• Actualiza a 15.5.16
• Actualiza a 16.2.5

Angular Expressions - Remote Code Execution using filters

Angular Expressions provides expressions for the Angular.JS web framework as a standalone module. Prior to 1.5.2, an attacker can write a malicious expression using filters that escapes the sandbox to execute arbitrary code on the system. This vulnerability is fixed in 1.5.2.

• Actualiza a 1.5.2

CVE-2026-30635

Command injection vulnerability in automagik-genie 2.5.27 MCP Server allows attackers to execute arbitrary commands via the view_task (aka view) in the readTranscriptFromCommit function in dist/mcp/server.js when a user reads from an external FORGE_BASE_URL.

Signal K Server's WebSocket Login Endpoint Lacks Rate Limiting (Credential Brute-Force)

Signal K Server is a server application that runs on a central hub in a boat. Prior to version 2.25.0, the HTTP login endpoints (POST /login and POST /signalk/v1/auth/login) are protected by express-rate-limit (default: 100 attempts per 10-minute window, configurable via HTTP_RATE_LIMITS). The WebSocket login path — sending {login: {username, password}} messages over an established WebSocket connection — calls app.securityStrategy.login() directly without any rate limiting. An attacker can bypass HTTP rate limiting entirely by opening a WebSocket connection and attempting unlimited password guesses at the speed bcrypt allows (~20 attempts/sec

• Actualiza a 2.25.0

LiquidJS is vulnerable to Denial of Service via circular block reference in layout

LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to version 10.25.7, a circular block reference in {% layout %} / {% block %} causes an infinite recursive loop, consuming all available memory (~4GB) and crashing the Node.js process with FATAL ERROR: JavaScript heap out of memory. This allows any user who can submit a Liquid template to perform a Denial of Service attack. This issue has been patched in version 10.25.7.

• Actualiza a 10.25.7

@profullstack/mcp-server vulnerable to OS Command Injection in domain_lookup Module

<html> <body> <!--StartFragment--><html><head></head><body><h1>Security Advisory: OS Command Injection in <code>profullstack/mcp-server</code> <code>domain_lookup</code> Module</h1> Field | Value -- | -- Project | profullstack/mcp-server Repository | https://github.com/profullstack/mcp-server Affected Commit | 2e8ea913573610667ad54e31dba2e8198ebf7cf9 Affected Module | mcp_modules/domain_lookup Affected Endpoints | POST /domain-lookup/check, POST /domain-lookup/bulk Vulnerability Type | CWE-78: OS Command Injection CVSS 3.1 Score | 9.8 (Critical) — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Authentication Required | None Default Network Exposure | B

@cyclonedx/cdxgen: Docker registry auth substring match forwards credentials to a different registry

# Docker registry auth substring match forwards credentials to a different registry ## Repository `cdxgen/cdxgen` ## Affected product/package - Ecosystem: npm - Package: `@cyclonedx/cdxgen` - Reviewed tree version: `12.3.3` - Reviewed commit: `b1e179869fd7c6032c3d483c3f7bd4d7154ec22b` - Affected file: `lib/managers/docker.js` - Affected from: v9.9.5 The Single Executable Applications (SEA) binaries and container images are also affected. ## Weakness CWE-522 / CWE-346. ## Summary When cdxgen scans or pulls container images through the Docker daemon API, it builds an `X-Registry-Auth` header from Docker credentials in `DOCKER_CONFIG/co

• Actualiza a 12.3.3

RedwoodSDK: Same-site CSRF in in server actions

RedwoodSDK is a server-first React framework. From version 1.0.0-beta.50 to before version 1.2.3, server actions in rwsdk apply HTTP method enforcement but no origin validation. A request originating from a different origin that the browser treats as same-site can invoke a server action with the victim's session cookie attached. This issue has been patched in version 1.2.3.

• Actualiza a 1.2.3

n8n-MCP: Authenticated SSRF in n8n-mcp webhook and API client paths

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. From version 2.18.7 to before version 2.50.2, there is an authenticated server-side request forgery vulnerability affecting the webhook trigger tools, the n8n API client (N8N_API_URL), and per-request URLs supplied via the x-n8n-url header in multi-tenant HTTP mode. This issue has been patched in version 2.50.2.

• Actualiza a 2.50.2

n8n-MCP: Sensitive MCP tool-call arguments logged on authenticated requests in HTTP mode

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.13, when n8n-mcp runs in HTTP transport mode, authenticated MCP tools/call requests had their full arguments and JSON-RPC params written to server logs by the request dispatcher and several sibling code paths before any redaction. When a tool call carries credential material — most notably n8n_manage_credentials.data — the raw values can be persisted in logs. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipeli

• Actualiza a 2.47.13

n8n-MCP Logs Sensitive Request Data on Unauthorized /mcp Requests

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.11, when n8n-mcp runs in HTTP transport mode, incoming requests to the POST /mcp endpoint had their request metadata written to server logs regardless of the authentication outcome. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of: bearer tokens from the Authorization header, per-tenant API keys from the, x-n8n-key header in multi-tenant setups, JSON

• Actualiza a 2.47.11

n8n-mcp affected by path traversal, redirect-following SSRF, and telemetry payload exposure

## Impact `n8n-mcp` versions before 2.50.1 contained three independently-reported issues affecting deployments that run the n8n API integration: 1. **Caller-supplied identifiers were not validated before being used as URL path segments** by the n8n API client. An authenticated MCP caller passing a crafted workflow id could cause outbound requests carrying the configured n8n API key to land on other same-origin endpoints, bypassing handler-level access controls (including `DISABLED_TOOLS`). 2. **Validated webhook, form, and chat trigger URLs followed redirects.** A URL that passed initial validation could redirect the outbound request to a

• Actualiza a 2.50.1

locize Client SDK: Cross-origin DOM XSS & Handler Hijack Through Missing e.origin Validation in InContext Editor

locize is a localization platform that connects code and i18n setup. Prior to version 4.0.21, the locize client SDK registers a window.addEventListener("message", …) handler that dispatches to registered internal handlers (editKey, commitKey, commitKeys, isLocizeEnabled, requestInitialize, …) without validating event.origin. The pre-patch listener in src/api/postMessage.js gates dispatch on event.data.sender === "i18next-editor-frame" — that value sits inside the attacker-controlled message payload, not the browser-enforced origin. Any web page that could embed or be embedded by a locize-enabled host — an iframe on a third-party page, a windo

• Actualiza a 4.0.21

Path traversal / URL injection via unsanitised lng/ns/projectId/version in i18next-locize-backend

i18next-locize-backend is a simple i18next backend for locize.com which can be used in Node.js, in the browser and for Deno. Prior to version 9.0.2, i18next-locize-backend interpolates lng, ns, projectId, and version directly into the configured loadPath / privatePath / addPath / updatePath / getLanguagesPath URL templates with no path-component validation and no encoding. When an application exposes any of these values to user-controlled input (?lng= / ?ns= query parameters via i18next-browser-languagedetector, cookies, request headers, or a URL-derived projectId), a crafted value can change the structure of the outgoing request URL. Affecte

• Actualiza a 9.0.2

i18next-fs-backend: Path traversal via unsanitised lng/ns allows arbitrary file read/overwrite

i18next-fs-backend is a backend layer for i18next using in Node.js and for Deno to load translations from the filesystem. Prior to version 2.6.4, i18next-fs-backend substitutes the lng and ns options directly into the configured loadPath / addPath templates and then read / write the resulting file from disk. The interpolation is unencoded and unvalidated, so a crafted lng or ns value — containing .., a path separator, a control character, a prototype key, or simply an unexpectedly long string — allows an attacker who can influence either value to read or overwrite files outside the intended locale directory. When lng / ns are derived from unt

• Actualiza a 2.6.4

Path traversal / SSRF in i18next-http-middleware via user-controlled language and namespace parameters

i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware passes the user-controlled lng and ns values from getResourcesHandler directly into i18next.services.backendConnector.load(languages, namespaces, …) without any sanitization. Depending on which backend is configured, the unvalidated path segments enable either path traversal or SSRF. This issue has been patched in version 3.9.3.

• Actualiza a 3.9.3

HTTP response splitting and DoS in i18next-http-middleware via unsanitised Content-Language header

i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware wrote user-controlled language values into the Content-Language response header after passing them through utils.escape(), which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older i18next (< 19.5.0) that still exercised the backward-compatibility fallback at LanguageDetector.js:100 or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled lng parameter reached re

• Actualiza a 3.9.3

Prototype pollution and path traversal in i18next-http-middleware via user-controlled language and namespace parameters

18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Versions prior to 3.9.3 allow an unauthenticated HTTP client to pollute Object.prototype in the Node.js process hosting the middleware, via two unvalidated entry points that reach internal object-key writes: getResourcesHandler and missingKeyHandler. This can break authorisation checks (if (user.isAdmin) returning true for any user), cause type-confusion DoS, and depending on downstream code it can be chained into RCE.

• Actualiza a 3.9.3

Marko: XSS via case-insensitive script/style closing tag bypass in runtime HTML escaping

Marko is a declarative, HTML-based language for building web apps. Prior to marko version 5.38.36 and prior to @marko/runtime-tags 6.0.164, when dynamic text is interpolated into a <script> or <style> tag the Marko runtime failed to prevent tag breakout when the closing tag used non-lowercase casing. An attacker able to place input inside a <script> or <style> block could break out of the tag with </SCRIPT>, </Style>, etc. and inject arbitrary HTML/JavaScript, resulting in cross-site scripting. This issue has been patched in marko version 5.38.36 and @marko/runtime-tags 6.0.164.

• Actualiza a 5.38.36
• Actualiza a 6.0.164