SQL Injection in FrontAccounting Prior to 2.4.20

Executive Summary

CVE-2026-40524 is a high-severity SQL injection vulnerability in FrontAccounting versions before 2.4.20, specifically in the get_gl_transactions() function. The issue occurs because the filter_type parameter is concatenated directly into a SQL IN() clause without proper parameterization or type casting.

Attackers who have SA_GLANALYTIC permission can exploit this vulnerability by injecting malicious SQL code. They do this by supplying a closing parenthesis followed by crafted conditions, enabling a boolean-based blind SQL injection attack.

This attack technique allows the attacker to extract sensitive journal entry data by observing differences in response sizes, such as the size of generated PDF reports, which vary depending on whether injected conditions evaluate to true or false.

The root cause is the unsafe handling of input parameters without proper sanitization or parameterization, and the existing HTML sanitization filter does not prevent this type of integer-based SQL injection.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows attackers with specific permissions to perform SQL injection attacks that can extract sensitive journal entry data from FrontAccounting systems. This unauthorized data extraction could lead to exposure of sensitive financial information.

Such exposure of sensitive data may result in non-compliance with data protection regulations and standards like GDPR and HIPAA, which require safeguarding personal and financial information against unauthorized access and breaches.

Therefore, if exploited, this vulnerability could compromise the confidentiality and integrity of sensitive data, potentially leading to regulatory violations and associated legal or financial penalties.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have serious impacts as it allows attackers with certain permissions to extract sensitive data from the accounting system's database.

• Attackers can retrieve sensitive journal entry data, which may include financial records and possibly password hashes.
• The boolean-based blind SQL injection technique enables attackers to systematically extract data without direct data reflection, making the attack stealthy and reliable.
• Exploitation of this vulnerability could lead to unauthorized data disclosure, potentially compromising the confidentiality and integrity of financial information.
• The vulnerability has a high CVSS score (7.2 to 8.8), indicating significant risk and potential impact.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by attempting to exploit the boolean-based blind SQL injection in the get_gl_transactions() function, specifically targeting the filter_type parameter. An attacker can inject SQL payloads that close the IN() clause and add conditions to observe differences in response sizes.

One detection method involves sending crafted requests with injected SQL conditions such as '0) OR 1=1-- -' and observing the size of the generated report or response. A true condition typically results in a significantly larger response (~340KB) compared to a false condition (~2KB).

While specific commands are not detailed in the provided resources, a typical approach would be to use tools like curl or sqlmap to send POST requests to the vulnerable endpoint (e.g., rep702.php) with manipulated filter_type parameters and analyze the response size differences.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade FrontAccounting to version 2.4.20 or later, where the vulnerability has been patched.

If upgrading is not immediately possible, restrict access to users with SA_GLANALYTIC permission and monitor or block suspicious requests targeting the get_gl_transactions() function.

Implement input validation and parameterized queries for the filter_type parameter to prevent SQL injection. Specifically, applying strict type casting (e.g., casting filter_type to an integer) or centralized input validation can mitigate the risk.

Useful 0 Not Useful 0