CVE-2026-100502 in Flame
Summary
by MITRE • 09/26/2026
Flame through 2.4.0 contains an insufficient session expiration vulnerability in the login endpoint that allows attackers with former admin access to obtain tokens with arbitrary lifespans by supplying unvalidated duration parameters. Attackers can mint near-permanent administrator tokens that survive password changes, retaining full control of the dashboard since tokens are verified only against a static JWT secret that is never rotated.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Flame through version 2.4.0 represents a critical authentication flaw rooted in improper session management and inadequate input validation within the login endpoint. This issue specifically affects systems where administrative privileges have been previously granted, allowing attackers who retain knowledge of former admin credentials or access to initiate login requests to exploit weak token generation mechanisms. The core technical deficiency lies in the application's handling of duration parameters during the authentication process. Instead of enforcing a strict maximum lifetime for session tokens based on security policies or default configurations, the system accepts arbitrary values provided by the client without sufficient validation. This lack of boundary checking permits an attacker to request a JWT with an excessively long expiration time, effectively bypassing standard session timeout controls that are designed to limit the window of opportunity for unauthorized access following credential compromise or loss.
From a technical perspective, this vulnerability is exacerbated by the static nature of the JSON Web Token signing secret. In secure implementations, secrets should be rotated periodically and stored securely to mitigate risks associated with key exposure. However, in Flame 2.4.0, the JWT secret remains constant throughout the application's lifecycle. Because token verification relies solely on matching this unchanging secret against a static value, there is no mechanism to invalidate tokens based on time-based criteria other than their explicit expiration claim. Consequently, once an attacker obtains a token with a near-permanent lifespan through the duration parameter manipulation, that token remains valid indefinitely unless manually revoked by an administrator who may not even be aware of its existence. This design flaw means that traditional security controls such as password changes do not serve as effective revocation mechanisms for sessions established via this vulnerable endpoint.
The operational impact of this vulnerability is severe, granting attackers persistent and undetected administrative access to the application dashboard. By minting tokens with arbitrary lifespans, an adversary can maintain full control over system configurations, data integrity, and user management functions long after any initial breach or credential compromise has occurred. This persistence allows for prolonged lateral movement within the network environment if the Flame instance is integrated with other critical systems. Furthermore, because the token verification process does not check against a dynamic revocation list or enforce reasonable maximum lifetimes by default, standard incident response procedures like password resets are rendered ineffective in restoring security posture. The attacker can continue to execute administrative commands, exfiltrate sensitive data, and modify system settings without triggering typical alerts associated with session expiration anomalies.
This vulnerability aligns closely with CWE-613, which describes insufficient session expiration, as well as CWE-284 regarding improper access control due to the failure to enforce proper authentication constraints. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts and potentially T1528 Steal Application Access Token, as it involves leveraging legitimate credentials or tokens for unauthorized persistence. To mitigate these risks, developers must implement strict validation rules that cap the maximum allowable duration for any generated JWT at a reasonable interval defined by organizational security policies. Additionally, implementing token revocation lists or short-lived access tokens paired with refresh tokens would significantly reduce the impact of compromised keys. Regular rotation of signing secrets and ensuring that session invalidation occurs upon significant account changes are also essential steps to restore robust authentication hygiene in affected versions prior to 2.4.1.