Vulnerabilities

The @zereight/mcp-gitlab MCP server (version 2.1.18, npm) registers its Streamable HTTP transport at /mcp without any Host or Origin allowlist and without the MCP SDK's DNS-rebinding protections (enableDnsRebindingProtection, allowedHosts, allowedOrigins are never set; express.() is installed globally before any origin check). Because the server binds to 127.0.0.1 by default, a malicious web page can use DNS rebinding to make a victim's browser send cross-origin requests to the local MCP listener with attacker-controlled Host and Origin headers, which the server accepts and processes through the MCP initialize path instead of rejecting at the HTTP boundary. In default local mode this lets the attacker's page drive the MCP session and invoke GitLab tools from the victim's machine; in REMOTE_AUTHORIZATION=true mode, unauthenticated tools/list and GitLab API calls are blocked by token checks, but the browser-boundary flaw remains and a captured/planted Private-Token flow still allows tool listing and calls such as list_project_variables against the victim's GitLab. Affected users are anyone running this package with the Streamable HTTP transport (documented for remote deployments), while stdio users are not directly exposed. The issue is rated CVSS 3.1 9.6 (critical); no public PoC or in-the-wild exploitation is known.

Do: Upgrade @zereight/mcp-gitlab to a release later than 2.1.18 once a fix ships (verify that StreamableHTTPServerTransport sets enableDnsRebindingProtection with allowedHosts/allowedOrigins, or that a Host/Origin-checking middleware runs before express.() and /mcp). Until then, prefer stdio over Streamable HTTP, do not expose the HTTP listener beyond loopback without a reverse proxy that strictly validates Host and Origin, and set REMOTE_AUTHORIZATION=true so tool calls require a GitLab token. Review server logs and metrics (totalSessions/activeSessions) for unexpected initialize requests or sessions originating from browsers.

The @zereight/mcp-gitlab MCP server (repository zereight/gitlab-mcp) is vulnerable to server-side request forgery (CWE-918) when the environment variable ENABLE_DYNAMIC_API_URL=true is set: the server honors an attacker-supplied X-GitLab-API-URL request header as the base URL for all outbound GitLab API calls, validating only URL syntax with no allowlist or hostname restriction. Because the server attaches the victim's GitLab Private-Token to every outbound fetch using that redirected URL, any caller who can reach the HTTP/SSE transport can point the server at an attacker-controlled host and capture the victim's token, giving full access to whatever GitLab projects and permissions that token grants. All versions through commit 74a8c83 are affected, and no patched version was available at the time of the report. The flaw is rated critical (CVSS 3.1 9.6; the advisory text also cites 8.5) and the report includes a working proof-of-concept, though no exploitation in the wild is known and it is not on the CISA KEV list.

Do: Do not set ENABLE_DYNAMIC_API_URL=true; leave the dynamic API URL feature disabled (its default state) until a patched release is published. If the flag was ever enabled on a network-reachable instance, rotate the configured GitLab private tokens immediately and review logs for outbound requests to unexpected hosts carrying private-token headers. Restrict access to the MCP HTTP/SSE endpoints (bind to localhost, firewall the port, require strong authentication) and monitor the upstream repository for a fix.

@yeger/turbo-graph, an npm package for visualizing Turborepo task graphs, starts an embedded Next.js server bound to all network interfaces (0.0.0.0:29312 by default) instead of the loopback interface, because the declared 'localhost' hostname is never passed to Node's listen() call. Its /api/run GET endpoint performs no authentication, session validation, CSRF protection, or task allowlist check (CWE-306) and passes attacker-supplied 'tasks' and 'filter' query parameters directly into a spawn() of the Turbo CLI. An unauthenticated adjacent-network attacker can therefore send a crafted GET request to the /api/run endpoint to trigger arbitrary repository-defined Turborepo tasks, gaining code execution, file modification, destructive build side effects, or deployment of attacker-chosen targets with the privileges of the developer's OS user. Anyone running the @yeger/turbo-graph dev server, typically on a developer workstation while inspecting a monorepo, is affected; no affected version range or fixed version is specified in the available data. No public proof-of-concept or in-the-wild exploitation is known; the flaw carries a CVSS 3.1 score of 8.8 (high) with an adjacent-network attack vector.

Do: Upgrade @yeger/turbo-graph to the latest patched release when one is published (no fixed version is stated in the available data) and check your dependency tree with npm ls @yeger/turbo-graph. Until patched, restrict inbound access to TCP port 29312 with a host firewall so only the local machine can reach /api/run, run the tool only on trusted networks, and stop the dev server when it is not in use. Also review recent task runs and deployments in affected repositories for signs of unauthenticated triggering.

