CVE-2026-80210: FrontAccounting through 2.4.20 Cross-Site Request Forgery on Financial Transaction Forms
FrontAccounting through 2.4.20 generates a CSRF token in endform() in includes/ui/uicontrols.inc and embeds it as the token hidden field in every form it renders, but only admin/users.php and admin/changecurrentuserpassword.php call checkcsrftoken() to validate it. No financial transaction handler validates the token, including gl/gljournal.php, gl/glbank.php, purchasing/supplierinvoice.php, sales/customerinvoice.php, sales/customerpayments.php and admin/companypreferences.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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
FrontAccountingto a version that resolves this vulnerability.Fixed in 2.4.20 - Configuration
Ensure every endpoint that processes POST data from financial transaction forms validates the CSRF token by calling check_csrf_token() (not only in admin/users.php and admin/change_current_user_password.php as described).
FrontAccounting (CSRF protection) check_csrf_token() = enabled for all financial transaction form handlers (e.g., gl/gl_journal.php, gl/gl_bank.php, purchasing/supplier_invoice.php, sales/customer_invoice.php, sales/customer_payments.php, admin/company_preferences.php)
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Any authenticated FrontAccounting user who can be induced to load attacker-controlled content is exposed. The forged action is performed under that user's active session and permissions.
Are financial transaction forms protected by the application's existing CSRF token?
No. Although FrontAccounting renders a _token hidden field in forms, the described financial transaction handlers do not validate it; validation is called only by admin/users.php and admin/change_current_user_password.php.
What actions can an attacker forge?
The affected handlers include journal entries, bank transactions, supplier invoices, customer invoices, customer payments, and company preference changes. A cross-origin POST can cause the selected action to be recorded in the victim's session.
Does exploitation require an attacker to authenticate to FrontAccounting?
No attacker account or privileges are required. The attacker needs to cause an already authenticated user to load a page that auto-submits a cross-origin form to an affected endpoint.