Unauthenticated Attackers Can Steal API Keys in Obot Before 0.26.0
A high-severity authentication bypass in Obot allows attackers to hijack accounts by manipulating token request IDs, requiring immediate updates.
Key points
- CVE-2026-114662 affects Obot versions prior to 0.26.0 with a CVSS score of 8.6.
- The flaw allows unauthenticated attackers to steal non-expiring API keys via the CLI login flow.
- Attackers exploit the vulnerability by creating token requests and sending login links to signed-in users.
Obot versions earlier than 0.26.0 contain a high-severity authentication bypass vulnerability that enables unauthenticated attackers to steal API keys. According to the National Vulnerability Database record for CVE-2026-114662, the flaw resides in the command-line interface login flow. The vulnerability allows attackers to manipulate token request IDs to hijack victim accounts. This issue affects the obot-platform product specifically.
How it unfolded
- The vulnerability was cataloged as CVE-2026-114662 with a CVSS score of 8.6, classified as high severity.
- The record lists CWE-352 as the associated weakness type for this authentication bypass.
- The issue allows attackers to bypass authentication checks when generating tokens through the CLI login process.
Who is affected
Organizations using the obot-platform obot product before version 0.26.0 are affected by this vulnerability. The National Vulnerability Database lists this specific software and version range as impacted. The vulnerability allows attackers to create token requests via the POST /api/token-request endpoint. Attackers can then send a login link to a signed-in user. When the user clicks the link, the attacker can fetch the resulting non-expiring API key. This grants the attacker full control over the victim's account.
Our take on the response
The severity rating of 8.6 indicates a high risk to affected systems. The ability to steal non-expiring API keys without authentication is a significant threat. Attackers can easily initiate the exploit by creating a token request and sending a link. The vulnerability description states attackers can steal API keys by choosing token request IDs. Organizations must verify their current Obot version immediately. If running a version before 0.26.0, the system contains the vulnerability. The impact includes complete account compromise for any user who interacts with the malicious link.
Who needs to act first
Managed service providers should prioritize updating exposed Obot instances immediately. Teams usually begin by identifying systems running versions prior to 0.26.0. Check whether any client environments are exposed to the internet or internal networks where attackers could send login links. Roll out updates in stages, starting with the most accessible systems. Back up configurations before applying changes to ensure recovery options. Test the update in a non-production environment first. Monitor logs for unusual token request activity during the transition.
What to do and how to stay safe: Obot
- Verify the installed version of obot-platform obot on all managed servers and workstations.
- Upgrade to version 0.26.0 or later as soon as the vendor provides the update.
- Monitor application logs for unexpected POST requests to the /api/token-request endpoint.
- Review existing API keys and rotate them if any account compromise is suspected.
Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time
General security guidance from the Patch Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the CVSS score for CVE-2026-114662?
The CVSS score is 8.6, which is classified as high severity.
Which versions of Obot are affected by this vulnerability?
Obot versions before 0.26.0 are affected by this authentication bypass flaw.
How do attackers exploit this vulnerability?
Attackers create a token request and send a login link to a signed-in user to steal the API key.
