CVE-2026-40522: FrontAccounting SQL Injection in Bank Statement Reports

Technical summary

The vulnerability exists in the Bank Statement report handler where user-supplied input in the PARAM_0 POST parameter is concatenated directly into a SQL WHERE clause without parameterization or prepared statements. An attacker with valid authentication credentials can inject UNION SELECT payloads to exfiltrate arbitrary data from the database. The injected SQL is then executed server-side, allowing retrieval of sensitive records—particularly from the users table containing credentials—which are subsequently rendered into generated PDF output. This represents a classic second-order SQL injection scenario where malicious data persists through report generation.

Business impact

Compromise of user credentials and email addresses creates multiple downstream risks: credential stuffing attacks against other systems if passwords are reused, phishing campaigns using legitimate internal email addresses, and privilege escalation if extracted accounts belong to administrators. The ability to extract password hashes may enable offline cracking attempts. For regulated organizations, unauthorized database access can trigger breach notification obligations and compliance violations. The attack surface is limited to authenticated users, reducing overall enterprise risk but elevating insider threat concerns.

Affected systems

FrontAccounting installations running versions prior to 2.4.20 are affected. The vulnerability is specific to the Bank Statement report module and requires successful authentication to exploit. Organizations using this open-source accounting software should inventory all deployments and verify their installed versions.

Exploitability

The vulnerability requires valid login credentials, which substantially increases the barrier to exploitation compared to unauthenticated flaws. However, exploitation difficulty is low once authenticated: a user need only submit a crafted POST request with SQL injection syntax in the PARAM_0 parameter. The attack is reliable and does not depend on user interaction or unusual system configuration. The flaw is not listed in the CISA Known Exploited Vulnerabilities catalog as of the publication date, suggesting no active in-the-wild exploitation has been publicly documented, though this does not guarantee absence of private exploitation.

Remediation

Organizations should upgrade FrontAccounting to version 2.4.20 or later. This version addresses the vulnerability by implementing parameterized queries in the Bank Statement report handler, preventing SQL injection. Until patches can be applied, access to the Bank Statement report feature should be restricted to a minimal set of trusted users, and database activity should be monitored for anomalous queries.

Patch guidance

Upgrade to FrontAccounting 2.4.20 or a newer stable release. Consult the official FrontAccounting project repository and release notes to confirm patch availability and any breaking changes. For enterprises requiring extended support timelines, coordinate with your deployment team to plan upgrade windows that minimize disruption to accounting workflows. Test patches in a non-production environment first, particularly given FrontAccounting's role in financial reporting.

Detection guidance

Monitor web server and application logs for suspicious POST requests to the Bank Statement report handler that contain SQL keywords (SELECT, UNION, CAST, CHAR, etc.) in the PARAM_0 parameter. Database query logs should be inspected for unexpected UNION queries or attempts to access the users table from the FrontAccounting application context. Endpoint detection and response (EDR) solutions may alert on unusual database access patterns. Consider implementing Web Application Firewall (WAF) rules to block payloads containing common SQL injection patterns before they reach the application.

Why prioritize this

While this vulnerability carries a CVSS 3.1 score of 7.1 (HIGH), requiring authentication limits its immediate threat in external attack scenarios. However, organizations should prioritize patching if they: (1) maintain strict access controls but suspect potential insider threats, (2) operate in regulated industries where credential disclosure triggers compliance incidents, or (3) use FrontAccounting in environments where user accounts are shared or poorly managed. The relatively low complexity of exploitation once authenticated makes this a moderate-to-high priority for remediation within normal patch cycles.

Risk score, explained

The CVSS 3.1 score of 7.1 reflects high confidentiality impact (full database read access) and low integrity impact (limited ability to modify data). The authentication requirement (PR:L) prevents remote unauthenticated exploitation, reducing the attack vector severity. The lack of availability impact (no denial of service) further moderates the score. For organizations with strong identity and access management, this score may be locally adjusted downward; for those with weak credential hygiene, it may warrant upward adjustment.

Frequently asked questions