CVE-2026-101062: Obot before v0.23.0 Authentication Bypass via OAuth Dynamic Client Registration
Obot before v0.23.0 (affected versions <= v0.22.1) running with OBOTSERVERENABLEAUTHENTICATION=true exposes OAuth dynamic client registration without authentication and without any restriction on the redirect URIs a client may register. Because the authorization flow auto-completes for an already logged-in user with no consent screen, an attacker who registers a client pointing at their own domain and induces a logged-in victim to visit a single crafted authorization URL receives an authorization code at the attacker-controlled redirect URI and can exchange it for an access token and refresh token. The token minted by the MCP OAuth flow carries the victim's full group set in the JWT, and Obot validated only the issuer and not the audience, so the token is accepted as a bearer token against any Obot API endpoint the victim can access rather than being scoped to the requested MCP server, allowing the attacker to read or modify the victim's resources until the token is revoked. v0.23.0 adds a consent screen, restricts MCP OAuth tokens to the MCP involved in the request, and enforces audience validation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Obotto a version that resolves this vulnerability.Fixed in v0.23.0
Event History
Frequently Asked Questions
Which deployments are exposed?
Obot versions up to and including v0.22.1 are affected when OBOT_SERVER_ENABLE_AUTHENTICATION=true. The provided information does not establish whether deployments with authentication disabled are affected by this OAuth flow.
What does an attacker need to exploit this issue?
An attacker can register an OAuth client without authentication, using an attacker-controlled redirect URI, and must induce an already logged-in victim to open one crafted authorization URL. No victim consent or additional interaction is required after the URL is visited.
What access can a stolen token provide?
The attacker can exchange the received authorization code for access and refresh tokens containing the victim's full group set. Because affected versions do not validate the token audience, the token can be used against any Obot API endpoint the victim is allowed to access, including to read or modify resources.
What should be done if exploitation is suspected?
Upgrade to v0.23.0, which adds consent, restricts MCP OAuth tokens to the relevant MCP, and enforces audience validation. Revoke potentially exposed tokens, since access persists until the token is revoked.