GHSA-xwmw-prc4-v3cr

## Summary 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.2