Obot: OAuth Dynamic Client Registration Enables API Token Theft via Audience Confusion

In affected versions, an unauthenticated attacker could register an OAuth client with an arbitrary external redirect URI, and the authorization flow would auto-complete without a consent screen. If a logged-in victim visited a crafted authorization URL, an authorization code was delivered to the attacker's redirect URI and exchanged for an access token. That token was minted with the victim's full set of groups, so it could be used as a bearer token against the Obot API endpoints the victim had access to — rather than being scoped to just the requested MCP server.

Am I affected?

You are affected if you run Obot <= v0.22.1 with OBOT_SERVER_ENABLE_AUTHENTICATION=true. Exploitation requires a logged-in victim to visit a single attacker-controlled authorization URL.

Details

Three issues combined to create this vulnerability. First, OAuth dynamic client registration was reachable without authentication and applied no restriction on the redirect URIs a client could register, so an attacker could register a client pointing at their own domain. The authorization flow then auto-completed for an already-logged-in user with no consent step, so simply loading the authorization URL issued an authorization code and redirected it to the attacker's URI. Finally, the token minted by the MCP OAuth flow carried the victim's full group set in the JWT — the field used to authorize API paths — so although the token's audience was the requested MCP server, it was accepted across the victim's wider API access. (Obot's JWT verification validated the issuer but not the audience; audiences were enforced at the MCP layer.)

Impact

Worst case is that an attacker who gets a logged-in victim to click a crafted link obtains an access token (and refresh token) usable against the API endpoints the victim is authorized for — reading or modifying the victim's resources until the token is revoked. No attacker-side privileges are required.

Mitigation

Upgrade to v0.23.0 or later, which adds three protections: a consent screen that shows the requesting client and the MCP server it wants access to before authorization completes; restriction of tokens minted by the MCP OAuth flow to only the MCP involved in the request, so they can no longer reach the user's wider API access; and audience validation as a fail-safe ensuring these tokens are only accepted for the MCP server they were issued for.

Severity

CVSS v3.1 Score: 8.8/10 (High) — CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Credits

The Obot team would like to thank @EQSTLab for responsibly disclosing this issue in accordance with our security policy.