CVE-2026-59973 is a server-side request forgery (CWE-918) bypass of the previously published fix (GHSA-v6ph-xcq9-qxxj / CVE-2026-39885) for external $ref dereferencing in the mcp-from-openapi dependency used by FrontMCP's OpenAPI adapter. The fix added a denylist check on the parsed URL hostname string, but mcp-from-openapi 2.3.0 still does not resolve hostnames before validating, does not pin the validated IP to the fetch, does not revalidate redirect targets, and misses IPv4-mapped IPv6 loopback forms, so semantically equivalent loopback targets such as 127.0.0.1.nip.io, redirectors to 127.0.0.1, and [::ffff:127.0.0.1] still cause backend requests to localhost. An attacker who can cause a hosted or multi-user FrontMCP deployment to load an untrusted OpenAPI spec (via the adapter's untrusted url, spec, and loadOptions.refResolution inputs to OpenAPIToolGenerator.fromURL()/fromJSON()) can trigger requests from the server to loopback or private internal services during tool generation, yielding high confidentiality impact and limited integrity impact per the 8.5 CVSS score. Affected are FrontMCP deployments up to and including the latest release v1.2.1 and current main, as well as any direct consumer of npm mcp-from-openapi up to 2.3.0. No public proof-of-concept, KEV listing, or known in-the-wild exploitation is reported.

Do: Until fixed releases beyond FrontMCP 1.2.1 and mcp-from-openapi 2.3.0 are available, avoid loading untrusted OpenAPI specs or disable external $ref resolution (refResolution) for untrusted specs, and block backend egress to loopback, link-local, and RFC1918 ranges at the network layer. Watch for patched versions of mcp-from-openapi that resolve and pin IPs and revalidate redirect targets before the fetch. Audit whether your FrontMCP deployment accepts user-supplied url or spec values in the OpenAPI adapter, as that is the required attack precondition.

CVE-2026-59965 is an authorization bypass (CWE-863) in version 0.7.0 of the npm package @jhb.software/payload-alt-text-plugin, a plugin that adds AI-generated alt-text endpoints to Payload CMS v3 projects. The plugin's POST /api/alt-text-plugin/generate and /bulk endpoints call the Payload Local API (findByID and update) without setting overrideAccess: false, and Payload's internal logic treats an omitted parameter as overriding access, so the collection's read and update access functions are never invoked. As a result, any authenticated user — regardless of role — can read and overwrite the alt and keywords fields on upload documents in any collection, even those protected by restrictive, admin-only access rules. Anyone running a Payload CMS v3 project with the vulnerable plugin version installed is affected, and impact is limited to confidentiality and integrity of these metadata fields (CVSS 7.1, C:L/I:H/A:N). There is no known public proof-of-concept, it is not in CISA's KEV catalog, and no in-the-wild exploitation has been reported.

Do: Check for and upgrade to a release of @jhb.software/payload-alt-text-plugin newer than 0.7.0 once a patched version is published, since the advisory does not name a fixed version. As interim mitigation, restrict which authenticated users can reach /api/alt-text-plugin/generate and /bulk, or treat collection-level read/update access rules on upload collections as not enforced for the alt and keywords fields. Review upload-collection documents for unexpected changes to alt and keywords metadata made by non-admin accounts.

@argos-ci/[email protected] is vulnerable to OS command injection (CWE-78): the CI branch/ref string, sourced unvalidated from the CI environment (e.g., GITHUB_HEAD_REF on GitHub Actions), is interpolated directly into an execSync() template literal in packages/core/src/ci-environment/git.ts, which executes it via /bin/sh -c so metacharacters like $() or backticks are evaluated as shell commands. The vulnerable path is reached when the Argos API reports hasRemoteContentAccess: false, causing the upload flow to call getMergeBaseCommitSha(), which passes the unsanitized branch name as the ref to gitFetch()'s `git fetch` command; a secondary sink exists in a `git merge-base` call. An attacker who can influence a project's branch name, for example by opening a pull request with a crafted branch name containing shell metacharacters, gains arbitrary OS command execution on the CI runner. Projects running @argos-ci/core 6.2.0 in CI where branch names can be attacker-controlled and remote content access is disabled are affected. There is no known public proof-of-concept, the issue is not in CISA KEV, and no in-the-wild exploitation is known.

Do: Upgrade to a patched @argos-ci/core release when one becomes available; the recommended fix is to replace template-literal execSync() calls with execFileSync() using argument arrays so the shell is bypassed entirely. As interim mitigations, allowlist or sanitize the CI branch name (e.g., reject shell metacharacters in GITHUB_HEAD_REF) or ensure the Argos project has remote content access so the getMergeBaseCommitSha() path is not taken. Review CI runner logs and stored secrets for signs of command execution triggered by attacker-crafted pull-request branch names.

