
CVE-2026-44895 - GitHub Advisory Database
GitHub advisory for @yoda.digital/gitlab-mcp-server (mcp-gitlab-server): with USE_SSE=true the HTTP/SSE transport has no authentication, sends wildcard CORS headers, and binds to 0.0.0.0. Any network caller or any web page the operator visits can open /sse and POST /messages to drive all 86 GitLab tools (delete_repository, push_files, etc.) using the operator's personal access token. It includes a curl PoC, a CVSS 4.0 vector (~6.3 Medium, effectively High when SSE is enabled) and four fixes: required auth token, loopback bind, a CORS allowlist, and the OAuth roadmap.
What it is
CVE-2026-44895 (GHSA-8jr5-6gvj-rfpf) affects @yoda.digital/gitlab-mcp-server (mcp-gitlab-server), reviewed at commit 80a7b4cf3fba6b55389c0ef491a48190f7c8996a. The SSE transport in src/transport.ts has no inbound credential check on any code path, so an unauthenticated caller can act as the operator's GitLab PAT.
How it works
- With
USE_SSE=true, every response setsAccess-Control-Allow-Origin: *, with methodsGET, POSTand headerContent-Type. httpServer.listen(port)at line 97 passes no host, so Node binds to0.0.0.0.GET /ssereturns a session endpoint.POST /messages?sessionId=<id>then proxies MCP calls to GitLab usingGITLAB_PERSONAL_ACCESS_TOKEN.- The page says the PAT never leaves the process, but every API call it can make is available to the caller.
- The page says a web page the operator visits can do this via cross-origin fetch, with no interaction beyond the visit.
Preconditions / Affected
USE_SSE=truemust be set. This is the CVSS 4.0AT:Pprecondition, and the README promotes SSE as a feature.- The attacker needs network reach to the port, or the operator's browser must run a hostile page while the server is up.
- The page names no patched version. It reports the commit above and says no prior advisories exist for the package.
- Severity:
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N, about 6.3 Medium. The advisory calls it functionally High wherever SSE is on.
What to do
The page gives no upgrade path. It proposes four changes. To check exposure, reproduce against your own instance:
curl -N http://localhost:3000/sse &
# note data: /messages?sessionId=<UUID>
curl -X POST "http://localhost:3000/messages?sessionId=<UUID>" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_repository","arguments":{"project_id":"target-org/private-repo"}}}'If this returns repository data, the instance is exposed. The proposed fixes are:
- Exit at startup if
USE_SSE=trueandMCP_GITLAB_AUTH_TOKENis unset, and checkAuthorization: Bearer <token>on every request, returning 401 on mismatch. - Bind to
127.0.0.1by default. Network exposure would need an explicitMCP_GITLAB_HOST=0.0.0.0with a warning banner. - Default CORS to localhost only, and require a
CORS_ORIGINSallowlist when exposure is intentional. - SAML/OAuth is the long-term direction, listed on the roadmap at README line 190.
Until a release includes these, the practical choices are to run stdio instead of SSE, or to keep SSE off any reachable interface.
Caveats
- The proposed request check only enforces when
MCP_GITLAB_AUTH_TOKENis set, so it depends on the startup guard in item 1. - Items 1–3 are described as achievable in the existing codebase with no new dependencies. The page doesn't say they have shipped.
Organisations named here
- CVSS 4.0
Technologies named here
- curl
- CVSS 4.0
- Model Context Protocol
- GitLab
- Node.js
- TypeScript
- npm
- Missing Authentication for Critical Functionality
Techniques named here
- Trust-boundary violation
Related in AI Security
