Obot CVE-2026-101062

Requires Obot running with OBOT_SERVER_ENABLE_AUTHENTICATION=true (this specific server setting must be enabled), plus a victim who is already logged into Obot and who visits a single attacker-crafted OAuth authorization URL. The attacker needs no account or privileges on Obot (unauthenticated dynamic client registration is reachable), but exploitation is gated by the required victim interaction (clicking the malicious link) and by the non-default authentication-enabled deployment mode. It affects versions <= v0.22.1; v0.23.0 remediates via a consent screen, token audience restriction to the requested MCP server, and audience validation.

The vendor CVSS 4.0 base score is 8.7 (High) and the GHSA-cited CVSS 3.1 is 8.8, driven by network vector (AV:N), low complexity (AC:L), no attacker privileges (PR:N) and high confidentiality/integrity/availability impact - tempered only by required user interaction (UI:P). No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided, so exploitation status is: no public exploit identified at time of analysis. The high CVSS reflects a genuine, well-understood authorization flaw (CWE-863: three chained defects - unauthenticated OAuth dynamic client registration with unrestricted redirect URIs, consent-less auto-completion of the authz flow, and missing JWT audience validation), but two factors materially lower real-world urgency: it only applies when OBOT_SERVER_ENABLE_AUTHENTICATION=true is set, and it requires a currently-logged-in victim to click a single attacker-crafted authorization URL (a phishing/social step). This is a real, credible authorization bypass worth patching, but the non-default auth prerequisite plus the required victim interaction and the absence of KEV/EPSS/POC signals make it targeted-effort rather than mass-exploitable. Note the input CVSS 4.0 vector uses UI:P (passive) whereas the attack narrative (victim must actively click a crafted link) is better modeled as active interaction - a minor scoring nuance to verify with the vendor.

An attacker uses Obot's unauthenticated OAuth dynamic client registration to register a client whose redirect URI points to their own domain, then emails a logged-in Obot user a single crafted authorization URL. Because the flow auto-completes with no consent screen, the victim's browser silently delivers an authorization code to the attacker, who exchanges it for access and refresh tokens carrying the victim's full group set; since Obot validated only the issuer and not the audience, the tokens work as bearer credentials against any API the victim can reach. No public exploit code is identified at this time.