Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-26T14:16:56.903Z",
  "pubdate": "2026-09-26T14:16:56.903Z",
  "executiveSummary": "Froxlor versions through 2.3.10 contain a critical Cross-Site Request Forgery (CSRF) vulnerability affecting the two-factor authentication (2FA) management functionality. The vulnerability allows an unauthenticated attacker to programmatically disable a logged-in user's 2FA settings without requiring secondary confirmation or re-authentication.\nThe flaw stems from the application's failure to enforce CSRF protections on GET-based state-changing requests. Since the application’s global CSRF middleware is restricted to state-changing HTTP verbs (POST, PUT, PATCH, DELETE) and utilizes a SameSite=Lax cookie policy, an attacker can successfully execute the 2FA deletion process by tricking a victim into clicking a crafted link or via malicious cross-site navigation.\nThe impact is severe, as successful exploitation results in the complete bypass of 2FA for the target account, effectively reducing the account security posture to password-only authentication. This vulnerability facilitates account takeover (ATO) scenarios when combined with a compromised password. The vulnerability affects both customer and administrative user roles, posing a significant risk to overall panel integrity. It is strongly recommended to update to version 2.3.12, where this issue has been resolved.",
  "technicalDetails": "The vulnerability resides in the 2FA management module of the Froxlor web panel, specifically triggered via the path '/customer_index.php?page=2fa&action=delete'. The root cause is the handling of sensitive state-changing operations via the HTTP GET method, which is inherently susceptible to CSRF attacks because browsers automatically include session cookies in cross-site requests.\nWhile Froxlor implements a global CSRF middleware, its design is flawed as it explicitly excludes GET requests from validation. Furthermore, the reliance on the 'SameSite=Lax' cookie attribute is insufficient to prevent this attack. Because the 2FA deletion action is reachable via a top-level navigation (such as a standard hyperlink click or a meta-refresh/redirect), the browser sends the victim's authentication session cookie to the server. The application then processes the request as a legitimate, authenticated instruction to clear the 'type_2fa' and 'data_2fa' session variables associated with the account.\nExploitation flow: 1. An attacker identifies the target endpoint '/customer_index.php?page=2fa&action=delete'. 2. The attacker crafts a malicious URL or a hidden iframe/redirect containing the target path. 3. The attacker lures a victim who possesses an active Froxlor management session to click the link or visit a site that triggers the request. 4. The browser executes the GET request, including the victim's session cookie. 5. The application verifies the session as valid and, lacking CSRF token verification for GET requests, processes the deletion of 2FA settings for the account. 6. The 2FA is silently removed, leaving the account vulnerable to unauthorized access if the password is known or subsequently compromised.\nThe vulnerability affects both customer and admin panels, meaning an attacker could potentially disable 2FA for administrative accounts, leading to a full compromise of the panel management environment. The absence of additional authentication checks—such as requiring the user's password or an existing 2FA code before authorizing the removal of 2FA—compounds the issue. Version 2.3.12 remediates this by ensuring state-changing operations are protected against CSRF and by enforcing stricter validation logic for sensitive security changes."
}