yayson, an npm library for parsing JSON:API documents, is vulnerable to prototype pollution (CWE-1321) because Store and LegacyStore key their internal lookup tables with attacker-controlled 'type', 'id', and relationship-name strings from the document, using plain objects as the maps. A document whose type is '__proto__' — including one arriving as an 'included' resource referenced through a relationship, which bypasses any data.type allow-list — makes Store.sync() write onto Object.prototype, polluting every object in the Node.js process for its lifetime; LegacyStore is additionally reachable when a configured types mapping resolves to '__proto__'. An attacker gains at minimum process-wide denial of service or logic corruption, with escalation to authorization bypass or RCE possible only if the consuming application exposes exploitable gadgets. Any Node.js application using yayson 3.x or 4.x (<= 4.2.0) that deserializes untrusted JSON:API documents is affected. No public proof of concept or in-the-wild exploitation is known and the flaw is not in CISA KEV; severity is High (suggested CVSS v3.1 8.1 from the supplied vector, though the record also carries a 9.1 Critical rating).

Do: Upgrade to yayson 4.3.0, which uses null-prototype lookup tables and rejects '__proto__', 'constructor', and 'prototype' as document-derived member names. As interim mitigation, reject documents whose type or relationship names are '__proto__', 'constructor', or 'prototype', and/or run Node with --disable-proto=throw. Audit whether attacker-controlled JSON:API payloads reach Store.sync()/LegacyStore.sync() and whether attacker-chosen polluted keys could influence security-sensitive logic in your application.

OmniRoute, an open-source AI gateway that exposes a single endpoint for multiple model providers, allows remote code execution through its POST /api/acp/agents custom ACP agent endpoint, where attacker-controlled binary and versionCommand values pass only a self-consistency check before being handed to execFileSync. The tokenizeVersionCommand function and DISALLOWED_VERSION_COMMAND_CHARS filter block only a limited set of shell metacharacters, so an attacker can still supply interpreter evaluation arguments that execute arbitrary code, and /api/acp/ is absent from the LOCAL_ONLY_API_PREFIXES and SPAWN_CAPABLE_PREFIXES restrictions. When requireLogin is false, or during the bootstrap window of a freshly started instance, an anonymous remote request is sufficient to execute arbitrary code in the server container; with requireLogin=true and a management password configured, the attacker instead needs a management session or a management-scoped API key. All deployments running version 3.8.49 or earlier are affected, with self-hosted instances that leave requireLogin disabled or are briefly exposed during startup at greatest risk. No fixed version is available yet, and no public proof-of-concept, in-the-wild exploitation, or KEV listing is known as of this review.

Do: Because no patched release exists yet, enable requireLogin with a strong management password on every OmniRoute instance and confirm that all /api/acp/ traffic requires a management session or management-scoped API key. Restrict the gateway container's network exposure (bind to localhost or firewall it) so anonymous clients cannot reach POST /api/acp/agents, and treat fresh-instance startup as a sensitive window. Monitor the upstream project for a fixed version and upgrade as soon as one is published, and review container logs for unexpected interpreter executions triggered by versionCommand values.

Angular's server-side rendering stack (@angular/platform-server) fails to escape matching closing tags when serializing untrusted input inside template content nested in fallback raw-content elements such as noscript, iframe, noembed, and noframes, because the Domino serializer's fallbackRawContentTags traversal stops at the DocumentFragment representing template.content. An attacker who can influence interpolated values — or, unconditionally, when DOM nodes are constructed imperatively via Renderer2 — can craft input whose closing tag terminates the fallback container under HTML5 RAWTEXT parsing, causing trailing markup to be interpreted as active DOM elements. Successful abuse yields arbitrary JavaScript execution (cross-site scripting) in the browser of a user who loads the server-rendered page, consistent with the CVSS 4.0 score of 8.6, which requires user interaction. Any application using Angular SSR on versions prior to 20.3.30, 21.2.22, or 22.1.4 is affected; the bug is reachable via standard interpolation through comments or text nodes without relaxed schemas, while literal xmp or style usage additionally requires CUSTOM_ELEMENTS_SCHEMA or NO_ERRORS_SCHEMA. No public proof-of-concept or confirmed in-the-wild exploitation is known, and the issue is not listed in CISA's KEV catalog.

Do: Upgrade Angular to 20.3.30, 21.2.22, or 22.1.4 to match your major release line. Audit SSR templates for interpolation of untrusted values inside noscript, iframe, noembed, or noframes fallback content and review any Renderer2-based imperative DOM construction, HTML-encoding or sanitizing untrusted values before they reach those containers as an interim mitigation. Note that relaxed schemas (CUSTOM_ELEMENTS_SCHEMA / NO_ERRORS_SCHEMA) with literal xmp or style elements widen the attack surface and should be checked explicitly.

The @openhop/server npm package passes unsanitized Fastify route parameters directly into path.join() when constructing filesystem paths for flow YAML files, allowing path traversal (CWE-22). An unauthenticated attacker sends GET or DELETE requests to /api/flows/:id with URL-encoded traversal sequences (e.g., ..%2F), which are decoded by the router and normalized by path.join() to escape the configured flow directory, yielding arbitrary .yaml file reads and arbitrary .yaml file deletions anywhere the process can reach. Because the server sets CORS to allow any origin, a victim's browser can be tricked into attacking a loopback-bound instance, and Docker deployments that bind HOST=0.0.0.0 by default are directly reachable over the network, which drives the High 8.3 CVSS score (network vector, no privileges, user interaction for the CORS-based vector, high impact on integrity and availability via file deletion). Anyone running the affected server is at risk, with Docker deployments and locally-running instances exposed through distinct paths. There is currently no known public proof-of-concept and the flaw is not in the CISA KEV catalog.

