Skip to main content
Vulnerability Database/CVE-2026-100712

CVE-2026-100712: Froxlor CSRF Vulnerability

CVE-2026-100712 is a cross-site request forgery vulnerability in Froxlor that allows attackers to disable two-factor authentication via unauthenticated GET requests. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-100712 Overview

CVE-2026-100712 is a Cross-Site Request Forgery (CSRF) vulnerability [CWE-352] in Froxlor server management panel through version 2.3.10. The flaw allows an attacker to disable a logged-in user's two-factor authentication (2FA) through an unauthenticated-triggerable GET request to the 2FA management endpoint. No confirmation, re-authentication, or CSRF token is required. Both customer and administrator 2FA handlers are affected. An attacker who lures a logged-in panel user to a crafted link silently clears the victim's 2FA configuration, reducing the account to password-only authentication. The issue is fixed in Froxlor 2.3.12.

Critical Impact

Successful exploitation strips 2FA from a victim's Froxlor account via a single link click, enabling account takeover when combined with a compromised password.

Affected Products

  • Froxlor server management panel versions through 2.3.10
  • Customer panel 2FA handler (/customer_index.php?page=2fa)
  • Admin panel 2FA handler (equivalent admin endpoint)

Discovery Timeline

  • 2026-09-26 - CVE-2026-100712 published to the National Vulnerability Database (NVD)
  • 2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-100712

Vulnerability Analysis

Froxlor exposes 2FA management actions through GET parameters on customer_index.php and the equivalent admin page. Issuing a request such as /customer_index.php?page=2fa&action=delete instructs the application to clear the authenticated user's type_2fa and data_2fa fields immediately. The handler performs the destructive action without prompting for the current password, the TOTP code, or any confirmation step.

The issue is amplified by two framework-level decisions. The global CSRF middleware validates tokens only on POST, PUT, PATCH, and DELETE methods. The session cookie is configured with SameSite=Lax, which permits the session to accompany cross-site top-level navigations such as link clicks and HTTP redirects. Together these conditions make the 2FA removal path trivially reachable from an attacker-controlled page.

Root Cause

The root cause is a combination of state-changing operations exposed over HTTP GET and a CSRF protection layer that does not cover GET requests. Any security-relevant action that mutates account state must be reachable only through protected methods or must require re-authentication. Neither control is present on the 2FA delete flow.

Attack Vector

Exploitation requires an authenticated Froxlor user to visit or be redirected to an attacker-controlled resource while holding an active session. The attacker embeds the crafted URL in an <a> tag, <img> tag, window.location redirect, or a shortened link delivered via email or chat. When the victim's browser issues the top-level navigation, the SameSite=Lax session cookie accompanies the request, and Froxlor processes the 2FA deletion. The attacker gains no direct feedback but can verify success by observing subsequent login behavior or by chaining with credential-stuffing or phishing. See the GitHub Security Advisory GHSA-w582-7wqv-62mm and the VulnCheck Advisory: Froxlor CSRF Bypass for additional technical detail.

Detection Methods for CVE-2026-100712

Indicators of Compromise

  • Web server access log entries containing page=2fa with action=delete as a GET request, especially with a Referer header pointing to an external domain.
  • Audit log entries showing type_2fa or data_2fa cleared on an account without a corresponding user-initiated configuration change.
  • User reports of unexpected 2FA removal or prompts to re-enroll a second factor after a routine browsing session.

Detection Strategies

  • Alert on any GET request to the Froxlor 2FA endpoints that includes a destructive action parameter, particularly from off-site referrers.
  • Correlate 2FA state changes in the database with authenticated login events to identify silent removals that lack a preceding administrative UI workflow.
  • Hunt for sequences in which 2FA is disabled and shortly followed by a successful login from a new IP address, user agent, or geolocation.

Monitoring Recommendations

  • Enable verbose authentication and account-change logging in Froxlor and forward events to a centralized SIEM.
  • Monitor Froxlor administrator and customer accounts for 2FA toggles and generate alerts for state transitions.
  • Track outbound referrers in reverse-proxy logs that precede Froxlor 2FA deletions to attribute campaigns.

How to Mitigate CVE-2026-100712

Immediate Actions Required

  • Upgrade Froxlor to version 2.3.12 or later, which contains the vendor fix.
  • Invalidate all active Froxlor sessions after upgrading and require users to re-authenticate.
  • Audit all accounts for 2FA status and require re-enrollment where unexpected removal is observed.
  • Notify Froxlor users of the risk and instruct them not to click untrusted links while logged in to the panel.

Patch Information

The vulnerability is remediated in Froxlor 2.3.12. The upstream fix enforces CSRF protection on the 2FA management flow and prevents state-changing operations from being executed via unprotected GET requests. Review the GitHub Security Advisory GHSA-w582-7wqv-62mm for the full change set and version matrix.

Workarounds

  • Restrict access to the Froxlor administration interface to trusted source IP addresses via a reverse proxy or firewall rule.
  • Configure a web application firewall rule that blocks GET requests to customer_index.php and the admin equivalent when page=2fa and action=delete are present.
  • Change the session cookie SameSite attribute to Strict at the reverse-proxy layer to prevent cross-site navigations from carrying the session.
  • Advise panel users to log out of Froxlor when not actively administering the system.
bash
# Example nginx rule to block GET-based 2FA deletion until upgrade is complete
location ~ ^/(customer_index|admin_index)\.php$ {
    if ($request_method = GET) {
        set $block "";
        if ($arg_page = "2fa") { set $block "${block}1"; }
        if ($arg_action = "delete") { set $block "${block}1"; }
        if ($block = "11") { return 403; }
    }
    # existing PHP handler configuration follows
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.