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.

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.