Build1 publisher2 min readPublished
Four MCP servers drew CVEs for exposing every tool without authentication
NVD logged CVEs for four MCP servers in about 35 hours, each because every tool it exposes needs no authentication. A fifth MCP flaw, LiteLLM's authentication bypass, is already on CISA's exploited-vulnerabilities list.
The Engineer · Build desk
What happened
- The four are a GitLab reader that uploads any local file, the Bifrost gateway that runs whatever program a caller registers, a MySQL tool that opens its database and filesystem to the network, and an IBM sandbox that escapes on two string concatenations.
- All four records sit at NVD status Received. Every CVSS score is the issuing authority's own number, assigned by JFrog or GitHub's security team and not yet reviewed by NVD.
- Two of the four fixes were tagged in June, three months before the matching CVE records appeared in the database.
- The GitLab proof of concept is public twice over, in the advisory and in Pluto Security's July post. CISA's SSVC assessment marks exploitation at PoC and automatable.
- As of the writeup's publication, none of the four flaws had drawn a single analysis on Hacker News or Dev.to.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Teams running the default GitLab-MCP container are exposed by the image as shipped. Closing it means upgrading.
- constraint The fix controls who can reach the file read but never removes it, so a later deploy that re-enables the transport reopens the full read-and-exfiltrate chain.
- decision For anyone exposing Bifrost the one gating decision is turning authentication on before the management port is reachable, because the shipped default leaves it off.
- precedent Patched-before-published means scanning by advisory date misses the exposure window, so MCP detection has to key on installed version instead.
The GitLab server is the clearest case in the writeup, because no step needs exploit code. Connect to its SSE endpoint and it returns a session id with no login screen. Then ask it to read a file. The `upload_markdown` tool takes your `file_path`, passes it straight to `fs.readFileSync` with no sanitization, and uploads whatever it reads into a GitLab project it can see. The file worth asking for is `/proc/self/environ`, because the process keeps `GITLAB_PERSONAL_ACCESS_TOKEN` there to talk to GitLab. Whoever holds that token holds the GitLab account. The default Docker image binds port 3002 on 0.0.0.0 and runs as root, since the Dockerfile never declares a USER.
Bifrost, maximhq's Go gateway, goes further still. JFrog's CNA writeup is blunt about it: "A stdio client is a command plus args. Bifrost starts that program in the gateway the moment the client is added. No MCP handshake required. The default is governance.auth_config.is_enabled=false. Auth off means every caller is a local admin." A single unauthenticated POST to /api/mcp/client registers a client whose command and arguments then run as the gateway's process user. That fix merged on September 2 and shipped in transports/v2.1.0 on September 8.
The two servers rated 10.0 both carry a changed scope, and none of the four has a CVSS v4.0 score at all.
Version 2.1.27 of the GitLab server put an authentication check in front of the SSE transport and limited file_path when the call comes in remotely. The maintainers confirm in the PR #622 thread, though, that the arbitrary-path read itself never got sanitized.
The writeup's author covers MCP security most weeks and had argued the protocol's "real risk lives in defaults, not in exotic prompt injection". This week, they wrote, "read like a validation set".
What to watch
- Whether NVD's own analysis revises the CNA-assigned scores or adds a CVSS v4.0 for the four records.
- Whether the GitLab server's unsanitized file-read path, flagged in PR #622, ever gets a real fix.
- Whether exploitation reports follow now that the GitLab chain and LiteLLM's bypass are both public.