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.