EUVD-2026-40080
GHSA-8ccm-j5hq-9jhr
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:H/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 SA_GLANALYTIC account (PR:L); UNION data theft gives C:H and JOIN-amplified SLEEP() DoS gives A:H, with no integrity change (I:N).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
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.
AnalysisAI
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.
Technical ContextAI
FrontAccounting is an open-source, web-based double-entry accounting/ERP system written in PHP with a MySQL/MariaDB backend. The flaw is a classic CWE-89 SQL Injection: user-controlled POST parameters (PARAM_2, PARAM_3) feeding the Audit Trail report (rep710.php) are concatenated into SQL without proper parameterization or escaping, so the query parser treats attacker input as executable code. Because the audit report joins multiple tables, a single injected time-delay function (SLEEP()) is evaluated once per row of the JOIN result set, multiplying its cost and turning a normally low-impact blind technique into a resource-exhaustion primitive. The affected CPE is cpe:2.3:a:frontaccounting:frontaccounting:*:*:*:*:*:*:*:* across all versions before 2.4.20.
RemediationAI
Vendor-released patch: upgrade to FrontAccounting 2.4.20, which contains the fix (commit 647a18196caad27f96ea852e993c9e30f815357f; release notes at https://sourceforge.net/p/frontaccounting/news/2026/04/release-2420/). If immediate upgrade is not possible, revoke the SA_GLANALYTIC permission from any account that does not strictly require Audit Trail reporting (trade-off: those users lose access to GL analytics and audit reports), and restrict network access to the application - particularly the reporting/rep710.php endpoint - to trusted internal users via firewall or reverse-proxy ACLs (trade-off: may break legitimate remote reporting workflows). A WAF rule blocking SQL metacharacters in the PARAM_2/PARAM_3 POST fields can serve as a stopgap but is bypassable and must not replace the patch. Review the VulnCheck advisory (https://www.vulncheck.com/advisories/frontaccounting-sql-injection-via-reporting-rep710-php) for confirmation details.
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 before 2.4.20 allows authenticated attackers to extract arbitrary database contents by
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 allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today