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.