A stolen Xerj API token can issue new tokens that survive revocation of the one an attacker took. CERT/CC describes the Console API authentication bypass as CVE-2026-97406: anyone holding a valid bearer token can mint independent credentials with the same access. For teams using Xerj to index data for AI agents, revoking the compromised token leaves the credentials it minted working.
The CVE record lists Xerj Console API v1.0.0-rc.11 as affected. CERT/CC published its note on October 20 and credits Shiran Guez with reporting the flaw. It reports no official patch, and the Xerj vendor entry is marked unknown; CERT/CC says it received no vendor statement. Check the installed build and watch for a vendor-documented fix before treating an unlisted version as safe.
Bearer tokens pass as sessions
Xerj is a search and indexing engine for AI agents that uses the Elasticsearch API. Its security contract requires a passkey-backed session to issue an API token. But the implementation turns browser sessions and API bearer tokens into the same generic AuthSession object. The token-creation handler accepts that object without checking how the session was authenticated, according to CERT/CC.
That gives a holder of an existing valid token the ability to create another token at the original token’s access level. An ordinary token carries its existing permissions forward. If an account owner’s token is taken, CERT/CC says a successor keeps full administrative authority; the holder can then create an account invitation and enroll a separate passkey. This attack starts with a valid token; the token holder can call the token-creation handler without a passkey-backed session.
Revocation leaves successor credentials
CERT/CC puts the recovery trap plainly: “revoking a compromised parent token has no effect on any descendant tokens spawned from it.” Xerj has no hierarchical revocation linking the issued credentials to their parent, so retiring the known leaked token leaves independently minted tokens active. With an owner token, an attacker-controlled passkey can also keep account access in place.
After revoking a stolen token, check separately for successor tokens and new passkeys. CERT/CC gives no procedure to verify complete removal of descendant credentials; keep recovery open. Treat suspected owner-token theft as an instance access problem, with credential and account recovery coordinated with whoever operates the deployment.
Scope and contain Xerj access
Find Xerj Console API deployments and identify where API tokens are held, starting with owner-level tokens and integrations that can reach sensitive indices. Reduce the Console API’s reachability to the admin network and the clients that need it; that limits who can exercise this path. Retire unnecessary owner tokens, and isolate a deployment when you have reason to suspect one was stolen.
If a token may have escaped, preserve your available token-issuance and account-change records, inspect visible credentials, invitations and passkeys, and coordinate recovery with the instance owner. CERT/CC advises watching the project for a fix; require a vendor-documented correction to passkey-backed issuance and a tested way to remove successor credentials before relying on token revocation as recovery. Until then, keep owner tokens scarce and Console API access tightly scoped.