Do: Upgrade to a patched @openhop/server release as soon as one is published, since no fixed version is identified in the available data. Until patched, restrict network exposure (bind to loopback rather than 0.0.0.0 in Docker, use a firewall or reverse-proxy allowlist) and consider validating the :id route parameter against a strict pattern that rejects path separators and '..' sequences. Check audit logs for unauthenticated GET/DELETE requests to /api/flows/ containing encoded slashes or dot-segments, and verify that no unexpected .yaml files outside the flow directory have been read or deleted.

The `set_functype_version` tool in the npm package functype-mcp-server accepts an unvalidated `version` string, interpolates it into the npm specifier `functype@<version>`, and passes it to `pnpm add`, so alias syntaxes such as 'file:' or 'npm:' let the caller install an arbitrary local or remote package under the `functype` name. Any attacker who can get a 'tools/call' request to this MCP tool can trigger it; the tool is registered by default and requires no authentication in stdio mode. Immediately after installation the server calls initDocsData(true), which dynamically imports functype/cli from the newly installed package, executing attacker-controlled module-level JavaScript in the MCP server process and yielding full RCE with that process's privileges (CVSS 3.1 7.8 High, high confidentiality/integrity/availability). Only developers or teams running functype-mcp-server with an MCP client are affected; the vulnerable code is in packages/mcp-server/src/index.ts and maps to CWE-829 (inclusion of functionality from an untrusted control sphere). No public proof-of-concept or in-the-wild exploitation is known, and the issue is not listed in CISA's KEV catalog.

Do: Until a patched release is identified (none is specified in the current data), restrict or disable the set_functype_version tool in MCP client configurations, and validate the version parameter against a strict semver/dist-tag allowlist before it reaches pnpm add. Audit affected machines by checking whether the functype entry in the project's node_modules resolves to an unexpected local path or unrelated package, and review logs for pnpm add invocations originating from MCP tool calls. Monitor the functype-mcp-server npm feed and repository for a fixed version and upgrade as soon as one is published.

nuxt-ollama version 1.2.26 unconditionally merges all module options, including the cloud-only ollama.api_key credential, into Nuxt's public runtime config (runtimeConfig.public.ollama). Because Nuxt serializes runtimeConfig.public into the window.__NUXT__ payload embedded in every server-rendered HTML page, any unauthenticated visitor can read the API key in plaintext with a single HTTP GET of the page. An attacker who captures the key can issue arbitrary Ollama API requests under the operator's account, consuming cloud model usage at the operator's expense. Only Nuxt applications that use the nuxt-ollama module and configure api_key for Ollama cloud (as the module's own documentation instructs) are affected; deployments targeting a local Ollama server without an api_key leak no secret. No public proof-of-concept, CISA KEV listing, or in-the-wild exploitation reports are known; the issue is a code-level design flaw with a CVSS 3.1 score of 7.5 (high, confidentiality only).

Do: Upgrade nuxt-ollama to a patched release once published, and rotate any Ollama cloud API keys that were configured through this module. Until patched, check exposure by viewing the source of a server-rendered page and looking for the ollama api_key inside window.__NUXT__, and keep the credential out of runtimeConfig.public (serve it only server-side or strip it from the public namespace). Any key found leaking should be rotated immediately, since anyone who previously fetched the page could have captured it.

n8n, an open-source workflow automation platform, is affected by an expression-sandbox escape (CWE-94, code injection): the expression compiler's PrototypeSanitizer (packages/workflow/src/expression-sandboxing.ts) resolved through dynamically scoped 'this' and did not reject reserved class member names. An attacker who can supply workflow expressions, typically an authenticated user with permission to create or edit workflows, can define a class field named '__sanitize', which rebinds the sanitizer and lets the expression code reach the Function constructor. Successful exploitation gives JavaScript-driven backend code execution on the n8n server as well as JavaScript execution in the editor preview, with high impact on confidentiality and integrity (CVSS 4.0 score 8.7, High). All n8n deployments running versions prior to 1.123.76 on the 1.x line, or prior to 2.37.7 / 2.38.2 on the 2.x line, are affected until patched. No public proof-of-concept, CISA KEV listing, or confirmed in-the-wild exploitation is known, and EPSS currently estimates only a 0.3% probability of exploitation within 30 days.

Do: Upgrade n8n to 1.123.76 (1.x line) or 2.37.7 / 2.38.2 (2.x line). Until patched, restrict workflow creation and expression editing to trusted users, since exploitation requires the ability to supply expressions, and audit workflows for class fields named '__sanitize'. Because editor-preview execution is also affected, review which users open shared or untrusted workflows in the editor.

