The New MCP Advisories Are Access-Control Bugs, Not Prompt-Injection Folklore

The New MCP Advisories Are Access-Control Bugs, Not Prompt-Injection Folklore

The latest MCP advisories are a useful correction to the agent-security conversation. The industry has spent months arguing about prompt injection because prompt injection is novel, demo-friendly, and genuinely dangerous. But three fresh advisories point at something less exotic and more urgent: ordinary access-control bugs sitting inside high-authority agent connectors.

MCPHub accepted arbitrary usernames from an SSE URL path and created sessions without real authentication. Open WebUI let lower-privilege API users invoke private MCP tools by supplying tool identifiers through chat-completion parameters. A Home Assistant MCP integration wrote YAML backups into an unauthenticated web-served directory. None of those require a magic prompt. They require the same security mistakes web engineers have been fixing for two decades, now attached to tools that agents can call.

That is the part teams need to internalize. MCP is not just a prompt surface. It is a transport, credential, authorization, logging, and execution surface. If that layer gets identity wrong, the model downstream cannot reason its way back to safety.

Identity cannot come from a URL path

The MCPHub advisory is the sharpest example. GitHub rates it critical with CVSS 9.1. The vulnerable server accepted path parameters like /:user/sse/:group as identity, fabricated an internal user object, and set current user context without database validation, token verification, or authentication when bearer auth was disabled or missing. An unauthenticated network user could impersonate another user, including an admin, and execute MCP tool calls under that spoofed identity.

That is bad enough as access bypass. It is worse as forensic corruption. If an attacker can make tool calls that appear to come from someone else, the audit log becomes evidence against the wrong principal. Agent systems lean heavily on logs because decisions are distributed across prompts, retrieved context, tool calls, and external services. Poisoning identity at the first hop breaks every later accountability story.

The advisory also flags a race condition: a singleton UserContextService stored current user in one instance variable, allowing concurrent connections to overwrite identity context. That is the kind of bug that feels too mundane for AI discourse and exactly the kind that matters in production. Session state must be per connection, per request, or otherwise isolated. A global “current user” is not an architecture; it is a future incident report.

Tool visibility is not tool authorization

The Open WebUI advisory lands on a related failure mode. In v0.6.43, tool_ids and tool_servers were user-supplied to the chat-completion API, and middleware resolved tools without checking whether the caller had permission. The result: a lower-privilege user could cause the server to invoke private MCP tools using stored server credentials.

This is the API version of hiding a button in the UI and calling it security. A tool that is invisible in one client is not unauthorized unless the server re-checks access when the request arrives. Agent products are especially vulnerable here because their UI, API, and tool planner can diverge. The model may propose a tool call, the client may pass an identifier, and the server may hold credentials. Every handoff must re-assert the caller’s right to use that capability.

Open WebUI’s fixes reflect that distinction: local tool records were addressed in v0.7.0, and admin-configured MCP servers were fixed in v0.8.6 by checking has_connection_access(user, mcp_server_connection) before stored credentials are used. That is the pattern teams should copy. Never let a client-supplied tool ID become an executable capability without server-side authorization against the authenticated principal.

Backups are data exfiltration paths too

The Home Assistant MCP issue is less glamorous and possibly more relatable. When ENABLE_YAML_CONFIG_EDITING=true, backups were written under <config>/www/yaml_backups/, which Home Assistant serves unauthenticated at /local/. Those backups could contain MQTT passwords, REST credentials, webhook IDs, geofence coordinates, and shell commands. The fix moves backups to <config>/.ha_mcp_tools_backups/, migrates existing exposed files, removes the legacy directory if empty, and notifies users to rotate exposed secrets.

This is a reminder that agent tooling often creates secondary data surfaces. The risky path may not be the tool call itself. It may be the log file, backup directory, transcript export, retrieved cache, or “helpful” file path returned to a client. If that artifact contains secrets and lands somewhere web-served, the agent layer has become a leak amplifier.

The practical response is not to panic about MCP. It is to threat-model MCP servers like delegated API gateways. Require authentication on every remote transport. Do not derive identity from URL paths, headers, or client strings without verification. Store user context per request or connection, not in singleton globals. Re-check authorization for every tool_id, tool_server, resource, and credential use. Keep backups and logs outside public directories. Include authenticated principal, session ID, connection ID, and tool name in audit logs.

Prompt-injection defenses still matter. A malicious document can steer an agent toward a dangerous tool call. But if the MCP server has broken auth, missing authorization, global user context, or public backups, the model is not the first control that failed. The boring controls failed.

That is the editorial lesson: agent security is becoming normal application security with a larger blast radius. The novel pieces are real, but they do not repeal the old rules. If your MCP server acts like a trusted internal script while sitting on a network transport with credentials behind it, the vulnerability is not philosophical. It is architectural.

Security teams should spend less time asking whether their prompts are clever enough and more time asking whether every MCP connector can answer four questions: who is calling, what are they allowed to do, which credential is being used, and where will the evidence land? If any answer is “the client told us,” request changes.

Sources: GitHub Advisory GHSA-wf8q-wvv8-p8jf, Open WebUI advisory CVE-2026-45350, Home Assistant MCP advisory GHSA-g39v-cvjh-8fpf, OWASP GenAI secure MCP server guide