Frontaccounting
Monthly
Unsalted MD5 password hashing in FrontAccounting through 2.4.20 renders every stored credential recoverable in minutes if the database is compromised. All authentication-related code paths - user creation, password updates, self-service password change, forgotten-password reset, and login verification - use raw md5() with no per-user salt, so identical passwords produce identical digests and the entire user table can be cracked en masse with rainbow tables or GPU-accelerated tools. No active exploitation (CISA KEV) has been identified, but the CVSS 4.0 score of 8.2 with VC:H reflects that a single database breach translates directly to full plaintext credential exposure across all accounts.
FrontAccounting 2.4.20 and earlier selectively enforces CSRF validation - tokens are generated for every rendered form but the validation call is absent from all financial transaction handlers, including journal entries, supplier invoices, customer payments, bank transactions, and company configuration. An attacker who can induce an authenticated FrontAccounting user to visit a malicious page can silently forge any of those POST requests under the victim's live session, recording fraudulent accounting data without the victim's awareness. No public exploit identified at time of analysis, though a detailed researcher disclosure with technical specifics is publicly available on GitHub.
Remote code execution in FrontAccounting before 2.4.20 lets an authenticated user abuse the attachment upload handler to plant a PHP web shell. The handler fails to validate the unique_name parameter, so traversal sequences write attacker-controlled files outside the attachments directory and into the web root, and because file extensions are not validated, an uploaded PHP file executes as the web server user. Publicly available exploit code exists and a vendor patch is available, though the issue is not listed in CISA KEV.
SQL injection in FrontAccounting before 2.4.20 allows authenticated attackers to extract arbitrary database contents by injecting UNION SELECT payloads into the PARAM_0 POST parameter of the Bank Statement report handler (rep601.php). Attackers with valid low-privilege accounts can dump usernames, password hashes, and email addresses from the users table, with results rendered into the generated PDF report. Publicly available exploit code exists and a vendor patch was released in 2.4.20; the flaw is not listed in CISA KEV and no active exploitation is confirmed.
SQL injection in FrontAccounting's Audit Trail report handler (reporting/rep710.php) lets authenticated users holding the SA_GLANALYTIC permission run arbitrary SQL through the PARAM_2 and PARAM_3 POST parameters in all releases prior to 2.4.20. Attackers can extract arbitrary database contents via UNION-based injection or knock the application offline by amplifying SLEEP() across JOINed result sets to exhaust database connections. Publicly available exploit code exists (VulnCheck/Jiva Security writeup), but the issue is not in CISA KEV, so it is no public exploit identified as actively exploited.
SQL injection in FrontAccounting's get_gl_transactions() function lets authenticated users holding the SA_GLANALYTIC permission read arbitrary database contents by injecting into the unparameterized filter_type parameter of a SQL IN() clause. The flaw enables boolean-based blind extraction of sensitive journal-entry and general-ledger data using reliable response-size differentials. Publicly available exploit code exists and a vendor patch shipped in 2.4.20, though there is no public exploit identified as actively exploited.
An issue was discovered in FrontAccounting 2.4.7. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
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. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
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. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
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). Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Multiple SQL injection vulnerabilities in FrontAccounting (FA) before 2.3.21 allow remote attackers to execute arbitrary SQL commands via unspecified vectors. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Unsalted MD5 password hashing in FrontAccounting through 2.4.20 renders every stored credential recoverable in minutes if the database is compromised. All authentication-related code paths - user creation, password updates, self-service password change, forgotten-password reset, and login verification - use raw md5() with no per-user salt, so identical passwords produce identical digests and the entire user table can be cracked en masse with rainbow tables or GPU-accelerated tools. No active exploitation (CISA KEV) has been identified, but the CVSS 4.0 score of 8.2 with VC:H reflects that a single database breach translates directly to full plaintext credential exposure across all accounts.
FrontAccounting 2.4.20 and earlier selectively enforces CSRF validation - tokens are generated for every rendered form but the validation call is absent from all financial transaction handlers, including journal entries, supplier invoices, customer payments, bank transactions, and company configuration. An attacker who can induce an authenticated FrontAccounting user to visit a malicious page can silently forge any of those POST requests under the victim's live session, recording fraudulent accounting data without the victim's awareness. No public exploit identified at time of analysis, though a detailed researcher disclosure with technical specifics is publicly available on GitHub.
Remote code execution in FrontAccounting before 2.4.20 lets an authenticated user abuse the attachment upload handler to plant a PHP web shell. The handler fails to validate the unique_name parameter, so traversal sequences write attacker-controlled files outside the attachments directory and into the web root, and because file extensions are not validated, an uploaded PHP file executes as the web server user. Publicly available exploit code exists and a vendor patch is available, though the issue is not listed in CISA KEV.
SQL injection in FrontAccounting before 2.4.20 allows authenticated attackers to extract arbitrary database contents by injecting UNION SELECT payloads into the PARAM_0 POST parameter of the Bank Statement report handler (rep601.php). Attackers with valid low-privilege accounts can dump usernames, password hashes, and email addresses from the users table, with results rendered into the generated PDF report. Publicly available exploit code exists and a vendor patch was released in 2.4.20; the flaw is not listed in CISA KEV and no active exploitation is confirmed.
SQL injection in FrontAccounting's Audit Trail report handler (reporting/rep710.php) lets authenticated users holding the SA_GLANALYTIC permission run arbitrary SQL through the PARAM_2 and PARAM_3 POST parameters in all releases prior to 2.4.20. Attackers can extract arbitrary database contents via UNION-based injection or knock the application offline by amplifying SLEEP() across JOINed result sets to exhaust database connections. Publicly available exploit code exists (VulnCheck/Jiva Security writeup), but the issue is not in CISA KEV, so it is no public exploit identified as actively exploited.
SQL injection in FrontAccounting's get_gl_transactions() function lets authenticated users holding the SA_GLANALYTIC permission read arbitrary database contents by injecting into the unparameterized filter_type parameter of a SQL IN() clause. The flaw enables boolean-based blind extraction of sensitive journal-entry and general-ledger data using reliable response-size differentials. Publicly available exploit code exists and a vendor patch shipped in 2.4.20, though there is no public exploit identified as actively exploited.
An issue was discovered in FrontAccounting 2.4.7. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.
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. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
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. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
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). Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Multiple SQL injection vulnerabilities in FrontAccounting (FA) before 2.3.21 allow remote attackers to execute arbitrary SQL commands via unspecified vectors. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.