Froxlor EUVD-2026-25176

Exploitation requires an authenticated customer or administrator account in Froxlor with API access to the Customers.update or Admins.update endpoints. The attacker must be able to either upload a PHP file to a predictable filesystem location (such as their allocated customer web directory under /var/customers/webs/) or identify an existing PHP file on the server to weaponize. Froxlor instances with default API configurations are vulnerable. The vulnerability does NOT require special server configurations, disabled security features, or non-default settings - standard Froxlor installations prior to version 2.3.6 with API endpoints enabled are exploitable. Limiting factors include: authentication requirement (PR:L) prevents anonymous exploitation, and attackers typically need either file upload capabilities in their hosting space or knowledge of existing PHP file locations on the server filesystem to craft effective path traversal payloads. The scope change (S:C) indicates that successful exploitation can impact resources beyond the Froxlor application itself, specifically other customer hosting environments managed by the same instance.

The CVSS vector AV:N/AC:L/PR:L/UI:N/S:C indicates network-accessible exploitation requiring only low-privileged authentication (customer account) with no user interaction and scope change, yielding a critical 9.9 score. The scope change element is particularly significant - successful exploitation allows attackers to impact resources beyond the vulnerable Froxlor instance itself, potentially compromising hosted customer websites and data given Froxlor's role managing multi-tenant hosting environments. While EPSS data is not provided, the technical accessibility (low complexity, requires only customer-level credentials which may be obtained through phishing or credential stuffing) suggests moderate exploitation probability. No CISA KEV listing or public POC is confirmed at time of analysis, indicating exploitation has not been widely observed, though the technical details in the GitHub Security Advisory (GHSA-w59f-67xm-rxx7) provide sufficient information for skilled attackers to develop exploits. The primary risk factors are: (1) prevalence of Froxlor in shared hosting environments where customer compromise can cascade to other tenants, (2) difficulty detecting malicious language parameters in database records without specific monitoring, and (3) persistence of the payload across sessions until database cleanup. Organizations running multi-tenant Froxlor instances face higher real-world risk than single-tenant deployments. The availability of a vendor patch significantly reduces risk for organizations with active patch management.

An attacker with compromised or legitimately obtained Froxlor customer account credentials authenticates to the Froxlor API and calls the Customers.update endpoint, setting their def_language parameter to ../../../../../var/customers/webs/customer1/shell where they have previously uploaded a PHP webshell disguised as an image or configuration file in their allocated web directory. The malicious path is stored in the database. When the attacker (or any user associated with that customer account) next accesses the Froxlor panel, Language::loadLanguage() constructs the path to their webshell and executes it via require, granting the attacker command execution as the web server user and enabling lateral movement to other hosted customer environments or exfiltration of database credentials.