Obot before v0.23.0 (versions up to 0.22.1) permits OAuth dynamic client registration to be performed without any authentication and does not restrict the redirect URIs that a client may register. The authorization flow automatically completes for an already logged‑in user without showing a consent screen. An attacker can register a client that points to the attacker’s own domain, lure a victim to visit a single crafted authorization URL, obtain an authorization code at the attacker‑controlled redirect URI, and exchange that code for an access token and a refresh token. The token produced by the MCP OAuth flow contains the victim’s full group set in its JWT payload, and Obot verifies only the issuer, not the audience. Consequently, the attacker can use the token as a bearer token against any Obot API endpoint the victim can access, enabling the attacker to read or modify the victim’s resources until the token is revoked. The flaw satisfies CWE‑863, where a privilege dependency is exploited to bypass authorization.

The issue affects the obot-platform’s obot product, specifically versions 0.22.1 and earlier when OBOT_SERVER_ENABLE_AUTHENTICATION is set to true. Users running these versions are vulnerable unless the dynamic client registration feature is disabled.

The vulnerability has a CVSS score of 8.7 and is not listed in the CISA KEV catalog. EPSS data is not available, but the lack of any authentication or redirect‑URI restrictions means an attacker only needs social engineering to get a victim to visit a crafted URL; no local privilege or code execution is required beyond the normal OAuth authorization flow. Once the attacker obtains the victim’s token, the flawed token validation logic allows the attacker to act with the victim’s privileges across all accessible APIs. Given the high impact and the fairly straightforward exploit path, the overall risk is high, especially for environments that rely on Obot’s authorization mechanisms.