Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:56.417Z",
  "pubdate": "2026-09-26T14:16:56.417Z",
  "executiveSummary": "Froxlor versions up to and including 2.3.10 are vulnerable to a second-factor authentication (2FA) bypass due to insecure session token validation.\nThe vulnerability originates from the system's reliance on numeric user IDs within the 'panel_2fa_tokens' table without account namespace validation.\nBecause administrative and customer accounts share overlapping ID namespaces, a valid 2FA token issued for a customer can be cross-utilized to authenticate as an administrator.\nThe impact is significant, as it allows an authenticated attacker who possesses a valid customer-side 2FA cookie and the target administrator's password to circumvent the TOTP second-factor requirement.\nSuccessful exploitation grants the attacker full administrative access to the Froxlor panel, leading to potential full system compromise.\nThis vulnerability requires the attacker to hold a valid, non-expired 'remembered-2FA' token from a controlled customer account and possess the target administrator's legitimate credentials.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of the session management logic within the Froxlor 2FA authentication flow. When a user elects to 'remember' their 2FA status, the application stores a token in the 'panel_2fa_tokens' database table. This record maps the token directly to a numeric user ID but fails to include a discriminator or namespace identifier to distinguish between account types (customer vs. administrator).\nIn the Froxlor architecture, customer IDs and administrator IDs are assigned from independent but overlapping integer sequences. Consequently, if Customer ID '5' and Administrator ID '5' both exist within the system, the application's lookup mechanism for remembered-2FA tokens fails to enforce type-specific scoping. When the lookup query executes, it selects the record based solely on the integer ID matching the incoming session token, regardless of the role context.\nThe attack flow proceeds as follows: 1. The attacker creates or controls a customer account with a specific numeric ID (e.g., ID 101). 2. The attacker triggers the creation of a 'remembered-2FA' cookie for this account. 3. The attacker obtains the plaintext password of a target administrator who happens to share the same numeric ID (ID 101). 4. During the login attempt for the administrator account, the attacker submits the compromised administrator password along with the 2FA token cookie generated during their customer session. 5. The backend, upon validating the password, queries the 'panel_2fa_tokens' table for a token associated with ID 101. 6. The query retrieves the customer-side token because it matches the numeric ID requested. 7. The application incorrectly treats this token as valid for the administrator session, bypassing the TOTP check and granting the attacker administrative access.\nThis vulnerability is strictly a bypass of the secondary factor and does not circumvent the requirement for a valid password. However, in scenarios where the administrator password is known—via social engineering, credential stuffing, or other leak vectors—the 2FA protection is rendered completely ineffective."
}