Obot CVE-2026-114662

Exploitation requires that (1) the attacker can reach the token-request endpoint POST /api/token-request on the Obot instance over the network without authentication, and (2) a currently signed-in Obot user is tricked into opening the attacker-crafted CLI login link and completing the login flow (the UI:P / passive-interaction requirement). The core technical prerequisite is the CLI login flow's use of attacker-choosable token request IDs, which lets the attacker predict and later retrieve the victim-bound non-expiring API key. Limiting factors: exploitation needs a social-engineering step to deliver the login link to an authenticated victim, so it cannot be fully automated against arbitrary targets; it affects Obot versions before 0.26.0 only, and the non-expiring nature of the stolen key means compromise persists until the key is manually revoked.

This is a genuinely serious flaw that warrants prompt remediation, but it is not a drop-everything internet-wide emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H) correctly captures a network-reachable, low-complexity, unauthenticated attack whose only gating factor is passive victim interaction (clicking an attacker-supplied login link), yielding high confidentiality and integrity impact via full account takeover. The CWE-352 (CSRF) classification combined with the description's 'choosing token request IDs' detail indicates a predictable/attacker-controlled identifier problem layered on top of a cross-site request flow - a design-level authentication bypass rather than a memory-safety edge case. Mitigating the urgency: no EPSS score was provided, the CVE is NOT in CISA KEV, and no public POC is referenced, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical constraint is the UI:P requirement - a signed-in victim must be socially engineered into opening the login link - which makes this better suited to targeted phishing than mass automated exploitation. Net: high-severity by impact, real priority for any Obot operator, but real-world exploitation depends on social engineering and the product's relatively limited deployment footprint, not on worm-like automatability.

An unauthenticated attacker calls POST /api/token-request with a chosen (attacker-known) token request ID, then sends the corresponding CLI login link to a signed-in Obot user via phishing. When the victim clicks and completes the login flow, the attacker fetches the resulting non-expiring API key tied to that request ID and uses it to fully take over the victim's account. No public exploit is referenced, but the attack is low-complexity and requires only passive victim interaction.