GitLab MCP server's read-only mode falls to a stray comma

Three GitHub security advisories published on 15 September 2026 describe multiple ways to defeat the safety controls in @zereight/mcp-gitlab, an npm package from the maintainer zereight that exposes GitLab to a large language model agent over the Model Context Protocol. One of the flaws, a server-side request forgery issue tracked as CVE-2026-61559, was rated high with a CVSS v3.1 score of 8.5 and had no patched version at the time of the report.

The first advisory, GHSA-5648-rgj9-v224, covers five separate defects found during a source review of commit 60adcc0, corresponding to package version 2.1.28. The reviewers note that the server relies on read-only mode, a project allow-list and transport authentication as its safety controls, and that under the MCP threat model tool-call arguments can be shaped by untrusted input through prompt injection or by a malicious client.

The most striking finding is a read-only bypass in the execute_graphql tool. The server strips comments and strings from a GraphQL document, then uses a regular expression to look for write operations. Because GraphQL treats commas as insignificant and the stripping function does not remove them, a document that begins with a comma before the word "mutation" is classified as read-only but still executes as a write, according to the advisory. The same handler never checks project scope, so a raw GraphQL body reaches the API with the server's token against any project that token can access, regardless of the GITLAB_ALLOWED_PROJECT_IDS allow-list.

The advisory also reports that the startup check which forces remote authorisation does not fire when the server is started with a cookie path or OAuth, leaving every caller of the /mcp endpoint unauthenticated while the server attaches its own live session upstream. Server-sent events are unauthenticated by default with no Origin or Host validation. A fourth defect allows an unauthenticated session-exhaustion denial of service: token validation only checks that a string is at least 20 characters and uses the right character set, so roughly 1,000 requests with garbage tokens fill all session slots for the default one-hour timeout and legitimate users receive a 503 error. Finally, continuous integration job traces are returned to the model verbatim, which the advisory describes as a prompt-injection surface that can be chained with the read-only bypass to reach writes.

The second advisory, GHSA-vmp7-252j-cwp7 or CVE-2026-61568, says the Streamable HTTP endpoint in version 2.1.18 is created without the SDK's DNS-rebinding protection and with no Host or Origin allow-list, and that the default bind address is loopback. A malicious web page can therefore reach a victim's local listener with attacker-controlled headers. The advisory says that in multi-user mode an unauthenticated tools/list call is still rejected with a 401, but the initialize request is processed rather than refused as cross-origin localhost access.

The third advisory, GHSA-2h44-8472-frjj or CVE-2026-61559, concerns the optional ENABLE_DYNAMIC_API_URL feature. The server reads an X-GitLab-API-URL request header, checks only that it parses as a URL, and then sends the victim's GitLab token to that host. "The attacker never needed it in advance. The MCP server delivered it," the advisory states. It says the issue was reported on 7 June 2026 and that a merged startup guard does not address the runtime token-forwarding path. The recommended fix is a hostname allow-list applied at both affected code locations.