CVE-2026-100709 in Froxlor
Summary
by MITRE • 09/26/2026
Froxlor through 2.3.10 stores only a numeric user ID in remembered-2FA tokens (panel_2fa_tokens) without recording the account namespace, and the remembered-token lookup during login is not constrained to the customer or administrator account type. Because customer and administrator IDs are allocated from separate namespaces, a remembered-2FA token legitimately issued to a customer with a given ID also matches an administrator with the same ID. An attacker who controls a customer account with a colliding ID, holds a valid remembered-2FA cookie for it, and already knows the target administrator's password can bypass the administrator's TOTP second factor and obtain an authenticated administrator session. This is a second-factor bypass only; it does not defeat password authentication. Fixed in 2.3.12.
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 Froxlor versions through 2.3.10 represents a critical flaw in the implementation of multi-factor authentication token management, specifically within the mechanism used for remembering two-factor authentication status via cookies labeled as panel_2fa_tokens. The core technical deficiency lies in how these tokens are constructed and validated during subsequent login attempts. When a user successfully authenticates with their password and a valid time-based one-time password (TOTP), the system generates a persistent cookie to bypass future TOTP challenges for that session duration. However, this token stores only the numeric identifier of the authenticated entity without including any metadata regarding the account namespace or role type. This design oversight creates an ambiguity in identity resolution where the system fails to distinguish between different classes of users who may share identical numerical identifiers within their respective domains.
In typical web application architectures involving Froxlor, customer accounts and administrator accounts are managed in separate namespaces with independent ID allocation schemes. Consequently it is statistically possible for a low-privilege customer account to possess the same numeric identifier as a high-privilege administrator account. Because the remembered token lookup logic does not constrain its search by role or namespace, any valid 2FA cookie associated with a specific numerical ID will be accepted regardless of whether that ID belongs to a customer or an administrator. This lack of contextual validation allows for a direct cross-role identity collision attack vector where the system incorrectly maps a customer's authentication token to an administrator account sharing that same numeric value.
The operational impact of this vulnerability is severe, as it enables a complete bypass of the second factor of authentication for administrative accounts under specific conditions. An attacker who has compromised or controls a legitimate customer account with a known ID can leverage a valid remembered-2FA cookie obtained from their own session to authenticate as an administrator possessing that same numeric identifier. The attack chain requires the attacker to already possess the target administrator's password, which suggests this is often facilitated by credential stuffing attacks, phishing, or previous data breaches where administrative credentials have been exposed. Once the password is known and combined with the stolen 2FA token from a colliding customer ID, the system grants full authenticated access to the admin panel without requiring the actual TOTP code generated by the administrator's authenticator device. This effectively neutralizes the security benefit of two-factor authentication for any administrative account whose numeric ID conflicts with an existing or newly created customer account.
From a classification perspective, this vulnerability aligns closely with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity within the context of token-based session management. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, specifically regarding the misuse of legitimate credentials combined with stolen authentication tokens to escalate privileges or gain unauthorized access. The flaw highlights a fundamental misunderstanding in security design where unique identifiers are treated as globally unique across all user roles rather than being scoped strictly within their respective administrative boundaries. This is particularly dangerous because it undermines trust in multi-factor authentication systems, which rely on the assumption that possession of a valid token and password corresponds to a single specific identity.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary fix involves upgrading Froxlor to version 2.3.12 or later where this issue has been resolved by ensuring tokens are scoped correctly to the account type. For systems that cannot immediately upgrade, administrators should enforce strict password policies to reduce the risk of credential compromise which is a prerequisite for exploiting this flaw. Additionally implementing IP-based restrictions on administrative login pages can limit exposure if an attacker obtains valid credentials and tokens. Long-term architectural changes should include redesigning session token generation to explicitly bind the user role or namespace identifier within the encrypted payload, ensuring that even if numeric IDs collide across different tables, the system will reject any attempt to use a customer's authentication context for administrative access. Regular audits of ID allocation strategies can also help minimize the probability of such collisions occurring in the first place.