CVE-2026-79664 in Ech0
Summary
by MITRE • 08/25/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in Ech0 versions prior to 4.7.3 represents a critical failure in the implementation of JSON Web Token revocation logic, specifically affecting tokens issued with a never-expiring configuration. This flaw allows an attacker who has successfully stolen or intercepted such access tokens to maintain persistent authenticated access to the application indefinitely. The core issue stems from multiple independent mechanisms designed to invalidate these tokens failing under specific conditions related to how expiration times and token identifiers are handled within the system's authentication flow.
The first failure point occurs during the user logout process, where the application attempts to revoke active sessions or tokens. When a never-expiring token is processed for revocation via this path, the code encounters a nil value in the ExpiresAt field because such tokens do not have an expiration timestamp set by design. This unhandled null reference causes a panic within the server-side logic, effectively crashing the request handling routine and preventing any actual revocation action from being taken against the token. Consequently, the session remains active despite the user's intent to log out or the system's attempt to terminate it through this specific endpoint.
The second failure lies in the dedicated RevokeToken function which is intended for programmatic invalidation of tokens based on their remaining time-to-live. The logic governing this function checks if the remainTTL value is zero before proceeding with revocation steps. For never-expiring tokens, the TTL calculation results in a state that triggers this condition prematurely or incorrectly, causing the function to skip the actual blacklisting or database update required to invalidate the token identifier. This logical error ensures that even when an administrator or system component explicitly attempts to revoke such a token using standard API calls, the operation is silently ignored due to the flawed conditional check surrounding TTL values.
The third and final failure involves administrative deletion operations which are supposed to blacklist the JWT ID (JTI) associated with the access token. In this context, when an administrator deletes or revokes a never-expiring token through the admin interface, the system fails to add the specific JTI to the global blacklist used for validation checks during subsequent API requests. Because the cryptographic signature of the JWT remains valid and the JTI is not recorded in any denial list, every future request presenting this stolen token will be accepted by the authentication middleware as legitimate. This leaves the compromised account fully accessible until a manual rotation of the signing secret occurs, which would invalidate all tokens regardless of their revocation status but also disrupts service for all other users.
From an industry standard perspective, this vulnerability aligns with CWE-613, Insufficient Session Expiration, as it involves improper handling of session lifetime and invalidation mechanisms. Furthermore, the ability to maintain persistent access after credential theft maps directly to MITRE ATT&CK technique T1078, Valid Accounts, specifically within the context of maintaining persistence through valid authentication credentials that were not properly invalidated upon compromise detection or user logout. The combination of these failures creates a scenario where traditional session management defenses are bypassed entirely for a specific class of tokens.
The operational impact is severe, as it allows attackers to retain long-term access to sensitive systems without needing to repeatedly steal new credentials or exploit additional vulnerabilities. This persistence can lead to data exfiltration, lateral movement within the network, and potential compromise of higher-privilege accounts if the stolen token has elevated permissions. The lack of immediate revocation capability means that detection and response times are critical; however, even with rapid detection, the technical flaw prevents automatic remediation through standard logout or revoke APIs.
Mitigation strategies must address these specific code paths immediately. Developers should update to version 4.7.3 or later where this issue is resolved. In the interim, organizations can implement a workaround by avoiding the use of never-expiring tokens for sensitive operations or enforcing shorter expiration times even if refresh token logic is employed. Additionally, implementing server-side session state management that does not rely solely on JWT claims for revocation decisions can provide an additional layer of security. Monitoring logs for nil pointer exceptions during logout requests and reviewing admin deletion audit trails may help identify active exploitation attempts before significant damage occurs.