CVE-2026-80210 in FrontAccounting
Summary
by MITRE • 08/27/2026
FrontAccounting through 2.4.20 generates a CSRF token in end_form() in includes/ui/ui_controls.inc and embeds it as the _token hidden field in every form it renders, but only admin/users.php and admin/change_current_user_password.php call check_csrf_token() to validate it. No financial transaction handler validates the token, including gl/gl_journal.php, gl/gl_bank.php, purchasing/supplier_invoice.php, sales/customer_invoice.php, sales/customer_payments.php and admin/company_preferences.php, so those endpoints act on POST data with no origin check. An attacker who gets an authenticated user to load a page under attacker control can auto-submit a cross-origin form to any of them and have the forged journal entry, invoice, customer payment, bank transaction or company configuration change recorded under the victim's session.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in FrontAccounting versions through 2.4.20 represents a critical failure in implementing Cross-Site Request Forgery protections for sensitive financial and administrative operations. While the application framework includes mechanisms to generate and embed CSRF tokens within HTML forms via the end_form function, this security control is inconsistently applied across the codebase. Specifically, while user management endpoints such as admin/users.php and admin/change_current_user_password.php correctly invoke check_csrf_token() to validate incoming requests, a significant number of critical financial transaction handlers completely omit this validation step. This architectural inconsistency creates a severe attack surface where authenticated users can be tricked into performing unintended actions that result in direct financial loss or data integrity compromise.
The technical flaw lies in the selective enforcement of CSRF token verification. The application generates unique tokens for forms but fails to verify them when processing POST requests from several key modules, including gl/gl_journal.php for general ledger entries, gl/gl_bank.php for bank transactions, purchasing/supplier_invoice.php for supplier invoices, sales/customer_invoice.php and sales/customer_payments.php for customer-related financial data, and admin/company_preferences.php for system configuration changes. Because these endpoints do not validate the origin of the request or check for a valid CSRF token, they accept any POST data submitted by an authenticated user's browser session. This allows an attacker to craft malicious web pages that automatically submit forged forms to these vulnerable endpoints when accessed by a victim who is currently logged into FrontAccounting.
The operational impact of this vulnerability is substantial, as it enables attackers to manipulate financial records and system configurations without the victim's explicit consent or knowledge. By leveraging social engineering tactics to get an authenticated user to visit a malicious page, an attacker can execute arbitrary transactions such as creating fake journal entries, altering bank account details, generating fraudulent supplier invoices, recording false customer payments, or modifying critical company preferences. These actions are recorded under the victim's session credentials, potentially leading to significant financial discrepancies, audit trail corruption, and unauthorized changes to system settings that could disrupt business operations or expose further security weaknesses.
To mitigate this risk, it is imperative to enforce CSRF token validation across all state-changing endpoints within the application. Developers should ensure that every POST request handler invokes check_csrf_token() before processing any data, thereby ensuring that requests originate from legitimate forms generated by the application itself. Additionally, implementing additional defenses such as SameSite cookie attributes and verifying custom headers can provide defense-in-depth against cross-origin attacks. This vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery (CSRF), and maps to ATT&CK technique T1078, Valid Accounts, where attackers leverage existing credentials to perform unauthorized actions within a trusted environment. Immediate patching or code remediation is required to close this gap in the application's security posture.