CVE-2026-100712 in Froxlor
Summary
by MITRE • 09/26/2026
froxlor through 2.3.10 disables a user's two-factor authentication immediately upon an unauthenticated-triggerable GET request to the 2FA management page (e.g. /customer_index.php?page=2fa&action=delete), with no confirmation, re-authentication, or CSRF token. The global CSRF middleware only covers POST/PUT/PATCH/DELETE requests, and the session cookie is set to SameSite=Lax, so a cross-site top-level navigation (link click or redirect) carries the victim's session and silently clears type_2fa/data_2fa. Both the customer and admin 2FA handlers are affected. An attacker who lures a logged-in panel user into following a crafted link reduces that account to password-only authentication, which can be chained with a compromised password for account takeover. Fixed in 2.3.12.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Froxlor versions up to and including 2.3.10 represents a critical failure in access control mechanisms, specifically targeting the integrity of two-factor authentication (2FA) configurations. This flaw allows an unauthenticated attacker to disable multi-factor security for any logged-in user by exploiting improper handling of HTTP GET requests within the application's session management logic. The core technical issue lies in the execution path triggered when a victim visits a specific URL, such as /customer_index.php?page=2fa&action=delete. Unlike standard secure practices where destructive actions require explicit confirmation or re-authentication, this endpoint executes immediately upon receipt of the GET request. This design choice bypasses essential security controls that are typically mandated to prevent accidental or malicious state changes in administrative interfaces.
From a technical perspective, the vulnerability stems from an incomplete implementation of Cross-Site Request Forgery (CSRF) protections within the application's middleware layer. The global CSRF middleware is configured exclusively to protect POST, PUT, PATCH, and DELETE HTTP methods. Consequently, GET requests are treated as safe, read-only operations that do not require anti-CSRF tokens or verification mechanisms. This misalignment with industry standards creates a significant attack surface because it assumes that state-changing actions will never be initiated via simple link clicks or redirects. Furthermore, the session cookie is configured with the SameSite attribute set to Lax. While this setting restricts some types of cross-site requests, it permits top-level navigations such as clicking a hyperlink or following an HTTP redirect from another domain. This configuration allows an attacker's malicious page to trigger the vulnerable GET request in the victim's browser context while automatically attaching their valid session cookie, thereby authenticating the forged request without any user interaction beyond visiting the malicious site.
The operational impact of this vulnerability is severe, as it effectively strips away a primary layer of defense for user accounts. By disabling both type_2fa and data_2fa fields in the database through a silent background process, the attacker reduces the account's authentication method to password-only. This degradation of security posture can be directly chained with other threats such as credential stuffing or phishing attacks where passwords are compromised. Once an attacker possesses a valid username and password for a Froxlor user who has had their 2FA disabled via this vulnerability, they gain full unauthorized access to the account without needing to bypass any additional authentication factors. This is particularly dangerous in administrative contexts where elevated privileges could lead to broader system compromise or data exfiltration affecting multiple customers hosted on the same server infrastructure.
This flaw aligns with CWE-352, which describes Cross-Site Request Forgery vulnerabilities resulting from insufficient verification of request intent and origin. Additionally, it relates to CWE-862, a Missing Authorization check, as the application fails to verify that the user explicitly intends to perform this destructive action before executing it. In terms of offensive security frameworks, this vulnerability facilitates techniques associated with MITRE ATT&CK T1556, specifically Modifying Authentication Processes or Multi-Factor Authentication mechanisms. Attackers can leverage social engineering tactics to lure victims into clicking malicious links, thereby silently downgrading the account's security profile without raising alarms through unusual login patterns that might otherwise trigger alerts for missing 2FA codes.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary solution is to upgrade Froxlor to version 2.3.12 or later, where this issue has been resolved by the vendor. For environments unable to patch immediately, administrators should consider implementing reverse proxy rules that block GET requests to sensitive administrative endpoints if possible, although application-level fixes are preferred. Long-term remediation requires a comprehensive review of CSRF protection policies across all state-changing operations. Developers must ensure that any action modifying user security settings or account status utilizes POST methods with robust anti-CSRF tokens rather than relying on HTTP method semantics alone. Additionally, enforcing stricter SameSite cookie attributes such as Strict for sensitive sessions can further reduce the risk of cross-site context leakage. Regular audits of authentication flows should also be conducted to ensure that destructive actions always require explicit user confirmation and potentially re-authentication via password or 2FA code entry before execution.