Five Obot CVEs in One Batch — a Quickstart That Ships Owner/Admin and an MCP Gateway That Skips Authorization

2026-09-27 AI Vulnerabilities & CVEs by al-ice.ai Editorial

NVD published five CVE records for Obot, the open-source AI agent and MCP platform, on 27 September 2026 — two criticals, two highs, and a medium that is a configuration-truthfulness bug. The batch spans the project's OAuth login, its MCP registry, remote MCP server registration, the MCP connection gateway, and its documented Docker quickstart. The common thread is authorization that existed as a setting or an identifier but was never enforced where the action happened.

The five, in severity order: CVE-2026-101065 (CVSS 3.1 9.8) — the README quickstart binds 0.0.0.0:8080 with authentication disabled, mapping every request to a synthetic nobody user holding Owner and Admin roles. CVE-2026-101084 (9.6) — the /mcp-connect/{id} gateway does not enforce Access Control Rules, so any authenticated user who knows a server ID can use restricted MCP servers. CVE-2026-101062 (8.8) — unauthenticated OAuth dynamic client registration with unrestricted redirect URIs, combined with an auto-completing authorization flow, yields a bearer token carrying the victim's full group set. CVE-2026-101064 (7.6) — remote MCP server registration fetches an attacker-controlled URL with no destination validation, reaching loopback, private ranges, and the cloud metadata endpoint. CVE-2026-101063 (5.3) — enabling registry authentication does not actually protect the /v0.1/* MCP Registry endpoints.

The affected boundary is Obot before v0.23.0 for four of the five; the /mcp-connect bypass affects v0.21.0 and earlier and is fixed in v0.21.1. The quickstart issue is fixed by documentation only — there is no code patch that makes an auth-disabled deployment safe, because an auth-disabled deployment is the vulnerability. None of the records claims exploitation in the wild. The disclosure timeline matters here too: the project published the OAuth, registry, and SSRF advisories on 18 September and the /mcp-connect advisory back in May; the CVE records arrived 27 September. Operators already on the fixed versions have the named fixes — the new records do not indicate a regression. That advisory-to-CVE lag is the same pattern as the OpenClaw batch documented earlier this month: scanners that only watch CVE feeds were blind for weeks.

The quickstart is the worst one, and the fix is a paragraph

CVE-2026-101065 deserves to lead because its preconditions are the documented happy path. Following the README's Docker quickstart starts Obot listening on all interfaces, port 8080, with authentication off. With auth disabled, every request is attributed to a synthetic nobody user that carries the Owner and Admin roles — so anyone who can reach the port has full administrative access to the API and UI, including registering and launching MCP servers. The advisory adds two aggravating details: run this on a laptop on shared Wi-Fi and anyone on that network is an admin; and the quickstart mounts /var/run/docker.sock, so the MCP runtime backend stands on the host's Docker control surface.

The fix, per the advisory, is documentation: enable authentication in the quickstart and warn clearly about running with it disabled. That is honest but it means upgrading changes nothing for anyone who copied the old command into a compose file months ago — their deployment is still auth-disabled by its own configuration. If you run Obot, check for the exposure directly: anything answering on 8080 (or your mapped port) without a login prompt, from an address that is not loopback, is this finding. The broader lesson is one this site keeps repeating — the CIS MCP benchmark exists because safe defaults keep living in documentation while the shipped command does the opposite.

The gateway checked the ID but not the permission

CVE-2026-101084 is the architecturally interesting flaw. The MCP gateway endpoint /mcp-connect/{mcp_id} resolves the server from the caller-supplied identifier and opens the connection — including tool calls — without consulting the Access Control Rules that administrators use to restrict servers to specific groups and registries. Possession of an opaque server ID becomes the entire authorization check. Any authenticated user, including the lowest-privilege role, can fully use MCP servers the administrator believed were group-restricted, and can exercise whatever OAuth credentials and backend access those servers hold.

This is the same failure shape as DBHub's read-only mode that was never wired to enforcement and Flowise's workspace-crossing ChatFlow IDs: route-level authentication (you are logged in) standing in for object-level authorization (you may use this server). The advisory dates to May and the fix shipped in v0.21.1, so long-running deployments that track only recent releases may have carried this for months. Note the practical consequence for incident response: because the bypass uses legitimate gateway functionality with a valid identity, its use looks like normal MCP traffic. If untrusted users held accounts on an affected deployment, review gateway and tool-call logs for server IDs outside each user's granted registries — the upgrade closes the path but does not produce a list of past crossings.

OAuth registration became a token-minting primitive

