Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-27T17:20:50.733Z",
  "pubdate": "2026-08-27T17:20:50.733Z",
  "executiveSummary": "FrontAccounting versions through 2.4.20 utilize an insecure cryptographic implementation for user password storage, relying exclusively on unsalted MD5 hashing. This vulnerability allows for the trivial recovery of plaintext credentials from the database.\nBy bypassing modern adaptive hashing standards, the system is highly susceptible to credential recovery via precomputed lookup tables (Rainbow Tables) or high-speed GPU-accelerated brute-force attacks.\nThe scope of this issue spans the entire authentication and account management architecture, including user creation, profile updates, and password recovery mechanisms. The lack of per-user salts ensures that identical passwords result in identical hash values, facilitating mass password cracking across the user base once the database is compromised.\nSuccessful exploitation poses a critical risk to data confidentiality and integrity, potentially leading to unauthorized administrative access. Attackers do not require specialized network access during the exploitation phase; rather, they require read access to the backend database to extract the password digests.",
  "technicalDetails": "The root cause of this vulnerability is the implementation of a legacy, computationally inexpensive, and non-adaptive hashing algorithm (MD5) without the integration of unique per-user salts. The application fails to utilize modern cryptographic primitives such as Argon2, bcrypt, or scrypt, which are specifically designed to mitigate high-speed cracking attempts.\nVulnerable components include admin/users.php, admin/change_current_user_password.php, and includes/current_user.inc. In each of these files, the application directly processes the user-provided password using the md5() function before storage or comparison.\nThe authentication flow involves the get_user_auth($loginname, md5($password)) function, which performs a direct comparison between the database-stored hash and the incoming MD5 digest. Because this process lacks salt, the search space for an attacker is significantly reduced. An attacker who gains unauthorized read access to the database can exfiltrate the password table and execute local offline cracking operations.\nAttack flow: 1) Attacker obtains the 'users' table from the database via SQL injection, file inclusion, or secondary compromise. 2) Attacker observes that the stored strings correspond to 32-character hexadecimal MD5 digests. 3) Attacker deploys specialized hardware (GPUs) or utilizes existing precomputed rainbow tables to map these digests back to their corresponding plaintext passwords. 4) Since there is no salt to differentiate hashes for identical passwords, an attacker can determine all users who share the same password simultaneously. 5) Once the plaintext passwords are recovered, the attacker uses these credentials to authenticate as legitimate users, including administrators, to conduct unauthorized transactions, data exfiltration, or configuration changes.\nThe lack of adaptive hashing means the cost for an attacker to compute millions of guesses per second is negligible. This design failure fundamentally negates the security intended by hashing, providing a false sense of protection while exposing credentials to trivial recovery."
}