EUVD-2026-40081
GHSA-53v3-ffpm-f9hw
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable report endpoint with low complexity but requires an authenticated low-privilege account (PR:L); high confidentiality from full DB read, limited integrity, no availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
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.
AnalysisAI
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.
Technical ContextAI
FrontAccounting is an open-source, web-based ERP/accounting application written in PHP that uses a MySQL/MariaDB backend. The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command): the Bank Statement report handler (rep601.php) builds a SQL WHERE clause by concatenating the user-supplied PARAM_0 value without parameterization or escaping, so attacker-controlled syntax is executed directly by the database. Because the report renders query output into a PDF, the unparameterized clause becomes an in-band/UNION-based exfiltration channel - UNION SELECT payloads append attacker-chosen columns (e.g., from the users table) to the legitimate result set, which are then printed in the report output. The affected component is identified in the CPE cpe:2.3:a:frontaccounting:frontaccounting:*:*:*:*:*:*:*:* covering all versions prior to the 2.4.20 fix.
RemediationAI
Upgrade to FrontAccounting 2.4.20 or later, which contains the fix (Vendor-released patch: 2.4.20; release notes at https://sourceforge.net/p/frontaccounting/news/2026/04/release-2420/ and source commit https://github.com/FrontAccountingERP/FA/commit/894adaf71393e0ef6a04fe6036fcd2464050f590). If immediate upgrading is not possible, apply the upstream commit to rep601.php to parameterize the PARAM_0 input as the most targeted control. As compensating measures until patched, restrict access to the Bank Statement report function by removing the relevant report/security role from all but trusted accounting users (trade-off: legitimate users lose that report), and place the FrontAccounting instance behind network restrictions or a WAF rule that blocks UNION/SQL metacharacters in the PARAM_0 POST parameter (trade-off: WAF rules can be bypassed and may false-positive on legitimate report parameters). Additionally, rotate any potentially exposed credentials and ensure stored password hashes use a strong algorithm, since the users table is a confirmed exfiltration target. Vendor/third-party references: VulnCheck advisory https://www.vulncheck.com/advisories/frontaccounting-sql-injection-via-rep601-php.
More in Frontaccounting
View allincludes/db/class.reflines_db.inc in FrontAccounting 2.4.6 contains a SQL Injection vulnerability in the reference field
Remote code execution in FrontAccounting before 2.4.20 lets an authenticated user abuse the attachment upload handler to
FrontAccounting 2.4.3 suffers from a CSRF flaw, which leads to adding a user account via admin/users.php (aka the "add u
Multiple SQL injection vulnerabilities in FrontAccounting (FA) before 2.3.21 allow remote attackers to execute arbitrary
FrontAccounting 2.4.5 contains a Time Based Blind SQL Injection vulnerability in the parameter "filterType" in /attachme
SQL injection in FrontAccounting's get_gl_transactions() function lets authenticated users holding the SA_GLANALYTIC per
SQL injection in FrontAccounting's Audit Trail report handler (reporting/rep710.php) lets authenticated users holding th
An issue was discovered in FrontAccounting 2.4.7. Rated medium severity (CVSS 4.9), this vulnerability is remotely explo
Unsalted MD5 password hashing in FrontAccounting through 2.4.20 renders every stored credential recoverable in minutes i
FrontAccounting 2.4.20 and earlier selectively enforces CSRF validation - tokens are generated for every rendered form b
Same weakness CWE-89 – SQL Injection
View allShare
External POC / Exploit Code
Leaving vuln.today