CVE-2026-52793 in Froxlor
Summary
by MITRE • 08/19/2026
Froxlor is open source server administration software. Prior to 2.3.7, the API authentication path in lib/Froxlor/Api/FroxlorRPC.php and FroxlorRPC::validateAuth accepts an API key and secret for an administrator or customer account without checking type_2fa, validating a TOTP code, or invoking FroxlorTwoFactorAuth. The web interface requires a second factor for accounts with two-factor authentication enabled, but the API grants access after validating only the API credentials, expiration, API permission, and account status. An attacker who obtains an API key and secret for a protected account can call the available API functions without supplying the configured second factor, which can expose or modify customer data, domains, email and FTP accounts, databases, DNS records, and certificate material. This issue is fixed in version 2.3.7.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Froxlor versions prior to 2.3.7 represents a critical authentication bypass within the application's remote API interface. Froxlor serves as open-source server administration software, managing various aspects of web hosting infrastructure including customer accounts, domains, email services, and DNS records. The core flaw resides specifically in the lib/Froxlor/Api/FroxlorRPC.php module, where the FroxlorRPC::validateAuth function is responsible for authenticating API requests. While the graphical user interface correctly enforces multi-factor authentication by checking type_2fa settings and validating Time-based One-Time Password codes through the FroxlorTwoFactorAuth class, this security control was entirely absent in the programmatic access path. The API endpoint accepts an API key and secret pair for both administrator and customer accounts but fails to verify whether two-factor authentication is enabled for that specific account or require a valid TOTP code during the validation process.
This architectural inconsistency creates a significant disparity between user-facing security controls and backend service enforcement mechanisms. An attacker who successfully obtains valid API credentials, such as through phishing, credential stuffing, or data breaches from other sources, can bypass the intended second factor of authentication entirely. The system grants access based solely on the validity of the API key and secret, expiration status, assigned permissions, and general account status, ignoring the critical requirement for a secondary verification token. This oversight effectively nullifies the security benefit provided by two-factor authentication for any account that has it enabled but is accessed via the API rather than the web interface. The vulnerability allows unauthorized actors to authenticate as privileged users without possessing the physical device or authenticator app required to generate valid TOTP codes, thereby undermining a primary defense against credential compromise.
The operational impact of this vulnerability is severe due to the high level of access typically associated with administrative and customer API keys in server administration software. Once authenticated via this bypassed mechanism, an attacker can invoke available API functions that expose or modify sensitive infrastructure data. This includes reading or altering customer personal information, managing domain names, modifying email accounts and configurations, controlling FTP account permissions, creating or deleting databases, updating DNS records which could redirect traffic to malicious servers, and accessing certificate material used for secure communications. The ability to manipulate these components can lead to complete compromise of hosted services, data exfiltration, service disruption through denial-of-service actions via configuration changes, or the establishment of persistent backdoors within the server environment.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-306 Missing Authentication for Critical Function. The failure to enforce multi-factor authentication in an API context is also consistent with ATT&CK technique T1078 Valid Accounts, as it allows attackers to leverage stolen credentials while bypassing additional security layers designed to mitigate the risk of credential theft. To remediate this issue, administrators must upgrade Froxlor to version 2.3.7 or later where the API authentication logic has been corrected to check for two-factor authentication status and require a valid TOTP code when applicable. In environments where immediate patching is not feasible, implementing network-level access controls such as IP whitelisting for API endpoints can provide an additional layer of defense by restricting which source addresses are permitted to interact with the vulnerable RPC interface. Additionally, enforcing strict monitoring and alerting on API authentication failures may help detect attempts to exploit this bypass before successful unauthorized access occurs.