CVE-2014-3973

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.

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.

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.

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.

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.

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.