Executive brief
FrontAccounting, an open-source enterprise resource planning (ERP) system, contains a security flaw in its reporting module. An attacker with basic reporting permissions can manipulate database queries to bypass security filters and extract sensitive financial data, such as journal entries and password hashes. This could lead to a significant breach of corporate financial records and unauthorized access to administrative accounts.
Technical details
A SQL injection vulnerability exists in FrontAccounting versions prior to 2.4.20 within the get_gl_transactions() function located in gl/includes/db/gl_db_trans.inc. The root cause is the direct concatenation of the $filter_type parameter (sourced from $_POST['PARAM_2'] in rep702.php) into a SQL IN() clause without parameterization or escaping. An authenticated attacker with SA_GLANALYTIC permissions can break out of the IN() clause using a closing parenthesis and inject arbitrary SQL conditions. Because the application returns a PDF report, attackers can use a boolean-based blind technique by observing the significant response size differential between 'true' (full report) and 'false' (empty report) conditions to exfiltrate data. The vulnerability is patched in version 2.4.20 by implementing db_escape() on the affected parameter.
Affected products
- FrontAccounting FrontAccounting < 2.4.20
Timeline
- 2026-04-28: patched: Release 2.4.20 published with security fixes
- 2026-06-29: disclosed: Public disclosure and CVE assignment
References
- https://github.com/FrontAccountingERP/FA/commit/647a18196caad27f96ea852e993c9e30f815357f
- https://jivasecurity.com/writeups/frontaccounting-sqli-journal-entries-report-cve-2026-40524
- https://sourceforge.net/p/frontaccounting/news/2026/04/release-2420/
- https://www.vulncheck.com/advisories/frontaccounting-sql-injection-via-get-gl-transactions