FrontAccounting through 2.4.20 Use of Unsalted MD5 for Password Storage

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 Cross-Site Request Forgery on Financial Transaction Forms

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 < 2.4.20 SQL Injection via get_gl_transactions()

FrontAccounting before 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.

FrontAccounting < 2.4.20 SQL Injection via reporting/rep710.php

FrontAccounting before 2.4.20 contains a SQL injection vulnerability in the Audit Trail report handler that allows authenticated attackers with SA_GLANALYTIC permission to execute arbitrary SQL queries by injecting malicious code into the PARAM_2 and PARAM_3 POST parameters. Attackers can exploit time-based blind SQL injection through SLEEP() functions that are amplified across JOIN result sets to cause denial of service by exhausting database connections, or extract arbitrary database content through UNION-based injection techniques.

FrontAccounting < 2.4.20 SQL Injection via rep601.php

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.

FrontAccounting < 2.4.20 Path Traversal RCE via attachment upload

FrontAccounting before 2.4.20 contains a path traversal vulnerability in the attachment upload handler that allows authenticated attackers to execute arbitrary code by uploading files with traversal sequences in the unique_name parameter. Attackers can supply path traversal sequences ../../../shell.php to write files outside the intended attachments directory into the web root, and by uploading PHP files without extension validation, achieve remote code execution as the web server user.

PHP remote file inclusion vulnerability in config.php in FrontAccounting 1.12 Build 31 allows remote attackers to execute arbitrary PHP code via a URL in the path_to_root parameter.

Multiple PHP remote file inclusion vulnerabilities in FrontAccounting (FA) 1.13, when register_globals is enabled, allow remote attackers to execute arbitrary PHP code via a URL in the path_to_root parameter to (1) access/login.php and (2) includes/lang/language.php, different vectors than CVE-2007-4279.

Multiple PHP remote file inclusion vulnerabilities in FrontAccounting (FA) 1.12 allow remote attackers to execute arbitrary PHP code via a URL in the path_to_root parameter to (1) access/logout.php or certain PHP scripts under (2) admin/, (3) dimensions/, (4) gl/, (5) inventory/, (6) manufacturing/, (7) purchasing/, (8) reporting/, (9) sales/, or (10) taxes/. NOTE: the config.php vector is already covered by CVE-2007-4279, and the login.php and language.php vectors are already covered by CVE-2007-5117. NOTE: this issue is disputed by CVE because path_to_root is defined before use in all of the other files reported in the original disclosure

Multiple SQL injection vulnerabilities in FrontAccounting (FA) before 2.1.7, and 2.2.x before 2.2 RC, allow remote attackers to execute arbitrary SQL commands via unspecified parameters to (1) admin/db/users_db.inc, and various other .inc and .php files under (2) admin/, (3) dimensions/, (4) gl/, (5) inventory/, (6) manufacturing/, and (7) purchasing/.

Multiple SQL injection vulnerabilities in FrontAccounting (FA) before 2.1.7 allow remote attackers to execute arbitrary SQL commands via unspecified parameters to various .inc and .php files in (1) reporting/, (2) sales/, (3) sales/includes/, (4) sales/includes/db/, (5) sales/inquiry/, (6) sales/manage/, (7) sales/view/, (8) taxes/, and (9) taxes/db/.

Multiple SQL injection vulnerabilities in FrontAccounting (FA) 2.2.x before 2.2 RC allow remote attackers to execute arbitrary SQL commands via unspecified parameters to (1) bank_accounts.php, (2) currencies.php, (3) exchange_rates.php, (4) gl_account_types.php, and (5) gl_accounts.php in gl/manage/; and (6) audit_trail_db.inc, (7) comments_db.inc, (8) inventory_db.inc, (9) manufacturing_db.inc, and (10) references_db.inc in includes/db/.

Multiple SQL injection vulnerabilities in FrontAccounting (FA) before 2.3.21 allow remote attackers to execute arbitrary SQL commands via unspecified vectors.

FrontAccounting 2.3.1 allows remote attackers to obtain sensitive information via a direct request to a .php file, which reveals the installation path in an error message, as demonstrated by reporting/includes/fpdi/fpdi2tcpdf_bridge.php and certain other files.

An issue was discovered in FrontAccounting 2.4.7. There is a Directory Traversal vulnerability that can empty folder via admin/inst_lang.php.

includes/db/class.reflines_db.inc in FrontAccounting 2.4.6 contains a SQL Injection vulnerability in the reference field that can allow the attacker to grab the entire database of the application via the void_transaction.php filterType parameter.

FrontAccounting 2.4.3 suffers from a CSRF flaw, which leads to adding a user account via admin/users.php (aka the "add user" feature of the User Permissions page).

FrontAccounting 2.4.5 contains a Time Based Blind SQL Injection vulnerability in the parameter "filterType" in /attachments.php that can allow the attacker to grab the entire database of the application.