Four CVEs in Obot's MCP gateway: the critical one is the Docker quickstart itself

Between September 27 and September 28, 2026, the CVE Program published four vulnerability records for Obot, an open-source gateway that organisations use to control which AI agents may reach which Model Context Protocol (MCP) servers. The most serious of them, CVE-2026-101065 (CVSS 3.1 score 9.8), is not a coding bug at all: Obot's own documented Docker quickstart starts the service with authentication switched off, which hands anyone who can reach port 8080 full administrator rights — and, because the same quickstart mounts the Docker socket, a route onto the host. If you run Obot anywhere, confirm that authentication is enabled and move to version 0.23.0 or later.

What happened, in plain English

MCP — the Model Context Protocol — is the plumbing that lets an AI assistant call systems outside itself: a ticketing system, a file store, an HR database. The calls go through small adapter services called MCP servers, and each adapter holds real credentials for the system behind it. Because of that, companies increasingly put a gateway in front of the adapters: one place that decides which person or which agent is allowed to call which server. Obot is one of those gateways, sold and shipped as an AI governance platform.

Think of it as a reception desk in front of a corridor of locked offices. The desk exists so that visitors only get into the rooms they are cleared for.

Four separate problems have now been filed against that desk. In the default Docker setup documented by the project, the desk was simply unstaffed: Obot's quickstart command binds to 0.0.0.0:8080 with no authentication, and in that state every incoming request is treated as a user holding the Owner and Admin roles (CVE-2026-101065). Separately, an authenticated user who merely knew a server's ID could connect straight through the gateway to any registered MCP server and make tool calls against it, whether or not they had been granted access (CVE-2026-101084, CVSS 3.1 score 9.6). A third flaw let an unauthenticated attacker register an OAuth client with any redirect address they liked and, with one click from a logged-in victim, walk away with a token carrying that victim's permissions (CVE-2026-101062, CVSS 8.8). A fourth let privileged users point the server at internal addresses it should never fetch (CVE-2026-101064, CVSS 7.6).

There is no public report of any of these being exploited in the wild.

Are you affected? What to do now

You are affected if your organisation self-hosts Obot. If you do not run Obot, there is nothing here for you to patch — but the configuration lesson in the last section applies to any MCP gateway you do run.

How to check, in order:

• Find out whether Obot is running at all. Look for a container or pod from the image ghcr.io/obot-platform/obot. A quick check on a Docker host: docker ps --filter ancestor=ghcr.io/obot-platform/obot. Shadow deployments are the real risk here — this is the kind of tool a platform team spins up to try MCP out and then leaves running.
• Check whether authentication is on. Inspect the container's environment for OBOT_SERVER_ENABLE_AUTHENTICATION. If it is absent or not true, the instance is in the state described by CVE-2026-101065 and every request reaching it has Owner and Admin rights.
• Check what port 8080 is exposed to. The quickstart publishes it to all interfaces. Confirm from outside the host, not from the host itself, and treat "it's only on the internal network" as insufficient — an unauthenticated admin API on a flat corporate network is an open door.
• Check the version. Anything at or below 0.21.0 is affected by the /mcp-connect authorization bypass; anything at or below 0.22.1 is affected by the OAuth and SSRF issues.

What to do:

1. Upgrade to 0.23.0 or later. That release fixes CVE-2026-101062, CVE-2026-101064 and the lower-severity registry issue GHSA-pr6h-vr44-xq8j. The /mcp-connect bypass (CVE-2026-101084) was fixed earlier, in 0.21.1, so 0.23.0 covers it too.
2. Set OBOT_SERVER_ENABLE_AUTHENTICATION=true and configure an identity provider. Upgrading alone does not close CVE-2026-101065, because that record describes a configuration the documentation used to hand out. Note one operational trap flagged in Obot's own documentation: MCP servers created while authentication was disabled are deleted when you turn authentication on. Inventory what exists before you flip the switch.
3. Do not expose the quickstart deployment to anything you do not trust. Obot's documentation is explicit that because /var/run/docker.sock is mounted, a user holding the Power User role can effectively run code on the host, and it recommends Kubernetes rather than the Docker quickstart for multi-tenant or untrusted environments.
4. Rotate the credentials held by your MCP servers if an instance ran unauthenticated on a reachable network, or if you cannot rule out that untrusted users held accounts on a version at or below 0.21.0. Those are the OAuth tokens and API keys stored for each upstream system — they, not Obot itself, are what an attacker was after.
5. Review gateway logs for MCP connections that do not match your access rules — a user reaching a server no registry entitles them to. No official indicators of compromise have been published for these issues, so this is behavioural review rather than IOC matching.

The expert view

The four records split cleanly into one design-and-documentation failure and three ordinary authorization bugs, and it is the first that deserves attention.

CVE-2026-101065 is filed as CWE-306, missing authentication for a critical function, and the remediation is documentation. That framing is correct but undersells it. When Obot runs with authentication disabled it does not fail closed or run in a reduced mode; it maps every anonymous request onto a principal holding Owner and Admin. Combine that with a quickstart that binds to all interfaces and mounts the Docker socket, and the shortest path from unauthenticated network access to code execution on the host runs entirely through supported, documented features. Nothing needs to be broken. The CVSS 3.1 score of 9.8 looks high for "the docs told you to do it insecurely" and is, in my view, about right — the scoring reflects what an attacker achieves, and here that is the host.

CVE-2026-101084 is the one that should worry anyone who bought a gateway for governance rather than convenience. The authorization checks existed; they were enforced during the OAuth callback but a second code path, the UI authorizer, granted access independently. That is the classic shape of a broken access-control bug: not an absent check, but two checks with different opinions, where the permissive one wins. Because the gateway holds stored credentials for every upstream MCP server, a bypass at that layer is a confused-deputy problem — the attacker never needs the credentials, only the gateway's willingness to use them on request. An access-control plane that can be steered by an ID guess is providing an audit trail, not a boundary.

The broader trend is the uncomfortable part. Organisations are being told, correctly, to put MCP access behind a gateway instead of letting agents hold credentials directly. That advice concentrates secrets in a young category of software, and these four records are what early software in a new category looks like. The defences did not fail so much as arrive in the wrong order: consent screens on OAuth flows, blocking of loopback and link-local addresses, and per-server token scoping all landed in 0.23.0, which is to say they were added after the fact rather than designed in.

What is still unknown: whether any of these have been used against real deployments. There is no public exploitation evidence, no CISA Known Exploited Vulnerabilities listing, and no published indicators of compromise. Also unclear is how many Obot instances are running the unauthenticated quickstart — an unauthenticated admin API on port 8080 is trivially fingerprintable, so that number will not stay unknown for long.

Official sources

• GitHub Advisory Database — GHSA-vw82-7fv8-r6gp: Obot authorization bypass in /mcp-connect/{id} (CVE-2026-101084)
• CVE record — CVE-2026-101065: missing authentication in Obot's Docker quickstart
• CVE record — CVE-2026-101062: OAuth dynamic client registration / audience confusion
• GHSA-xwmw-prc4-v3cr — Obot: OAuth Dynamic Client Registration enables API token theft via audience confusion
• GHSA-jgh3-fggc-mcpm — Obot: server-side request forgery via remote MCP server URL (CVE-2026-101064)
• GHSA-pr6h-vr44-xq8j — Obot: MCP Registry API readable without authentication
• OSV — GHSA-vw82-7fv8-r6gp (affected and fixed version ranges)
• Obot documentation — Docker deployment (the quickstart command and its security caveats)
• Obot documentation — Enabling authentication
• Coverage: CVE Brief — September 28, 2026