CVE-2026-52793: Froxlor Auth Bypass Vulnerability

CVE-2026-52793 Overview

CVE-2026-52793 is an authentication bypass vulnerability in Froxlor, an open source server administration platform. Versions prior to 2.3.7 fail to enforce two-factor authentication (2FA) on the API path. The FroxlorRPC::validateAuth function in lib/Froxlor/Api/FroxlorRPC.php accepts an API key and secret without checking type_2fa, validating a Time-based One-Time Password (TOTP) code, or invoking FroxlorTwoFactorAuth. Attackers holding valid API credentials for a 2FA-protected account can invoke API functions and access or modify customer data, domains, email accounts, File Transfer Protocol (FTP) accounts, databases, Domain Name System (DNS) records, and certificate material. The issue is fixed in version 2.3.7.

Critical Impact
An attacker with a stolen API key and secret bypasses the second authentication factor and gains full API access to a Froxlor administrator or customer account.

Affected Products

Froxlor server administration software versions prior to 2.3.7
Froxlor administrator accounts with 2FA enabled
Froxlor customer accounts with 2FA enabled

Discovery Timeline

2026-08-18 - CVE-2026-52793 published to the National Vulnerability Database (NVD)
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-52793

Vulnerability Analysis

The vulnerability is an authentication bypass classified as [CWE-287] Improper Authentication. The Froxlor web interface enforces 2FA when accounts have it configured, requiring a valid TOTP code alongside the primary credentials. The API path enforces a different, weaker authentication flow. FroxlorRPC::validateAuth in lib/Froxlor/Api/FroxlorRPC.php validates only the API key, the API secret, key expiration, API permission, and account status. The function does not read the type_2fa field, does not require a TOTP code, and does not invoke FroxlorTwoFactorAuth. An attacker who obtains a valid API key and secret authenticates directly against the API and bypasses the account's configured second factor.

Root Cause

The root cause is a missing authentication step in the API validation path. The API and web interface authentication flows diverged: the web login enforces 2FA when configured on the account, but the API path treats API key possession as sufficient. There is no cross-check against type_2fa on the account record. API key issuance historically did not require re-authentication with the current account password, which increases the risk of unauthorized key generation by an attacker with a stolen session.

Attack Vector

Exploitation requires network access to the Froxlor API endpoint and possession of a valid API key and secret for a targeted administrator or customer account. Once authenticated, the attacker can call any API function permitted by the key, including operations against customer data, domains, email accounts, FTP accounts, databases, DNS records, and Transport Layer Security (TLS) certificates. Because the second factor is skipped, credential theft alone is sufficient to compromise 2FA-protected accounts.

php

// Patch excerpt from api_keys.php - require current password before API key generation
} elseif ($action == 'add') {
    if (Request::post('send') == 'send') {
        $user_passwd = Request::post('user_password');
        if (empty($user_passwd)) {
            Response::dynamicError(lng('panel.noauthentication'));
        }
        if ($userinfo['adminsession']) {
            $table = "`" . TABLE_PANEL_ADMINS . "`";
            $uid = 'adminid';
        } else {
            $table = "`" . TABLE_PANEL_CUSTOMERS . "`";
            $uid = 'customerid';
        }
        if (\Froxlor\System\Crypt::validatePasswordLogin($userinfo, $user_passwd, $table, $uid)) {
            $ins_stmt = Database::prepare("
                INSERT INTO `" . TABLE_API_KEYS . "` SET
                `apikey` = :key, `secret` = :secret, `adminid` = :aid, `customerid` = :cid, `valid_until` = '-1', `allowed_from` = ''
            ");

Source: Froxlor commit 7fc21dc

Detection Methods for CVE-2026-52793

Indicators of Compromise

API calls to Froxlor endpoints from source IPs not listed in the allowed_from field of the associated API key
API activity on accounts where type_2fa is set but no interactive web login with a TOTP challenge occurred in the same window
Unexpected creation or modification of domains, DNS records, email accounts, FTP accounts, databases, or TLS certificates via the API
New API key records inserted into the api_keys table without a corresponding password re-authentication event

Detection Strategies

Compare API authentication events against interactive web logins for the same account and flag API-only access on 2FA-enabled accounts
Enable and centralize Froxlor web server access logs and parse for FroxlorRPC endpoint activity
Correlate API key creation timestamps with administrator or customer login sessions to identify keys minted without user interaction

Monitoring Recommendations

Forward Froxlor and reverse proxy logs to a Security Information and Event Management (SIEM) platform for centralized review
Alert on API calls that modify DNS records, TLS certificates, or account credentials outside of maintenance windows
Track the volume of API requests per key and alert on sudden spikes or access from new geolocations

How to Mitigate CVE-2026-52793

Immediate Actions Required

Upgrade all Froxlor installations to version 2.3.7 or later
Rotate every existing API key and secret after upgrading, especially for accounts with 2FA enabled
Restrict API key usage with the allowed_from field to trusted source IP ranges
Audit the api_keys table for keys created without corresponding administrator or customer interaction

Patch Information

The fix is available in Froxlor release 2.3.7. The upstream commit 7fc21dc6f8d22673e4ddc765b710c9d3f85cb001 hardens API key generation by requiring the current account password before issuing a new key. Additional details are published in the GitHub Security Advisory GHSA-f9rx-7wf7-jr36.

Workarounds

Disable the Froxlor API entirely until the upgrade to 2.3.7 is complete if API access is not required
Delete API keys associated with accounts that have 2FA enabled and rely on the web interface for administrative tasks
Restrict access to the Froxlor API using upstream firewall rules or a reverse proxy allowlist

bash

# Example nginx allowlist for the Froxlor API endpoint
location /api.php {
    allow 10.0.0.0/8;
    allow 192.168.1.0/24;
    deny all;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}