CVE-2026-40522
HighCVSS 7.1Summary
FrontAccounting before version 2.4.20 contains a SQL injection vulnerability in the Bank Statement report handler. An authenticated attacker can inject UNION SELECT payloads into the PARAM_0 POST parameter, extracting arbitrary database data including usernames, password hashes, and email addresses, which are then rendered into PDF report output.
Risk Assessment
The risk involves theft of sensitive authentication data (usernames, password hashes) and email addresses, potentially leading to privilege escalation, account takeover, and breach of system confidentiality.
Recommendation
Immediately upgrade FrontAccounting to version 2.4.20 or later. If upgrading is not possible, temporarily restrict access to the bank statement report module to trusted administrators only.
Other vulnerabilities in FrontAccounting
See all- CVE-2026-40523High
FrontAccounting before 2.4.20 contains a SQL injection vulnerability in the Audit Trail report handler. Authenticated attackers with SA_GLANALYTIC permission can inject malicious code into PARAM_2 and PARAM_3 POST parameters to execute arbitrary SQL queries.
- CVE-2014-3973High
Multiple SQL injection vulnerabilities in FrontAccounting (FA) before version 2.3.21 allow remote attackers to execute arbitrary SQL commands via unspecified vectors.
- CVE-2026-80211Medium
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.
- CVE-2026-80210Medium
FrontAccounting through 2.4.20 generates a CSRF token in end_form() in includes/ui/ui_controls.inc and embeds it as the _token hidden field in every form it renders, but only admin/users.php and admin/change_current_user_password.php call check_csrf_token() to validate it. No financial transaction handler validates the token, including gl/gl_journal.php, gl/gl_bank.php, purchasing/supplier_invoice.php, sales/customer_invoice.php, sales/customer_payments.php and admin/company_preferences.php, so those endpoints act on POST data with no origin check. An attacker who gets an authenticated user to load a page under attacker control can auto-submit a cross-origin form to any of them and have the forged journal entry, invoice, customer payment, bank transaction or company configuration change recorded under the victim's session.
- CVE-2026-40524High
FrontAccounting before version 2.4.20 contains a SQL injection vulnerability in the get_gl_transactions() function where the filter_type parameter is concatenated directly into a SQL IN() clause without parameterization. Attackers with SA_GLANALYTIC permission can inject arbitrary SQL by supplying a closing parenthesis followed by malicious conditions to extract sensitive journal entry data through boolean-based blind SQL injection with reliable response size differentials.
- CVE-2026-40521High
A path traversal vulnerability in FrontAccounting before version 2.4.20 allows authenticated attackers to achieve remote code execution by uploading files with traversal sequences in the unique_name parameter. Attackers can write a PHP file outside the attachments directory into the web root, leading to arbitrary code execution.
Original NVD description (English source)
FrontAccounting before 2.4.20 contains a SQL injection vulnerability in the Bank Statement report handler that allows authenticated attackers to extract arbitrary database data by injecting UNION SELECT payloads into the PARAM_0 POST parameter. Attackers can supply malicious SQL syntax through the unparameterized WHERE clause to retrieve sensitive information including usernames, password hashes, and email addresses from the users table, rendered into PDF report output.