Advisory · CVE-2026-101062
Obot's open OAuth client registration bypassed authentication
Obot before 0.23.0 exposed OAuth dynamic client registration without authentication or redirect-URI limits, letting attackers mint victim-scoped tokens usable across the whole API.
- Vendor
- obot-platform
- Product
- Obot
- Identifier / CWE
- CVE-2026-101062
CWE-863 - Action timing
- Immediate
Explain it like I’m five
Obot let anyone register a new mailbox with any forwarding address, no questions asked, and never asked the owner for permission. An attacker registered a mailbox forwarding to themselves, tricked a logged-in user into one click, and received that user's keys, keys that opened every room in the building, not just the mailbox.
- 01Open registration
Obot before 0.23.0, running with authentication enabled, exposed OAuth dynamic client registration without authentication and without restriction on the redirect URIs a client may register.
- 02No consent screen
The authorization flow auto-completed for an already logged-in user with no consent screen.
- 03Code to attacker
An attacker who registered a client pointing at their own domain and induced a logged-in victim to visit one crafted authorization URL received an authorization code at the attacker-controlled redirect URI, exchanged for an access token and refresh token.
- 04Token escapes scope
The token minted by the MCP OAuth flow carried the victim's full group set in the JWT, and Obot validated only the issuer, not the audience, so it was accepted as a bearer token against any Obot API endpoint the victim could access.
What happened
Obot before 0.23.0 (affected versions at or below 0.22.1), running with OBOT_SERVER_ENABLE_AUTHENTICATION=true, exposed OAuth dynamic client registration without authentication and without any restriction on the redirect URIs a client may register. Because the authorization flow auto-completed for an already logged-in user with no consent screen, an attacker who registered a client pointing at their own domain and induced a logged-in victim to visit a single crafted authorization URL received an authorization code at the attacker-controlled redirect URI and could exchange it for an access token and refresh token.
The token minted by the MCP OAuth flow carried the victim’s full group set in the JWT, and Obot validated only the issuer and not the audience, so the token was accepted as a bearer token against any Obot API endpoint the victim could access rather than being scoped to the requested MCP server, allowing the attacker to read or modify the victim’s resources until the token was revoked.
Obot 0.23.0 adds a consent screen, restricts MCP OAuth tokens to the MCP involved in the request, and enforces audience validation.
What to do
- Upgrade Obot to 0.23.0 or later.
- Review OAuth client registrations for clients with unexpected or external redirect URIs.
- Revoke tokens issued through the MCP OAuth flow during the exposure window and force re-authentication.
- Audit API access and resource modifications by affected users for activity they did not initiate.
Management note
Two failures compounded here: an unauthenticated registration endpoint and a token that was never scoped to what it was issued for. The upgrade closes both, but token revocation is the step that actually ends an ongoing session an attacker may already hold.