CVE-2026-80211 in FrontAccounting
Summary
by MITRE • 08/27/2026
FrontAccounting through 2.4.20 stores and verifies user passwords as unsalted MD5 digests. admin/users.php passes md5($_POST['password']) to add_user() and update_user_password(), admin/change_current_user_password.php does the same when a user changes their own password, the forgotten-password path in includes/current_user.inc hashes the newly generated password the same way, and authentication calls get_user_auth($loginname, md5($password)). The codebase applies no per-password salt and contains no call to password_hash(), password_verify() or any other adaptive hash, so identical passwords yield identical digests and an attacker who obtains the user table can recover plaintext passwords with precomputed lookup tables or high-rate GPU cracking.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in FrontAccounting versions through 2.4.20 represents a critical failure in password storage security, classified under CWE-759 as the use of a one-way hash without salt and CWE-328 regarding weak cryptographic algorithms. The core technical flaw lies in the application of unsalted MD5 hashing for all user credentials across multiple authentication pathways within the software architecture. Specifically, the administrative interface at admin/users.php invokes md5 functions when adding new users or updating existing passwords via add_user() and update_user_password(). Similarly, self-service password changes through admin/change_current_user_password.php follow this same insecure pattern. The system also fails to apply salt during the forgotten-password recovery process in includes/current_user.inc, where newly generated passwords are hashed identically to user-initiated changes. Authentication mechanisms rely on get_user_auth() which compares provided credentials against these static MD5 digests rather than utilizing modern adaptive hashing functions like password_hash or password_verify that incorporate computational cost factors and unique salts per entry.
This architectural deficiency results in identical plaintext passwords producing identical hexadecimal digest values across the entire user database, creating a significant risk for bulk credential compromise. Because no random salt is appended to each password before hashing, attackers who gain access to the underlying SQL database can immediately identify users with common or duplicate passwords by observing matching hash strings. This characteristic drastically reduces the complexity of offline attacks against the stored credentials. The use of MD5 further exacerbates this risk due its known cryptographic weaknesses, including susceptibility to collision attacks and extremely fast computation speeds on modern hardware. Consequently, an adversary possessing database access can employ high-rate GPU cracking techniques or utilize precomputed lookup tables such as rainbow tables to reverse these hashes into plaintext passwords with minimal time investment compared to secure hashing standards like bcrypt, scrypt, or Argon2.
The operational impact of this vulnerability extends beyond simple credential theft to include potential account takeover and lateral movement within the targeted network environment. Since FrontAccounting is often deployed in business contexts handling financial data, compromised administrative accounts could lead to unauthorized manipulation of invoices, payment records, and customer information. The lack of per-user salting means that a single cracked password may reveal multiple user identities if they share common default or weak passwords, amplifying the scope of the breach. Furthermore, because the system does not implement rate limiting or account lockout mechanisms alongside this flawed storage method, automated brute-force attacks against login endpoints remain highly effective even without database access, although offline cracking remains the primary threat vector given the weakness of MD5.
Mitigation strategies must prioritize immediate remediation through software updates if a patched version is available from the vendor. In cases where upgrading is not immediately feasible, administrators should enforce strong password complexity policies to reduce the effectiveness of dictionary-based attacks and rainbow tables. It is also recommended to implement additional layers of defense such as multi-factor authentication for administrative accounts to mitigate the risk posed by compromised credentials. From a development perspective, future iterations must replace MD5 with industry-standard adaptive hashing algorithms that automatically generate unique salts per password entry. This ensures that even if two users select identical passwords, their stored hashes will differ significantly, thereby neutralizing precomputed table attacks and increasing the computational cost required for brute-force attempts to prohibitive levels. Regular security audits focusing on authentication modules are essential to prevent recurrence of such fundamental cryptographic misconfigurations in legacy systems.