n8n, an open source workflow automation platform, is vulnerable to a regular expression denial-of-service flaw (catastrophic backtracking, CWE-1333) in the Git node's clone operation. When a workflow using the Git node clone runs, the attacker-controlled destination path is matched against the default N8N_BLOCK_FILE_PATTERNS regular expression (declared in packages/@n8n/config/src/configs/security.config.ts), whose pattern ^(./).git(/.)$ allows catastrophic backtracking and executes synchronously in the main n8n process. An authenticated workflow editor can therefore freeze the entire instance with a single workflow execution, causing denial of service with no confidentiality or integrity impact (CVSS 4.0: 7.1 High). All n8n deployments prior to versions 1.123.76, 2.37.7, and 2.38.2 are affected, particularly self-hosted instances that allow non-admin users to create and run workflows. No public proof-of-concept or in-the-wild exploitation is known; EPSS currently estimates a 0.3% chance of exploitation within 30 days and the issue is not in CISA KEV.

Do: Upgrade n8n to version 1.123.76, 2.37.7, or 2.38.2 (or later). Until patched, restrict workflow creation/editing to trusted users and review whether any user-authored workflows invoke the Git node's clone operation; as an interim mitigation, consider overriding the default N8N_BLOCK_FILE_PATTERNS setting with a non-backtracking expression. There is no evidence of active exploitation, but exposed instances that allow untrusted editors should be patched promptly.

smol-toml, a TOML parser and serializer distributed via npm, contained a denial-of-service flaw (fixed in 1.7.1) in which parse() enters an infinite loop when a value inside an array or inline table is followed by a comment that has no trailing newline. In that case skipUntil() calls indexOfNewline(), which returns -1 at the end of input, and the helper resets the scan cursor to the beginning of the string, so the parser hangs indefinitely. An attacker who can supply TOML input to an application running an affected version gains a remote denial of service, hanging the process and consuming the service's processing capacity; the CVSS 4.0 score of 8.2 reflects high availability impact with no confidentiality or integrity impact. Any npm application or service that parses attacker-controlled TOML with smol-toml prior to 1.7.1 is affected. Exploitation has not been observed: there is no known public proof-of-concept, the flaw is not in CISA's KEV, and EPSS estimates a 0.4% probability of exploitation within 30 days.

Do: Upgrade smol-toml to 1.7.1 or later, including updating lockfiles where it appears as a transitive dependency (search npm/yarn/pnpm lockfiles for smol-toml). Until patched, avoid parsing untrusted TOML with affected versions, or pre-screen/reject input containing comments without a trailing newline inside arrays or inline tables, and consider enforcing a parse timeout. Note the trigger condition when reviewing any service that accepts TOML configuration or user-supplied TOML input.

node-csv is a full-featured CSV parser with a simple API that is tested against large datasets. Prior to 7.0.2, csv-parse with the columns and group_columns_by_name options enabled treats a duplicate __proto__ header as an existing property in packages/csv-parse/lib/api/index.js, assigns an attacker-controlled array through obj['__proto__'], and replaces the parsed record object's prototype. A malicious CSV header can therefore inject inherited array values into the returned record, hide those inherited values from JSON serialization, and affect property enumeration and type or shape checks in applications that process the record. This issue is fixed in version 7.0.2.

Colord is a tiny yet powerful tool for high-performance color manipulations and conversions. Prior to 2.9.4, synchronous CSS color string matchers in src/colorModels/rgbString.ts, src/colorModels/hslString.ts, src/colorModels/hwbString.ts, src/colorModels/lchString.ts, and src/colorModels/cmykString.ts use the ambiguous numeric regular expression ([+-]?\d*.?\d+), allowing the same digits to be divided between overlapping quantifiers in quadratically many ways when malformed input is rejected. An attacker who can supply an unbounded color string to colord(), getFormat(), isEqual(), mix(), or contrast(), including through a request body, JSON field, or uploaded stylesheet, can block the processing thread with a multi-kilobyte payload. The affected matchers are parseRgbaString, parseHslaString, parseHwbaString, parseLchaString, and parseCmykaString. This issue is fixed in version 2.9.4.

MapLibre GL JS, an interactive vector tile map library for web browsers distributed via npm, contains a cross-site scripting flaw (CWE-79) in DOM.sanitize() in src/util/dom.ts: the code iterates elem.attributes as a live NamedNodeMap while removeAttributes() deletes entries from that same collection, shifting indexes and skipping an adjacent dangerous attribute. An attacker who controls untrusted third-party style attribution strings or user-supplied custom attributions can supply consecutive dangerous attributes, so an event-handler attribute such as onload or ontoggle survives sanitization. The surviving attribute executes when the attribution control inserts the content into the page via innerHTML and the victim renders the affected map content — no interaction beyond viewing the map is required, which is why coverage describes it as a zero-click XSS. Any website or application embedding a vulnerable MapLibre GL JS version and rendering attacker-influenced attributions is affected; successful exploitation gives the attacker arbitrary JavaScript execution in the trusted site's origin, useful for credential/session theft or content manipulation. Exploitation is not yet confirmed: no public proof-of-concept is known, the flaw is not in CISA KEV, and EPSS estimates only about a 0.3% probability of exploitation within 30 days, despite the critical CVSS 3.1 score of 10.

