Three flaws in Obot MCP platform let attackers steal API tokens

The Obot team disclosed three security flaws in its open-source agent platform on 18 September 2026, the most serious of which allowed an attacker to steal a logged-in user's API access token with a single crafted link. All three affect Obot version 0.22.1 and earlier, and all are fixed in version 0.23.0.

The highest-rated issue, tracked as GHSA-xwmw-prc4-v3cr and scored 8.8 out of 10 under CVSS v3.1, combined three weaknesses. According to the advisory, OAuth dynamic client registration — the mechanism that lets a new application sign itself up to an authorisation server — was reachable without authentication and placed no restriction on the redirect URI a client could register. An attacker could therefore register a client pointing at their own domain. The authorisation flow then completed automatically for a user who was already logged in, with no consent screen, so merely loading the attacker's authorisation URL issued a code and sent it to the attacker.

The resulting token was worse than expected, the advisory said. Although it was issued for a specific MCP server — Model Context Protocol, the standard Obot uses to connect agents to tools — the token carried the victim's full set of group memberships in its JWT, and Obot's token verification checked the issuer but not the audience. The token could therefore be used as a bearer credential against any API endpoint the victim could reach, allowing an attacker to read or change the victim's resources until the token was revoked. No attacker-side privileges were needed. Version 0.23.0 adds a consent screen, limits tokens minted by the MCP OAuth flow to the MCP server involved, and enforces audience validation as a fail-safe.

A second advisory, GHSA-jgh3-fggc-mcpm, describes a server-side request forgery flaw rated 7.6. The URL of a remote MCP server is supplied by the user at registration and was accepted after only a check that it parsed and used an http or https scheme. Obot then fetched OAuth discovery metadata from that URL automatically during reconciliation, with no guard against loopback addresses, link-local ranges, private RFC1918 ranges or the cloud metadata endpoint at 169.254.169.254. Because response bodies were reflected in error messages, the flaw was non-blind. The advisory says a user with the Power User, Power User Plus or Admin role could use it to read internal services and potentially disclose the host's cloud IAM credentials. The fix adds a single egress chokepoint that rejects those address ranges at dial time.

The third issue, GHSA-pr6h-vr44-xq8j, is rated 5.3. Setting the registry authentication flag did not actually protect the MCP registry endpoints under the /v0.1 prefix, which remained readable by anonymous callers. The advisory says the authoriser rejected a fixed list of protected prefixes and then allowed everything else by default, and that /v0.1 was missing from the list. Exposed data covered server names, descriptions, repository URLs, icons and connect URLs, but not secret environment variables or headers, and anonymous users still could not connect to the servers. The Obot team notes this shares a root cause with an earlier advisory whose fix covered a different prefix.

The company credited EQSTLab for the OAuth issue and an external researcher for the other two.