Froxlor CVE-2026-100712

Requires an authenticated Froxlor session to already exist in the victim's browser AND the victim to follow an attacker-supplied link (top-level navigation) - this is the UI:P/UI:R limiting factor; the attacker themselves is unauthenticated. Works against default configurations because the CSRF middleware only guards POST/PUT/PATCH/DELETE (not the GET delete action) and the session cookie uses SameSite=Lax, which permits cross-site top-level GET navigations to carry the cookie. Affects both customer and admin 2FA handlers. Standalone the attack only removes 2FA; full account takeover additionally requires the victim's password to already be compromised.

This is a genuine but modest-severity CSRF (CWE-352) affecting Froxlor's 2FA management. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) correctly captures an unauthenticated network attacker who needs the victim to click a link - but the VC:H (high confidentiality) impact claim is questionable: silently disabling 2FA does not disclose data, it degrades an authentication control (an integrity impact on account security state). The real-world impact is LATENT - it only enables account takeover when chained with an already-compromised password, so a defense-in-depth layer is removed rather than access being directly granted. No EPSS score, no CISA KEV listing, and no public exploit code are present in the input, so there is no signal of active or automated exploitation. Net: a real, low-friction bug worth patching (trivially triggerable via a crafted link, no CSRF token, GET bypasses the POST/PUT/PATCH/DELETE-only middleware, SameSite=Lax permits the top-level navigation) but its standalone severity is Medium at most - the vendor's 7.1 overstates it via the VC:H choice.

An attacker sends a logged-in Froxlor customer or admin a link (email, chat, or a redirect on a malicious page) pointing to /customer_index.php?page=2fa&action=delete. Because the cookie is SameSite=Lax and the GET request rides the victim's session with no CSRF token or confirmation prompt, the victim's 2FA is silently cleared on click. The attacker, having previously phished or leaked the victim's password, then logs in unimpeded. No public exploit code is identified in the provided data.