Do: Upgrade to MapLibre GL JS 6.4.1 or later, which fixes the live NamedNodeMap iteration bug in DOM.sanitize(). In the interim, strip or validate event-handler attributes (e.g., onload, ontoggle) from third-party style attribution strings and user-supplied custom attributions before they reach the map library, and check npm lockfiles for maplibre-gl versions below 6.4.1.

CVE-2026-77465 is an uncontrolled recursion flaw (CWE-674) in toml-node, a TOML parser for Node.js and the browser: the Peggy 5.1.0-generated recursive-descent parser in lib/parser.js recurses through nested arrays and inline tables (peg$parsevalue, peg$parsearray, peg$parseinline_table_entry) with no depth limit. A remote, unauthenticated attacker who can make an application parse an attacker-controlled TOML document — for example via an API endpoint, uploaded config, or message body — can include a few thousand nested arrays or inline tables to exhaust the Node.js call stack. The failure surfaces as an unexpected RangeError instead of the parser's normal SyntaxError, which can terminate an unprotected request worker or the entire process, resulting in denial of service (no confidentiality or integrity impact). Any application or service running toml-node prior to version 4.2.0 to parse untrusted TOML is affected; the fix is in version 4.2.0. There is currently no known exploitation, no public proof-of-concept, and no CISA KEV listing, with EPSS estimating roughly a 0.4% chance of exploitation within 30 days.

Do: Upgrade to toml-node 4.2.0 or later (update the "toml" npm dependency, including transitive usage — check with npm ls toml). As interim mitigation, pre-validate or cap the nesting depth of untrusted TOML input before calling toml.parse(), and run parsing in an isolated worker so a RangeError-driven crash cannot take down the main process or request worker.

stream-json is a micro-library of stream components for processing JSON and JSONC with a minimal memory footprint. Prior to 3.5.0, the path filters pick, ignore, filter, and replace in src/core/filters/filter-base.js recompute the full path string from the nesting stack for every checkable token. Because the stack length equals the current nesting depth and a checkable token is emitted at every level, a depth D document costs O(D²) rather than O(D) to process. The issue is triggered by nesting depth rather than byte volume, including the documented pick({filter: 'data'}) traversal-until-match path, so an application that sends untrusted JSON through a string or RegExp filter can block the Node.js event loop and cause denial of service with a small deeply nested document. The streamArray, streamObject, and streamValues streamers are not affected because they use the constant-time asm.depth getter. This issue is fixed in version 3.5.0.

CVE-2026-63376 is a prototype pollution vulnerability (CWE-1321) in the npm 'toml' package (toml-node): toml.parse() writes attacker-controlled keys onto Object.prototype, corrupting every ordinary JavaScript object in the process. Although the compiler shields the tables it builds with Object.create(null), the deepRef path resolver fails to reject descent through an existing scalar value because its duplicate-key tracking strings desynchronize from the keys actually used during traversal; a crafted table header such as [a.b.y.__proto__.__proto__] (where a.b.y = 1) therefore walks the native prototype chain onto Object.prototype, after which all subsequent key/value pairs pollute it, including injection of nested gadget objects. An attacker who can get malicious TOML parsed by a server or application gains arbitrary global property injection — high integrity impact per the CVSS 3.1 score of 8.2 — which can alter program logic via polluted properties or gadgets and cause availability loss, with no confidentiality impact. Any Node.js project that parses untrusted or semi-trusted TOML with this package is exposed; version 4.1.1, the latest at the time of disclosure, is vulnerable, and the source data identifies no fixed version or affected range. No exploitation in the wild is known (absent from CISA KEV, EPSS about 0.4% at the 32nd percentile), and no public proof of concept is tracked beyond the reproduction steps in the advisory.

Do: Audit your dependency tree for npm 'toml' (e.g., npm ls toml) and determine whether any service parses attacker-supplied TOML with it; upgrade to a patched release when one is published, verifying against the npm security advisory since no fixed version is named in the source data. Until patched, avoid parsing untrusted TOML with toml.parse(), reject or sanitize table headers and dotted keys containing __proto__ segments before parsing, and consider freezing Object.prototype as defense-in-depth. Watch downstream services for pollution symptoms such as unexpected inherited properties, logic anomalies, or crashes.

