CERT/CC has published advisory VU#645818 describing an authentication bypass vulnerability in the console API of the Xerj search and indexing engine—an open solution focused on AI agents and compatible with the Elasticsearch API. The CVE-2026-97406 vulnerability allows an attacker who has a valid API token to create independent “child” credentials with the same level of access, bypassing the passkey authentication requirement. A critically important detail: revoking a compromised parent token does not affect the descendants created from it. At the time the advisory was published, there was no official patch, and CERT/CC coordinators were unable to contact the developer. Organizations using Xerj should immediately audit issued API tokens and restrict access to the console API.
Technical essence of the vulnerability
According to the CERT/CC advisory, Xerj’s architecture requires that the issuance of new API tokens be authorized exclusively by a session confirmed via passkey. However, the implementation converts both regular browser sessions and API bearer tokens into a single generalized AuthSession object. The token creation handler accepts this object without checking whether the session was authenticated specifically via passkey.
The vulnerable attack surface is the built-in console backend which, according to the project’s architecture documentation, is mounted at the path /_xerj-console/api/v1/*. At the same time, the authorization documentation states that only a superuser can create keys with a limited scope — but the vulnerability allows this restriction to be bypassed.
Key characteristics of the vulnerability:
- Precondition: the attacker must obtain or intercept a valid Xerj API token
- Mechanism: direct invocation of the token creation endpoint via bearer authentication without passkey confirmation
- Result: creation of independent credentials with permissions identical to those of the original token
- Persistence: the platform does not implement hierarchical revocation logic — child tokens remain active after the parent is revoked
A CVSS score for CVE-2026-97406 is not provided in the available materials. The range of affected versions has also not been established.
Escalation scenario leading to full instance takeover
According to CERT/CC, the vulnerability is most dangerous when a token belonging to the Xerj account owner is compromised. In this case, the following attack chain is described: the attacker creates a child token with full administrative rights, then uses it to issue an invitation for a new account, activates the invitation in their own browser, and registers a completely independent passkey under their control. The result is persistent access to the Xerj instance and its data indexes, which cannot be eliminated by revoking the initially compromised token.
The advisory characterizes this as a complete bypass of multi-factor controls, since the passkey requirement — the central protection element — is completely neutralized.
Impact assessment
Xerj is positioned as a search engine for AI agents that indexes local data. Compromise of an instance potentially opens access to all indexed data — including source code, documentation, and other materials that AI agents use in their work. For organizations that have integrated Xerj into AI-assisted development workflows, the consequences may include the leakage of intellectual property and compromise of the data supply chain for AI models.
No evidence of active exploitation of the vulnerability in real-world attacks has been found in the available materials. There is also no attribution to specific threat actors or campaigns.
Patch status and recommendations
CERT/CC reports that attempts to contact the developer for coordinated disclosure were unsuccessful, and there was no official patch as of the advisory publication date (20 October 2026). The project’s releases page lists version v1.0.0-rc.96, but the release notes do not mention a fix for CVE-2026-97406. This does not rule out the existence of a fix, but it does not confirm it either.
Until a confirmed patch becomes available, the following is recommended:
- Restrict network access to the console API (
/_xerj-console/api/v1/*) — allow connections only from trusted networks or completely close the endpoint if the console is not used - Audit all issued API tokens — identify tokens created via the API (rather than through a passkey session) and revoke both them and all child credentials potentially derived from them
- Review the history of invitations and passkey registrations — any invitation or registration of a new passkey that followed the creation of an API token should be treated as suspicious
- Set up monitoring — track calls to the token creation endpoint and subsequent invitation issuance or passkey registration operations, as this sequence of actions is characteristic of the described attack chain
- Track updates in the official Xerj repository and do not assume that an update fixes CVE-2026-97406 until this is explicitly confirmed in the release notes
It is fundamentally important to understand that simply revoking a compromised token is not an adequate response measure. Due to the lack of hierarchical revocation logic, all child tokens created before detection remain valid. Incident response must include full rotation of all tokens for the instance and a review of registered passkeys.
