CVE-2026-90935 in Froxlor
Summary
by MITRE • 09/14/2026
Froxlor before 2.3.7 fails to validate the mysql_server parameter against a customer's allowed_mysqlserver allowlist in the Mysqls.add API command. Attackers can supply a disallowed server index to create MySQL databases and users on forbidden servers, bypassing per-customer access controls.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in Froxlor versions prior to 2.3.7 represents a critical failure in input validation within the Mysqls.add API command. This specific component is responsible for provisioning new MySQL databases and associated user accounts on behalf of customers managed by the hosting control panel. The core technical flaw lies in the application's logic, which accepts an identifier or index for the target mysql_server but fails to cross-reference this value against a predefined allowlist configured per customer account. In a properly secured environment, any request to provision resources must verify that the requested infrastructure is explicitly permitted for the requesting user based on their subscription tier, administrative restrictions, or multi-tenancy policies. By omitting this validation step, the software allows an attacker who has access to the API endpoint to specify arbitrary server indices, effectively overriding the intended isolation boundaries between different customers or service tiers.
From a technical perspective, this is a classic example of insecure direct object reference combined with insufficient authorization checks. The application trusts client-supplied input regarding resource location without performing adequate backend verification against authoritative configuration data stored on the server side. This lack of validation enables an attacker to bypass per-customer access controls that are designed to prevent lateral movement or unauthorized resource consumption across different hosting environments. If a customer is restricted from using specific database servers due to capacity limits, security policies, or contractual agreements, this flaw allows them to circumvent those restrictions entirely by simply altering the mysql_server parameter in their API requests.
The operational impact of this vulnerability is significant for both service providers and end-users. For hosting providers, it undermines the fundamental premise of multi-tenancy, potentially allowing a customer to consume resources on servers reserved for other clients or high-priority accounts. This can lead to resource exhaustion, performance degradation for legitimate users, and potential data leakage if security zones are not strictly enforced at the network level beyond just application logic. For individual customers, it represents a breach of service integrity where they may inadvertently provision databases in locations that violate compliance requirements or internal governance policies. Furthermore, because this affects user creation alongside database provisioning, an attacker could potentially create administrative-level MySQL users on restricted servers if the API does not also validate role assignments against server-specific permissions.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Site 'Open Redirect', specifically in the context of resource targeting rather than web redirects, often categorized under CWE-798 if it leads to privilege escalation or unauthorized access. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1534 Internal Spearphishing is not applicable here but more accurately maps to T1078 Valid Accounts and potentially T1098 Account Manipulation if new users are created with elevated privileges on forbidden servers. It also reflects aspects of T1136 Create Account as the attacker creates unauthorized database entities within a restricted environment.
To mitigate this vulnerability, administrators must upgrade Froxlor to version 2.3.7 or later where these validation checks have been implemented. Until an update is applied, it is advisable to restrict direct API access through network-level controls such as firewalls or reverse proxies that limit exposure of the Mysqls.add endpoint to trusted IP addresses only. Additionally, implementing strict input sanitization and server-side authorization middleware can provide a defensive layer by verifying every resource request against the customer's allowed_mysqlserver allowlist before processing any database creation commands. Regular auditing of API logs for unusual patterns in mysql_server parameter values can also help detect potential exploitation attempts early.