CVE-2026-62988 in Froxlor
Summary
by MITRE • 08/19/2026
Froxlor is open source server administration software. From 2.3.7 until 2.3.8, the Customers.get, Customers.listing, Admins.get, Admins.listing, Ftps.get, and Ftps.listing API commands in lib/Froxlor/Api/Commands/Customers.php, lib/Froxlor/Api/Commands/Admins.php, and lib/Froxlor/Api/Commands/Ftps.php retrieve full database rows and return them without removing password and data_2fa fields. An authenticated API caller with permission to use these endpoints can obtain customer, administrator, and FTP password hashes as well as Base32-encoded TOTP seeds for administrator and customer accounts. Password hashes can be cracked offline, and TOTP seeds can generate valid second-factor codes until two-factor authentication is reset. Exposure of both values for an account can enable takeover of the hosting panel or hosted resources and can defeat both authentication factors. This issue is fixed in version 2.3.8.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Froxlor versions prior to 2.3.8 represents a critical information disclosure flaw within its application programming interface, specifically affecting the retrieval of sensitive user credentials and security tokens. The affected endpoints include Customers.get, Customers.listing, Admins.get, Admins.listing, Ftps.get, and Ftps.listing located in the respective command files for customers, administrators, and FTP users. When an authenticated API caller with appropriate permissions invokes these commands, the system retrieves full database rows from its backend storage and returns them directly to the client without sanitizing sensitive fields. This design oversight results in the exposure of password hashes and data_2fa fields, which contain Base32-encoded Time-based One-Time Password seeds for both administrator and customer accounts.
From a technical perspective, this flaw aligns with CWE-522, Insufficiently Protected Credentials, as well as CWE-209, Generation of Error Message Containing Sensitive Information. The API endpoints fail to implement proper data filtering or field exclusion before serializing the response payload. By returning raw database records, the application inadvertently leaks cryptographic material that is intended for server-side verification only. The password hashes stored in these fields are typically generated using strong hashing algorithms such as bcrypt or Argon2, which are designed to resist rapid cracking but remain vulnerable to offline brute-force attacks if exposed. Similarly, the data_2fa field contains the secret seed required to generate valid TOTP codes for two-factor authentication systems like Google Authenticator or Authy.
The operational impact of this vulnerability is severe due to the potential for complete account takeover and bypassing multi-factor authentication controls. An attacker who gains access to these API endpoints can extract password hashes, which can then be subjected to offline cracking using tools such as Hashcat or John the Ripper. Once a plaintext password is recovered, it provides direct access to the associated user account. More critically, the exposure of TOTP seeds allows an adversary to compute valid second-factor codes for any duration until the seed is reset by the administrator or the user changes their two-factor authentication settings. This effectively neutralizes the security benefit provided by multi-factor authentication, reducing a robust defense-in-depth strategy to a single factor that may be compromised through credential stuffing or phishing attacks.
This vulnerability maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as it facilitates unauthorized access using legitimate credentials obtained through information leakage. It also relates to T1528, Steal Application Access Token, in the context of API abuse where valid session tokens combined with leaked credential data allow persistent and undetected access. The ability to defeat two-factor authentication places this issue at a high severity level within risk assessment frameworks because it undermines one of the most effective controls against unauthorized access in modern web applications.
Mitigation strategies primarily involve upgrading to Froxlor version 2.3.8 or later, where the developers have implemented proper field exclusion logic to prevent sensitive data from being serialized and returned via API responses. For organizations unable to upgrade immediately, network-level restrictions should be applied to limit API endpoint access to trusted IP addresses only. Additionally, implementing strict rate limiting on authentication-related endpoints can mitigate the risk of automated credential cracking attempts using leaked hashes. Administrators should also consider rotating all affected passwords and resetting TOTP seeds for any accounts that may have been exposed during the vulnerable period. Regular security audits of API response payloads are recommended to ensure no other sensitive fields such as private keys or session tokens are inadvertently disclosed in future updates.