Xerj Console API authentication bypass allows successor token creation
15th article in the last 90 days, one of 80 articles referencing GitHub. Previous coverage: Netskope details four AI security blindspots controls miss (Oct 2026).
Companies mentioned
Best suited for
- Seniority
- Analyst
- Job function
- Cybersecurity / Security Analyst
- Persona
- Security Operations Leader
- Buyer role
- Technical Implementer / Administrator
- Decision stage
- How to start
- Adoption curve
- Early Adopters
- Technology maturity
- Emerging Exploration
- Industry
- Information Technology / Cybersecurity / Identity Security / Identity & Access Management (Workforce IAM/SSO/MFA)
Our classification, not the publisher's statement. Best suited for, not only for.
The Xerj Console API contains an authentication bypass that allows sessions to skip passkey-backed requirements during token issuance. Xerj is an open-source search and indexing engine built for AI agents on the Elasticsearch API, and this flaw can be used to create persistent successor credentials.
The vulnerability is tracked as CVE-2026-97406. According to the documented security contract, issuing new API tokens must be strictly authorized by a passkey-backed session. The Xerj implementation, however, converts both standard browser sessions and API bearer tokens into the same generic AuthSession object, and the token creation handler accepts that generalized principal without checking whether it was authenticated with a passkey.
An attacker who obtains or intercepts a valid Xerj API token can directly call the token creation endpoint and create independent successor credentials carrying the same access levels as the original token. The platform also lacks hierarchical revocation logic, so revoking a compromised parent token has no effect on descendant tokens spawned from it.
Exploitation enables persistent, unauthorized access that completely bypasses multi-factor controls. If the compromised token belongs to a Xerj account owner, the successor token retains full administrative authority. The attacker can use that access to issue a new account invitation, redeem it in their own browser, and enroll an independent, attacker-controlled passkey, which grants permanent control over the Xerj instance and its sensitive data indices. Revoking the initial token is rendered ineffective in this scenario.
The vendor could not be reached to coordinate this vulnerability, and an official patch had not been made available at the time of writing. Users are advised to monitor the project's GitHub repository for updates and to install the latest version of the library once a fix has been released.
The reporter, Shiran Guez, a Principal Application Security Architect, is credited. This document was written by Laurie Tyzenhaus.
Blog post, originally published by Laurie Tyzenhaus at kb.cert.org.