Astro is a web framework for content-driven websites. Prior to 7.2.4, Astro stripped a configured non-root base path from request pathnames using a string-prefix check without verifying a path-segment boundary. With base "/app", a request to "/appX/admin" resolved internally to the protected "/admin" route while middleware observed "/appX/admin" in context.url.pathname. In applications that authorize base-prefixed routes by inspecting context.url.pathname, an unauthenticated remote attacker could bypass pathname-based middleware authorization and reach protected routes. This issue is fixed in version 7.2.4.

TOON, an npm library for compact, human-readable serialization of JSON-like data used in LLM prompts, is vulnerable to prototype pollution (CWE-1321): before version 2.3.1, decoding attacker-controlled TOON containing __proto__, constructor, or prototype keys wrote through the object prototype chain and polluted Object.prototype for the entire runtime instead of creating an own property. The strongest vector is dotted keys such as a.__proto__.x handled by the expandPaths 'safe' path and insertPathSafe function, while plain nested objects, tabular rows, quoted keys, and streaming decode are also affected, and the encoder additionally drops own __proto__ properties and can invoke an inherited setter during normalization. An attacker who can feed crafted TOON to a decoding service gains denial of service in any application, and potentially remote code execution when a suitable downstream gadget is present. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation is reported, and EPSS currently estimates only a 0.4% probability of exploitation within 30 days.

Do: Upgrade the toon npm package to version 2.3.1 or later. Audit whether your services decode TOON from untrusted sources (e.g., user-supplied or model-generated prompt data), and until patched, strip or reject keys named __proto__, constructor, or prototype, or decode into null-prototype objects with schema validation. Also review downstream code (merge/mass-assignment patterns) for gadgets that could escalate Object.prototype pollution into remote code execution.

js-yaml, a widely used npm YAML parser, has a resource-exhaustion flaw (CWE-400/CWE-407) in its YAML merge-key processing: the maxTotalMergeKeys budget does not count empty mappings ({}), so the configured limit is never reached while CPU work accumulates. An attacker who can submit a crafted YAML document — an anchored array of many empty mappings that is merged (<<) by many targets — forces O(N×K) processing that scales far beyond the document's size (e.g., ~500 KB of YAML taking ~13 seconds to parse, versus ~13 KB taking ~20 ms). The impact is denial of service through prolonged CPU consumption, with no confidentiality or integrity effect (CVSS 3.1 7.5, availability only). Any Node.js application or service that parses untrusted YAML with js-yaml is exposed, with the highest default exposure in v3 and v4 where merge processing is enabled by default; in v5 the flaw applies when merge keys are used. No exploitation is currently known: the flaw is absent from CISA KEV, no public PoC is catalogued, and EPSS estimates only a ~0.4% probability of exploitation within 30 days.

Do: Upgrade js-yaml to a release containing the fix (each merge-source mapping counted as one budget unit) as soon as it is published; the available data does not name the fixed version, so track the project's advisory. Until then, limit the size and complexity of YAML accepted from untrusted sources, avoid exposing merge-key (<<) processing to untrusted input where the schema is configurable, and add parse timeouts or resource limits around YAML loading. Audit your dependency tree for js-yaml on any code path that parses untrusted YAML.

Vitest is a testing framework powered by Vite. From 2.1.0 until 4.1.11 and 5.0.0-rc.2, the public mockerPlugin and standalone interceptorPlugin exports in packages/mocker/src/node/interceptorPlugin.ts register the vitest:interceptor:register handler on Vite's unauthenticated HMR WebSocket without validating redirect targets against the file-serving allowlist. The implementation processes event.redirect without enforcing server.fs.allow and server.fs.deny through isFileLoadingAllowed. A remote client that can reach an exposed development server can submit an opaque URL scheme preserving .. segments, causing join(server.config.root, redirectUrl.pathname) to resolve outside the project root. The plugin's load hook then returns readFile(mock.redirect, 'utf-8') as module source, disclosing local files readable by the dev-server process. Vitest browser mode uses a token-authenticated RPC and is not remotely unauthenticated by default, although the same boundary check was missing on that path. This issue is fixed in versions 4.1.11 and 5.0.0-rc.2.

Next.js, the widely used React web framework published on npm, contains an unauthenticated remote code execution vulnerability classified as CWE-22 (path traversal) and rated critical at CVSS 9.0. The flaw affects applications built with the Pages Router or App Router that do not use Cache Components, and it is triggered only when the server runs on a machine with a Windows filesystem; a remote, unauthenticated attacker can reach it over the network, though exploitability is rated high attack complexity. Successful exploitation yields code execution with high impact to confidentiality, integrity, and availability, and the scope is changed, meaning impact extends beyond the vulnerable component. Only teams self-hosting Next.js on Windows servers are affected; deployments on Linux, macOS, or Vercel's managed infrastructure are not. There is currently no public proof-of-concept, the flaw is not in the CISA KEV catalog, and EPSS assigns a 1.1% probability of exploitation within 30 days, but no workaround exists, so upgrading is the only mitigation.

