FrontAccounting CSRF & unsalted MD5 hash vulnerability analysis

FrontAccounting Security Vulnerability Report Summary Vulnerability 1: Cross-Site Request Forgery (CSRF) in Financial Transaction Forms Vulnerability Overview FrontAccounting implements a CSRF token mechanism (hidden field + validation), but this mechanism is only applied to the and pages; all financial transaction forms lack this protection. Scope of Impact (confirmed, non-exhaustive) (GL journal entries) (supplier invoices) (customer invoices) (customer payments) (bank transactions) (company settings) Technical Details The function in embeds a hidden field, but financial transaction forms do not invoke this function, and is not validated upon submission. Verification: Reloading confirms the presence of the field in the form after authentication; a POST request to this endpoint without is processed normally and is not rejected. Exploitation Scenario An attacker hosts a webpage containing an auto-submitting form targeted at the victim's FrontAccounting instance. When an authenticated user visits the attacker's page (e.g., via a phishing link), the browser automatically sends a POST request carrying the session Cookie, resulting in the forged transaction being recorded without any further interaction. Remediation Invoke at the beginning of all transaction handling code blocks, or implement a global CSRF check (executed within includes/session before processing any POST data). Consider setting the attribute (Strict or Lax) for the session Cookie to provide defense in depth. Verification Environment FrontAccounting 2.4.20, PHP 8.1.34, Apache 2.4.65, MySQL 8.0. Disclosure Timeline May 24, 2026: Reported via email May 28, 2026: Report accepted and acknowledged, with the fix planned for the next minor release --- Vulnerability 2: Unsalted MD5 Password Hashing Vulnerability Overview FrontAccounting uses unsalted MD5 to hash all user passwords. If an attacker gains access to the database, the stored credentials can be easily cracked. Technical Details Password hashing in (lines 70, 76) and (line 72) uses PHP's function without a salt value: The authentication logic in line 79 also uses: Three Major Weaknesses of Unsalted MD5 1. No per-user salt → identical passwords produce identical hashes, facilitating batch cracking and rainbow table lookups. 2. MD5 is extremely susceptible to brute-force attacks — modern GPUs can compute billions of hashes per second. 3. Pre-computed lookup tables (CrackStation, hashes.net) can cover the most common passwords, enabling recovery in milliseconds without requiring GPUs. Verification Example: The password is stored as , which can be immediately recovered using online lookup tools. Remediation Replace with PHP's for password storage, and use for authentication. This change requires a migration path: upon successful login, re-hash the currently MD5-stored password using , enabling a rolling migration without forcing all users to immediately reset their passwords. Also consider increasing the minimum password length from 4 characters to at least 8 characters, and enforcing complexity requirements. Verification Environment FrontAccounting 2.4.20, PHP 8.1.34, MySQL 8.0. Disclosure Timeline May 24, 2026: Reported via email May 28, 2026: Report accepted and acknowledged, with the fix planned for the next minor release

Goal Reached Thanks to every supporter — we hit 100%!

FrontAccounting CSRF & unsalted MD5 hash vulnerability analysis

More from this source