CVE-2026-101062 chains three individually understandable behaviors into an account-level compromise. When OBOT_SERVER_ENABLE_AUTHENTICATION=true, Obot still exposed OAuth dynamic client registration without authentication and placed no restriction on the redirect URIs a client could register — so an unauthenticated attacker registers a client pointing at their own domain. The authorization flow then auto-completed for an already-logged-in user with no consent screen, so a single crafted authorization URL visited by a victim delivered an authorization code to the attacker's redirect URI, exchangeable for an access token.

The audience-confusion half is what elevates it. The minted token carried the victim's full set of groups rather than being scoped to the requested MCP server, and Obot accepted it as a bearer token against the API endpoints the victim could reach. A token obtained through one MCP-adjacent flow became a general-purpose credential with the victim's authority. The CVSS vector (PR:N/UI:R) prices this honestly: no privileges required, but one user interaction — the victim must visit the crafted URL while logged in. Defenders should read this alongside the LiteLLM MCP auth bypass that reached CISA's KEV catalog: MCP-adjacent OAuth plumbing keeps producing tokens whose scope and audience were never pinned down, and each one is worth testing with the question "where else is this bearer accepted?"

SSRF through the server URL field, and a registry flag that lied

CVE-2026-101064 is a textbook SSRF with an agent-platform blast radius. The URL of a remote MCP server is attacker-controlled at registration and fetched server-side with no validation — no guard against loopback, link-local, RFC 1918 ranges, or 169.254.169.254 — and responses are readable in error messages, which turns the metadata service into credential disclosure. Exploitation requires Power User, Power User Plus, or Admin, so this is a privilege-escalation and lateral-movement primitive rather than an internet-wide unauthenticated flaw. But in agent platforms "editor" roles routinely hold exactly this power, and the fetched URL persists as infrastructure: every subsequent agent run that touches the malicious server re-contacts the attacker's destination.

CVE-2026-101063 is lower severity (5.3) but arguably the most instructive for operators. Setting OBOT_SERVER_ENABLE_REGISTRY_AUTH=true did not protect the /v0.1/* registry endpoints — an unauthenticated GET /v0.1/servers returned catalog metadata including server names, descriptions, repository URLs, and connect URLs. The authorizer rejected a fixed set of known-protected prefixes and the registry paths were not in it. A dashboard showing "registry auth: enabled" described intent, not enforcement. The information disclosed is reconnaissance-grade rather than directly exploitable, but server IDs and connect URLs harvested here are exactly the inputs the /mcp-connect bypass consumes — the two flaws compose.

What defenders should do now

Upgrade to v0.23.0 or later (v0.21.1+ at minimum for the gateway bypass). Check the running image or binary, not just the compose tag. The /mcp-connect fix is older (v0.21.1) than the rest — confirm it explicitly rather than assuming a recent pull includes it.
Audit for auth-disabled exposure first, because no upgrade fixes it. Find every Obot instance reachable without credentials, especially quickstart-derived deployments and anything bound to 0.0.0.0. Enable authentication and re-verify from an untrusted source address. Treat any period of unauthenticated reachability as full administrative compromise: rotate all credentials, OAuth tokens, and MCP server secrets on that instance.
Re-validate registry isolation after patching. With registry auth enabled, request /v0.1/servers unauthenticated and confirm denial. Then test cross-registry /mcp-connect/{id} with a low-privilege account and a server ID from a registry the account cannot access.
Review OAuth client registrations and issued tokens. Look for clients with external redirect URIs registered before the upgrade, and for tokens whose group claims exceed the scope their flow should have granted. Revoke and reissue where the history is unclear.
Inventory remote MCP server URLs. List every registered remote server, flag any pointing at loopback, link-local, RFC 1918, metadata, or otherwise internal destinations, and confirm each was added by an authorized operator. Constrain egress so the Obot workload cannot reach the cloud metadata endpoint regardless of URL validation.
Hunt the gateway logs, not just the auth logs. Successful /mcp-connect bypasses authenticate normally. Correlate low-privilege identities with server IDs outside their granted registries and with tool calls carrying side effects.
Stop gating CVE response on CVE publication. Four of these advisories were public days to months before the CVE records. If your intake starts at NVD, add vendor-security-advisory and VulnCheck feeds for the agent platforms you operate — and read the advisory body, not just the CVE description.

The defensive lesson compresses to one sentence: in Obot, the identifier, the setting, and the role all looked like authorization, and none of them was enforced at the action. Server IDs, registry-auth flags, OAuth audience restrictions, and quickstart defaults each described a boundary the code did not hold. When you assess any agent platform, test every trust claim at the endpoint that acts on it — connect with the wrong principal, request the wrong object, register the wrong URL — because configuration text is not a control.

Sources: