Froxlor CVE-2026-100711

Exploitation requires the attacker to already possess a still-valid authentication artifact for a Froxlor account before version 2.3.12 - specifically a hijacked panel session cookie, an issued API key, or a 2FA 'trust this device' cookie - obtained through a separate prior compromise. The vulnerability only manifests when the legitimate user changes their password (the intended remediation) yet Froxlor fails to invalidate these existing artifacts. The limiting factor is significant: without prior credential/token theft the flaw is inert, so this is a chained, post-compromise persistence issue rather than remote unauthenticated initial access; impact scope also depends on whether the compromised account is a customer or an admin/reseller.

The provided CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VC:H, base 8.7) overstates real-world risk because it ignores the vulnerability's defining precondition: the attacker must ALREADY hold a hijacked session cookie, a valid API key, or a 2FA trust token before this flaw yields any value. CWE-613 (Insufficient Session Expiration) is accurate; this is a post-compromise persistence/remediation-failure issue, not an initial-access authentication bypass, so PR:N with AC:L misrepresents it - a prior credential-theft event is a condition outside the attacker's control (AC:H in my assessment). The vendor's own VI:N/VA:N is internally inconsistent with 'retain full account access,' which plainly includes the ability to modify account state (I should be High). No EPSS score, no CISA KEV listing, and no public POC are present, so there is no signal of active or automatable exploitation; the value is entirely as a follow-on to an already-successful account compromise. Net: high nominal CVSS but conditional, chained risk - a genuine incident-response gap that matters most to defenders who believe a password reset restored control, rather than a standalone widely-exploitable flaw.

An attacker who has already stolen a Froxlor panel session, API key, or 2FA trust cookie (via phishing, XSS, or token leak) continues using it. The victim or an administrator detects suspicious activity and rotates the account password as a containment step, but the stolen session/key/token remains valid, so the attacker keeps full account access and defeats the incident-response action. No public exploit code is identified; exploitation is trivial once the token is held but depends entirely on that prior compromise.