CVE-2026-40524: FrontAccounting SQL Injection Vulnerability

CVE-2026-40524 Overview

CVE-2026-40524 is a SQL injection vulnerability in FrontAccounting versions before 2.4.20. The flaw resides in the get_gl_transactions() function within gl/includes/db/gl_db_trans.inc. The filter_type parameter is concatenated directly into a SQL IN() clause without parameterization or escaping. Authenticated attackers holding the SA_GLANALYTIC permission can inject arbitrary SQL by supplying a closing parenthesis followed by malicious conditions. Exploitation yields boolean-based blind SQL injection with reliable response size differentials, enabling extraction of sensitive journal entry data from the accounting database. The weakness is classified under CWE-89: Improper Neutralization of Special Elements used in an SQL Command.

Critical Impact
Authenticated attackers with reporting privileges can exfiltrate confidential general ledger data, journal entries, and other database contents via blind SQL injection.

Affected Products

FrontAccounting ERP versions prior to 2.4.20
The vulnerable get_gl_transactions() function in gl/includes/db/gl_db_trans.inc
Reporting components including reporting/rep601.php (bank and audit reports)

Discovery Timeline

2026-06-29 - CVE-2026-40524 published to the National Vulnerability Database
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-40524

Vulnerability Analysis

The vulnerability exists in FrontAccounting's general ledger reporting pipeline. The get_gl_transactions() function builds a SQL query dynamically by concatenating user-controlled input into a gl.type IN (...) clause. Because filter_type is inserted without db_escape() or a prepared statement, attacker-supplied SQL fragments break out of the parenthesized list and modify the underlying query.

Exploitation requires an authenticated session with the SA_GLANALYTIC role, which is commonly granted to accounting and audit personnel. The injection point supports boolean-based blind extraction because the report renders different response sizes depending on whether the injected predicate returns true or false. An attacker can iterate character-by-character across sensitive tables including journal entries, chart of accounts, and user credentials.

The related patch also hardens reporting/rep601.php, where the $acc bank account identifier was similarly concatenated into a WHERE id = $acc clause without escaping.

Root Cause

The root cause is direct string concatenation of untrusted input into SQL statements. FrontAccounting provides a db_escape() helper, but the vulnerable code paths omitted it for the filter_type and $acc parameters. This is a textbook [CWE-89] failure to neutralize special SQL characters.

Attack Vector

Exploitation is network-based and requires a low-privileged authenticated account holding SA_GLANALYTIC. The attacker submits a crafted filter_type value to the general ledger transaction report endpoint. A closing parenthesis terminates the intended IN() list, allowing arbitrary boolean expressions to be appended before the remainder of the query is neutralized with a comment or a matching balancing parenthesis.

text

         $sql .= " AND gl.dimension2_id = ".($dimension2<0 ? 0 : db_escape($dimension2));
 
     if ($filter_type != null)
-        $sql .= " AND gl.type IN (" . $filter_type .")";
+        $sql .= " AND gl.type IN (" . db_escape($filter_type) .")";
 
     if ($amount_min != null)
         $sql .= " AND ABS(gl.amount) >= ABS(".db_escape($amount_min).")";

Source: FrontAccounting security commit 647a181. The patch wraps $filter_type in db_escape() so injected metacharacters are neutralized before query execution.

Detection Methods for CVE-2026-40524

Indicators of Compromise

HTTP requests to FrontAccounting reporting endpoints containing SQL metacharacters such as ), --, UNION, SLEEP(, or SUBSTRING( in the filter_type parameter.
Repeated report requests from a single SA_GLANALYTIC account with incrementally changing payloads, indicative of automated blind extraction.
MySQL general query log entries showing malformed gl.type IN (...) clauses containing appended conditions.

Detection Strategies

Enable database query logging on the FrontAccounting backend and alert on IN ( clauses containing unexpected operators, quotes, or comment sequences.
Deploy a web application firewall (WAF) rule set that inspects filter_type and related report parameters for SQL injection signatures.
Correlate authenticated session activity with abnormal report volume or error rates to surface blind extraction attempts.

Monitoring Recommendations

Baseline normal usage of the general ledger report endpoints and alert on statistical anomalies in request frequency and payload length.
Monitor FrontAccounting audit logs for accounts using the SA_GLANALYTIC permission outside of business hours or from atypical source addresses.
Track database error rates on the accounting schema, since blind SQL injection frequently generates parser errors during payload tuning.

How to Mitigate CVE-2026-40524

Immediate Actions Required

Upgrade FrontAccounting to version 2.4.20 or later, which includes the fix in commit 647a181.
Audit and reduce the assignment of the SA_GLANALYTIC permission to only staff who require ledger analytics.
Rotate database credentials and review recent journal entry access logs for signs of data exfiltration.

Patch Information

The upstream fix is in FrontAccounting commit 647a181, included in the FrontAccounting 2.4.20 release announcement. The commit applies db_escape() to filter_type in get_gl_transactions() and to $acc in reporting/rep601.php. Additional context is available in the VulnCheck advisory and the Jiva Security write-up.

Workarounds

If patching is not immediately possible, restrict network access to the FrontAccounting reporting endpoints using a reverse proxy or WAF.
Deploy a WAF rule that rejects filter_type values containing characters outside the expected numeric or comma-separated integer list.
Temporarily revoke the SA_GLANALYTIC role from all users until the upgrade is applied.

bash

# WAF-style validation for filter_type before it reaches FrontAccounting
# Only allow comma-separated integers (e.g., "0,1,2,4")
if ! [[ "$FILTER_TYPE" =~ ^[0-9]+(,[0-9]+)*$ ]]; then
    echo "Rejected: invalid filter_type parameter" >&2
    exit 1
fi