1-minute read
What a defender needs to know
A stolen Xerj API token can outlive its own revocation through the credentials it creates. CERT/CC says the Console API turns both passkey-backed browser sessions and API bearer tokens into a generic AuthSession. The token-creation handler accepts the bearer-token principal without enforcing its intended passkey check. A valid token holder can mint independent successor tokens at the same access level. The CVE record lists Xerj Console API v1.0.0-rc.11 as affected by CVE-2026-97406.
An owner-level token is especially sensitive: CERT/CC says a successor retains administrative authority and can support a new account invitation and separate passkey enrollment. Revoking the original token leaves successor tokens active. CERT/CC reports no official patch as of October 20 and no vendor statement.
Locate Xerj Console API deployments and owner-level tokens used by your integrations. Restrict Console API access to the admin network and necessary clients, retire unnecessary owner tokens, and isolate an instance if token theft is suspected. Keep available issuance and account-change records; inspect visible tokens, invitations and passkeys during recovery. Keep recovery open after revoking the original token; CERT/CC gives no procedure to verify removal of every successor credential. Watch for a documented passkey-enforcement fix and a tested credential-removal path before counting the instance recovered.