Description

Obot before v0.23.0 (affected versions <= v0.22.1) running with OBOT_SERVER_ENABLE_AUTHENTICATION=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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-27T21:17:01.617Z",
  "pubdate": "2026-09-27T21:17:01.617Z",
  "executiveSummary": "Obot versions <= v0.22.1 are vulnerable to an unauthorized OAuth dynamic client registration flaw when OBOT_SERVER_ENABLE_AUTHENTICATION is set to true.\nThe vulnerability allows an unauthenticated attacker to register arbitrary OAuth clients without redirect URI validation.\nBy leveraging a lack of user consent and improper JWT audience validation, an attacker can perform a cross-site request forgery-style attack to obtain valid access and refresh tokens for any logged-in victim.\nThis impact includes full account impersonation, as the minted tokens inherit the victim's group claims and are accepted globally across all Obot API endpoints due to the absence of audience scoping.\nThe risk is critical, as it bypasses authorization mechanisms and allows persistent unauthorized access to victim resources until token revocation.\nExploitation requires the victim to have an active session and be induced to visit an attacker-controlled authorization URL.",
  "technicalDetails": "The vulnerability originates from two primary security failures within the Obot OAuth implementation: the exposure of dynamic client registration without authentication and the absence of strictly enforced token scoping.\nWhen OBOT_SERVER_ENABLE_AUTHENTICATION is enabled, the dynamic client registration endpoint fails to verify the identity of the requester. Furthermore, the system permits the registration of arbitrary redirect URIs, allowing an attacker to intercept authorization codes.\nThe exploitation flow proceeds as follows: First, an attacker registers a malicious OAuth client via the dynamic registration endpoint, providing an attacker-controlled URL as the redirect URI. Second, the attacker crafts an authorization URL directed at the victim. When a logged-in victim visits this URL, the Obot server auto-completes the authorization flow without presenting a consent screen to the user. The server then transmits the authorization code to the attacker's redirect URI.\nOnce the attacker possesses the authorization code, they exchange it for an access token and a refresh token. Because the system previously failed to validate the audience of the JWT, these tokens are not scoped exclusively to the intended MCP (Model Context Protocol) server. Instead, they are accepted as valid bearer tokens across any Obot API endpoint the victim is authorized to access.\nThe resulting tokens contain the victim's full set of group claims, granting the attacker the victim's effective permissions. This facilitates unauthorized resource modification or data extraction. The lack of an explicit user consent mechanism is a critical design failure, as it prevents the user from identifying that an authorization request is being initiated by an untrusted third party. The combination of unauthenticated registration, missing consent, and lack of audience validation elevates this from a minor configuration issue to a full account takeover primitive for authenticated sessions."
}