CVE-2026-61560: How an Unauthenticated MCP Default Turned a File-Upload Tool Into Full GitLab Account Takeover

On September 15, 2026, a critical CVE dropped for one of the most-used GitLab MCP servers — and the exploit chain reads like a checklist of every default a self-hosted platform should never ship. No authentication on the network transport. No sanitization on a file-path parameter. The server's own GitLab credential sitting in process memory, one file read away. Chained together, any attacker who can reach the port walks away with full GitLab account takeover. CVSS 9.8. No user interaction. Here is exactly how it works, and the hardening checklist it implies for every MCP server on your own fleet.

Four steps to account takeover​

The vulnerable package is @zereight/mcp-gitlab (CVE-2026-61560, CVSS 9.8, published September 15, 2026), a Model Context Protocol server that lets AI agents drive GitLab — list projects, read merge requests, upload files. Every version before 2.1.27 is affected; the fix shipped in 2.1.27 alongside GHSA-cv3r-c5h8-f4g5 and three patch PRs. If you run it, the remediation is one line: upgrade to 2.1.27 or later and set SSE_AUTH_TOKEN on any SSE deployment. Now the chain, in the order an attacker walks it:

1. Reach the SSE endpoint. In SSE transport mode (SSE=true — the default for Docker deployments), the server exposes every MCP tool with zero authentication. No token, no login, no handshake. If the port is network-reachable, you are in.
2. Call upload_markdown with file_path=/proc/self/environ. The tool reads an arbitrary server-local file through an unsanitized file_path parameter (CWE-22, path traversal) and uploads its contents to a GitLab project. Point it at the process environment block and the server cheerfully exfiltrates its own secrets — to a project the attacker can read.
3. Lift GITLAB_PERSONAL_ACCESS_TOKEN from the upload. The server's GitLab credential lives in its own environment, so it is sitting in /proc/self/environ in plain text. The attacker now holds the token.
4. Authenticate as the victim. With the personal access token, the attacker has the victim's full GitLab account: read and write every accessible repo, approve merge requests, exfiltrate CI variables. Takeover complete.

Note what made step 2 elegant from the attacker's perspective: the exfiltration channel is a legitimate feature. Nothing about "upload a markdown file to GitLab" looks anomalous in a log. The tool did exactly what it was built to do — it just never asked who was asking, or whether the file was one it should have been allowed to touch.

Anatomy of the chain: three links, each necessary​

Every link in this chain is individually a known-bad practice. What earns the 9.8 is that all three shipped in the same default configuration, so removing any single one breaks the exploit:

This table is also the shape of the defense: you want all three rows fixed, because each row is a backstop for the other two. Auth on the transport protects you when (not if) a tool has an input-validation bug. Sandboxing file access protects you when (not if) an endpoint ends up more reachable than you planned. And keeping high-value credentials out of the process environment shrinks what any single file-read primitive can ever yield.

The uncomfortable corollary: most self-hosted MCP servers on most fleets today fail at least one of these rows. The transport ships open because "it's only on localhost." The file tool takes a raw path because "the agent needs flexibility." The token is in environ because "that's how the SDK reads it." CVE-2026-61560 is what happens when all three excuses are true at once.

The default was the vulnerability​

Strip away the CVE number and the deepest flaw here isn't a missing auth check — it's that the missing auth check was the default. The advisory states it plainly: SSE mode with no authentication is the default configuration for Docker deployments. Every operator who ran the documented docker run got an unauthenticated tool server holding a live GitLab credential, and nothing in the startup path told them to think twice.

That default also encodes an assumption the ecosystem has been trying to retire for eighteen months. Standalone HTTP+SSE was deprecated as an MCP transport in spec version 2025-03-26; Streamable HTTP has been the recommended remote transport since, with OAuth 2.1 as the expected auth story for anything reachable over a network. Yet here is a mainstream server, in September 2026, still shipping the legacy transport as its Docker default. The post-fix docs now label SSE the "legacy SSE transport" and refuse to start without SSE_AUTH_TOKEN — unless the operator explicitly sets a flag literally named SSE_DANGEROUSLY_ALLOW_UNAUTHENTICATED_REMOTE. The secure posture existed; it just wasn't the path of least resistance until a 9.8 forced the issue.

This is the localhost fallacy wearing a container costume. "No auth" is arguably fine for a stdio subprocess on a laptop, where the OS process boundary is the auth. It is disqualifying the moment the same server listens on a socket — and Docker's port publishing, a reverse proxy misconfiguration, or a "temporary" debug exposure silently converts localhost-only into network-reachable without changing a line of the server's config. The MCP security discourse has a name for this exact failure: most "MCP is insecure" incidents are really a local-trust model getting exposed remotely. If your threat model for an MCP server starts with "assume the port is reachable," the fix list writes itself — and it is the same list the patched version now enforces at startup.

Not a one-off: the same shape keeps shipping​

If this were one maintainer's bad week, it would be a patch note, not a blog post. It isn't. Start with the same package: CVE-2026-61560 shipped alongside CVE-2026-61559, an SSRF flaw (CVSS 9.6) where the server forwarded the user's GitLab token to an attacker-controlled API address supplied via header, fixed in the same 2.1.27. A third sibling, CVE-2026-61568, covers DNS rebinding against the server's Streamable HTTP endpoint for lack of a Host/Origin allowlist, fixed in 2.1.30. Three criticals, one server, one theme: the network boundary was an afterthought.

