mcp-pinot EUVD-2026-37951

The mcp-pinot HTTP transport must be enabled (the vulnerable default MCP_TRANSPORT=both or http) and MCP_HOST must remain at the default 0.0.0.0 (or any non-loopback address) so the listener is reachable from outside the host. The attacker needs only TCP reachability to port 8080 (default MCP_PORT) on that interface - no credentials, no user interaction, no specific platform. Exploitation is LIMITED to deployments where the listening interface is reachable by the attacker: instances bound to 127.0.0.1, fronted by an authenticated reverse proxy, or restricted by network policy/firewall to trusted clients are not exploitable. Versions 3.1.0 and later are not vulnerable in their default configuration because the bind host changed to 127.0.0.1 and non-loopback binds are refused without OAuth.

All risk signals align toward maximum priority for any operator running mcp-pinot ≤3.0.1 with the HTTP transport reachable beyond localhost. The CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H vector (10.0) is consistent with the description: no authentication, no user interaction, and tool calls that grant full read/write/admin on Pinot. EPSS and CISA KEV data were not provided in the input, so probability of mass scanning and confirmed in-the-wild use cannot be quantified here - absence is not confirmation either way. No public exploit was identified, but exploitation is trivial (HTTP POST with a JSON body), so the lack of weaponized PoC offers little protection. The most important mitigating factor is deployment scope: instances bound only to loopback or behind authenticated ingress are not exposed, so real-world impact depends heavily on whether operators deployed to Kubernetes/cluster networks with the documented default.

An attacker on the same network segment, VPC, or Kubernetes cluster as a vulnerable mcp-pinot deployment scans for TCP/8080, then sends an unauthenticated POST to /api/tools/call with a JSON body invoking the desired tool - for example {"name":"read-query","arguments":{"query":"SELECT ..."}} to exfiltrate data, or schema/table-config mutation tools to drop or alter Pinot tables. Because the server proxies the request with its own Pinot credentials, the attacker inherits full read/write authority against the cluster without ever touching Pinot directly. No public exploit identified at time of analysis, but the curl examples in the project's own PR description are functionally equivalent to a working PoC.