CVE-2026-79664: Ech0 before 4.7.3 Access Token Revocation Bypass
Ech0 before 4.7.3 fails to properly revoke access tokens created with never-expire option, allowing attackers to maintain perpetual authenticated access after token theft. Three independent revocation mechanisms fail: logout panics on nil ExpiresAt field, RevokeToken skips when remainTTL is zero, and admin delete does not blacklist the JTI, leaving stolen tokens cryptographically valid until JWT secret rotation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Ech0to a version that resolves this vulnerability.Fixed in 4.7.3
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments of Ech0 before 4.7.3 are exposed if access tokens can be created with the never-expire option. The practical impact is greatest where an attacker has stolen such a token, because it can continue to authenticate after attempted revocation.
What does an attacker need to exploit the bypass?
An attacker needs possession of a never-expiring access token. No additional privileges or user interaction are required to continue using the token after logout, token revocation, or administrative deletion attempts.
Are normal token-revocation actions sufficient to invalidate an affected token?
No. Logout can panic when ExpiresAt is nil, RevokeToken skips tokens whose remaining TTL is zero, and administrative deletion does not blacklist the token JTI. The token remains cryptographically valid until the JWT secret is rotated.
What can be done if upgrading is not immediately possible?
Rotate the JWT secret to invalidate affected stolen tokens. This is the documented mechanism that makes the still-cryptographically-valid tokens unusable.