FrontAccounting versions up to 2.4.20 implement a CSRF token for every form but only the administrative user‑management pages validate it. The financial transaction handlers—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—lack this validation, so they process POST data without any origin or authenticity check. An attacker who tricks an authenticated user into loading a malicious page can automatically submit a cross‑origin form to any of these endpoints, creating or altering journal entries, invoices, payments, bank transactions, or company settings under the victim’s session. The flaw is a classic type‑III Cross‑Site Request Forgery (CWE‑352) that allows untrusted actions to be performed with the victim’s privileges.

The affected product is FrontAccounting, supplied by the vendor FrontAccounting. All releases through and including version 2.4.20 contain the flaw. The vulnerability specifically impacts the financial transaction handlers mentioned above, which are part of one or more public or internal forms for journal entries, bank transactions, supplier invoices, customer invoices, customer payments, and company preferences.

The CVSS score of 7.1 indicates a high severity vulnerability. The EPSS score is not available, and the issue is not listed in CISA KEV, suggesting no confirmed widespread exploitation yet. The attack requires an authenticated user session; the attacker must be able to deliver a malicious page that submits a form to the target endpoint. Successful exploitation would allow the attacker to insert or modify financial records, potentially leading to significant integrity and accounting errors for the affected organization.