Zoom out one level and the shape repeats across implementations. In May 2026 — four months before this CVE — a different GitLab MCP server (@yoda.digital/gitlab-mcp-server) drew CVE-2026-44895 for essentially the same flaw: SSE mode with no inbound auth check, fixed by requiring a bearer token on both /sse and /messages. Two independent codebases, same protocol, same missing gate, same fix. When two teams make the same mistake independently, the mistake is in the water supply — in this case, example configs and SDK defaults that make "no auth" the easiest thing to ship.

Zoom out to the ecosystem and the numbers stop looking like anecdotes. Trend Micro found 492 MCP servers exposed on the public internet with zero authentication. An Astrix survey of roughly 20,000 MCP servers found only 8.5% using OAuth, with 53% still on static API keys. OWASP's MCP security work counts 30+ CVEs filed against MCP components in just the first sixty days of 2026, with token mismanagement and insufficient authentication sitting at the top of its risk list.

The 2026 greatest-hits reel writes itself: "MCPwnfluence" chained two flaws in the 4M-download Atlassian MCP server into unauthenticated RCE as root in two requests; a LiteLLM MCP endpoint flaw chained with a framework bug to a CVSS 10.0 and a CISA Known-Exploited listing; a Nextcloud MCP server exposed an unauthenticated webhook whenever one env var was left unset. CVE-2026-61560 is not an outlier. It is the median MCP security incident, executed cleanly.

The checklist: hardening your own self-hosted MCP servers​

The value of a CVE like this isn't the patch — it's the audit it implies. If you run MCP servers on machines you own (and if agents operate your platform, you do), walk every one of them through this list. Each item maps to a link in the chain above; each is cheap; none requires waiting for a vendor.

1. Default-deny on every network transport. Require a credential for every tool invocation that crosses a socket — bearer token at minimum, OAuth 2.1 where clients support it. Mirror the patched server's posture: refuse to start a remote listener with no auth configured, and make the escape hatch ugly and explicit. While you're at it, bind to localhost unless remote access is a deliberate, documented decision.
2. Sandbox every tool that touches the filesystem. Any file_path-shaped parameter gets an allowlist (a rooted directory, resolved symlinks, rejected ..), not a denylist. The upload_markdown primitive — "read N, send N somewhere" — is exactly the tool shape that must never accept an absolute path. Audit siblings too: if one tool takes a path, grep for every other parameter in the server that reaches open()/readFile().
3. Keep high-value secrets out of the file-readable blast radius. Environ is convenient and file-readable by design (/proc/self/environ, core dumps, debug endpoints). Prefer a secret mount or credential broker the server process can use but a file-read primitive can't trivially dump — and scope every token to least privilege, so a stolen PAT yields one project's read access, not account takeover.
4. Retire legacy SSE for remote servers. If a server still offers standalone SSE, treat it as tech debt with a CVE attached: migrate remote deployments to Streamable HTTP, put auth on the single /mcp endpoint, and set Host/Origin allowlists (the CVE-2026-61568 sibling is your reminder for why).
5. Pin versions and watch the advisories. The vulnerable range here was every release before 2.1.27 — months of "latest" tags. Pin MCP server images, subscribe to their GitHub security advisories, and make "patch within days of a GHSA" part of the runbook, not a background intention.
6. Audit exposure, not just configuration. Configuration says "localhost"; the network decides what's true. Scan your own fleet for listening MCP ports the way Trend Micro scanned the internet — ss -tlnp on every box, plus an external port check — and alert on any MCP listener reachable beyond its intended boundary. The CVE's first link only matters because a port was reachable; verify yours aren't.

Run that list and you've killed all three links with defense in depth to spare: auth stops the remote caller, sandboxing stops the pivot, secret hygiene stops the payoff, and exposure auditing catches the drift that re-opens link one six months from now.

Conclusion: the credential-holder is the blast radius​

The enduring lesson of CVE-2026-61560 fits in one sentence: every MCP server that holds a credential is that credential's blast radius. The GitLab token wasn't stolen from GitLab — GitLab's auth never failed. It was stolen from a helper server that held the token, exposed its tools to the network without asking who's there, and offered a file-read primitive generous enough to hand over its own memory. Threat-model the helper with the same seriousness as the service it fronts, because the attacker already does.

That re-framing is also why this matters beyond one package. As agents become operators — deploying apps, rolling back releases, paging through dashboards — the fleet accumulates MCP servers that each hold some credential worth stealing: cloud keys, registry tokens, deploy hooks. Each one is a small, purpose-built CVE-2026-61560 waiting for its own unauthenticated default. The platforms that survive the next two years of MCP CVEs won't be the ones that never ship a bug; they'll be the ones whose defaults — auth on, filesystem sandboxed, tokens scoped, listeners bound tight — make any single bug a non-event instead of a takeover.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators there, which is exactly why the MCP surfaces they touch deserve the checklist above. Star the repo on GitHub or deploy your first app today.