Do: If your Next.js server runs on Windows, upgrade immediately to the latest patched release — the advisory does not specify a fixed version, so check the official Next.js security advisory — since there is no known workaround. Deployments hosted on Linux, macOS, or Vercel's managed platform are not affected. Audit your deployments to confirm whether they use the Pages Router or App Router without Cache Components on a Windows filesystem to determine true exposure.

CVE-2026-84370 is a cross-site scripting flaw (CWE-79/CWE-184) in the SVGO (SVG Optimizer) npm package, in the opt-in removeScripts plugin — named removeScriptElement in versions 2 and 3 — which incompletely filters executable links in plugins/removeScripts.js and lib/svgo/tools.js. The plugin fails to recognize namespace-prefixed anchor elements (such as svg:a with href or namespaced *:href values) and does not strip ASCII tab, line-feed, or carriage-return characters before checking URL schemes; because browsers remove those characters when parsing the scheme, a crafted executable link survives optimization. When an application processes attacker-controlled SVG with the plugin enabled and serves the result in an active browser context, a victim who activates the surviving link executes script in the SVG's origin, allowing data exposure, content modification, or actions performed as the victim. Any npm-based application, CLI workflow, or build pipeline using SVGO from version 1.0.0 up to the fixed versions with the plugin enabled is affected. Exploitation is not currently observed: the issue is not in CISA KEV, no public proof-of-concept is known, and EPSS estimates a 0.3% probability of exploitation in the next 30 days.

Do: Upgrade SVGO to at least 2.8.4 on the 2.x line, 3.3.5 on the 3.x line, or 4.1.0 on the 4.x line. If upgrading is not immediate, disable the opt-in removeScripts/removeScriptElement plugin for untrusted SVG input, or avoid serving its output in an active browser context. Audit dependency and configuration files (e.g., imagemin/svgo wrappers) to find where the plugin is enabled implicitly, and run a dependency scan for vulnerable SVGO versions.

joi is a schema description language and data validator for JavaScript. From 16.0.0 until 17.13.6 and 18.2.5, the @hapi/joi package through 17.1.1 and the successor joi package contain prototype pollution in lib/messages.js, where exports.compile() and exports.merge() reuse inherited objects for attacker-controlled language keys supplied through messages(), message(), prefs({ messages }), Joi.extend({ messages }), or rule({ message }). A language key named __proto__ writes properties onto Object.prototype, and constructor writes to the Object function's static properties. A consuming application that gates on the presence of an inherited property can take the wrong branch for every inspected object. The flaw is not reachable from data that joi validates and requires an application to feed untrusted input directly into schema-construction configuration. This issue is fixed in joi versions 17.13.6 and 18.2.5; no fixed @hapi/joi version is available.

joi is a schema description language and data validator for JavaScript. From 16.0.0 until 17.13.5 and 18.2.4, joi's lib/types/keys.js internals.rename() implementation used by object().rename() permits a schema that renames keys with a regular-expression source and a Joi.expression() or Joi.x() target that interpolates the pattern's own match data, combined with { multiple: true }, to derive a target from an attacker-controlled input key. An attacker can send x-__proto__ with an object value, causing the target to render as __proto__ and set the prototype of the object returned by validate() instead of creating an own key. The global Object.prototype is not modified, so the effect is confined to the object returned by that validation call. Static-string targets and schemas using the default { multiple: false } are not affected. This issue is fixed in versions 17.13.5 and 18.2.4.

Hono is a Web application framework that provides support for any JavaScript runtime. From 4.12.12 until 4.13.5, the fix released for CVE-2026-39408 does not cover every traversal sequence, and toSSG() can still write files outside the configured output directory when a route parameter contains consecutive parent-directory segments. Static site generation builds each output path from the route path and values supplied through ssgParams, then verifies that the result stays inside the output directory using the same normalization routine that built the path. That routine does not fully collapse runs of consecutive parent-directory segments, allowing a path that the check accepts to resolve outside the output directory, and the check also treats output directories that differ in how they are rooted as equivalent. This arises when an application generates a static site from route parameter values it does not fully control, such as slugs from a CMS, API, or user submission. An untrusted ssgParams value can create or overwrite files elsewhere in the build environment and alter generated artifacts or deployment output. The vulnerability affects build-time static site generation only; request-time routing and applications with entirely developer-controlled ssgParams values are not affected. This issue is fixed in version 4.13.5.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to 4.13.5, when parseBody() expands dot-separated form field names into nested objects with dot-notation parsing enabled, it does not limit the nesting depth or the total number of intermediate objects created. Empty segments are preserved, so one deeply dotted field name can encode one nesting level per byte, while a large number of shallowly dotted fields can create the same amplification across a request. A request body within a normal size limit can therefore allocate an object graph far larger than the request after the body has already been accepted. An unauthenticated attacker who can reach an affected endpoint can send concurrent requests that exhaust the JavaScript heap, terminate the server process, and leave the service unavailable until restart. Dot-notation parsing is not enabled by default, and applications using the default behavior are not affected. This issue is fixed in version 4.13.5.