SSE on, auth off

Seven CVE records in two days describe one MCP fault: a network transport, every interface, no login

Two of them score a perfect 10. The trigger is a transport setting: MCP_TRANSPORT=sse on the MySQL server, SSE=true on the GitLab one, run_sse on PraisonAI. The stdio default was never affected, and the fixes are version numbers.

ServerWhat opens itScoreFixed in
MySQL MCP ServerMCP_TRANSPORT=sse10.00.4.2
@zereight/mcp-gitlabSSE=true, the Docker default9.82.1.27
@zereight/mcp-gitlab, Streamable HTTPno Host or Origin allowlist9.62.1.30
Bifrost gatewayauth_config.is_enabled=false, the default9.8transports/v2.1.0
PraisonAI ToolsMCPServerrun_sse binds 0.0.0.09.8praisonaiagents 1.6.59
PraisonAI MCPServer.startHttpno host restriction, no auth9.81.7.2
PraisonAI UI /api/mcp/connectcaller supplies command and args9.84.6.59
Where the port opened and the version that closes it. Scores are CVSS 3.1 base scores as recorded by the NVD.

The NVD published CVE-2026-59971 on 15 September at 10.0 out of 10 on CVSS 3.1, for a MySQL MCP server.

It answers unauthenticated SQL the moment its transport is set to SSE. The seven records in the table fail the same way, and none of them is a bug in MCP. The bug is a setting that turns a local pipe into a network service and changes nothing else.

The MySQL record is specific about the mechanism. Setting MCP_TRANSPORT=sse makes the server “construct SseServerTransport without security_settings or enable_dns_rebinding_protection”, the routes /, /sse and /messages/ “have no authentication”, and the service “binds to 0.0.0.0 by default”. A caller on the network reaches execute_sql directly. A caller who cannot reach it uses DNS rebinding to make a browser on the same machine relay the request. Where the MySQL account holds FILE privileges, the record says, the same path “may enable code execution”. The stdio transport “is not affected”, and 0.4.2 closes it.

The GitLab server, @zereight/mcp-gitlab, is the same fault with a worse payload. Before 2.1.27, its record says, SSE=true “exposes all MCP tools without any authentication”, one of which, upload_markdown, reads any file the process can and pushes it to a GitLab project. The record spells out the chain: read /proc/self/environ, take GITLAB_PERSONAL_ACCESS_TOKEN, own the account. The costliest line is the last one: “This is the default configuration for Docker deployments.” Two more records on the same package, at 9.6 out of 10 each, add DNS rebinding through the Streamable HTTP endpoint, fixed in 2.1.30, and a request header that redirects the server’s own token to a host the caller names.

Bifrost, an AI gateway, shows the shape without the flag. JFrog’s record says a stdio MCP client “is a command plus args” and that “Bifrost starts that program in the gateway the moment the client is added. No MCP handshake required.” The default governance.auth_config.is_enabled=false means, in the record’s words, “every caller is a local admin”, so one unauthenticated POST to /api/mcp/client runs a program as the gateway’s user. Version transports/v2.1.0 answers that registration with a 403; v2.0.0 still does not.

PraisonAI accounts for twenty-eight of the sixty-one records this paper pulled from the NVD for 14 to 16 September, and the transport fault appears in it three times. ToolsMCPServer.run_sse binds 0.0.0.0 and creates /sse and /messages/ “without invoking the available SecurityConfig authentication”, which is the record’s way of saying the guard existed and was not called. MCPServer.startHttp in the TypeScript package “binds without a host restriction” and forwards every POST to the handler unauthenticated. The UI’s /api/mcp/connect takes a command and its arguments from any caller and starts the process “even when the MCP handshake later fails”. The same habit runs through the project’s non-MCP surfaces, a Jobs API at 9.8 out of 10 and an AgentOS at 9.4, and two of the records call the 1.7.2 fix “an initial remediation”.

The objection is that this is one week’s disclosure queue, not a trend, and that twenty-eight records from one project are one researcher’s afternoon. Both are true, and neither helps. The MySQL and GitLab servers are separate projects by separate authors, both defaulted their network mode open, and the Serena record from 14 September, scored 2.9, quotes the maintainer calling a 0.0.0.0 listen address “a potential security hazard” while the documentation of the time recommended a sandbox rather than a different address. The pattern is a design habit, not a coincidence of the calendar.

The MySQL record names why the setting does this: the SDK’s transport object takes security_settings and enable_dns_rebinding_protection as arguments, and an author who constructs it without them gets a listener with neither. Nothing in the protocol or its SDKs makes an unauthenticated network listener an error. The MCP Go SDK this paper covered yesterday bounded the size of what a server will read; it did not bound who may send it.

The paper’s verdict is a grep before a patch list. Search your MCP configuration for any transport that is not stdio, and for each hit answer two questions: what authenticates a caller, and what address does it bind. If either answer is nothing, that server is one of these records whether or not its CVE has been filed yet. Then take the patch list: 0.4.2, 2.1.30, transports/v2.1.0, and for PraisonAI every version boundary in the table rather than one.

None of the seven records reports exploitation. All seven were published on 14 and 15 September, and the settings that opened the ports are older than any of the records, so the exposure predates the news by however long each flag has been set.

What it changes Grep your MCP configuration for any transport other than stdio. For each, name what authenticates a caller and what address it binds; if either is nothing, treat it as exposed now. Then upgrade: MySQL MCP Server 0.4.2, mcp-gitlab 2.1.30, Bifrost transports/v2.1.0, and every PraisonAI boundary in the table.

Primary source read

Who is telling you this

National Vulnerability Database · primary

Written by
Not published on the page; the record’s source is GitHub’s advisory database
For
NVD, run by NIST
What they gain if this is true
The paper’s best guess: none. The scoring is the CNA’s, GitHub’s, and the paper read the vendor advisory it points to.

National Vulnerability Database · primary

Written by
Not published on the page; the record’s source is JFrog
For
JFrog, which sells software supply-chain security scanning
What they gain if this is true
The paper’s best guess: a gateway that runs any registered program is a good argument for the product JFrog sells, and the record’s facts are checkable against Bifrost’s own v2.1.0 release, which the paper read.

Published in the edition of Wednesday, 16 September 2026 · Beat: Tooling