FrontAccounting CVE-2026-80210

The victim must have an active authenticated session in FrontAccounting (through 2.4.20) in the same browser profile at the time they visit the attacker-controlled page. No special server-side configuration is required - the CSRF validation gap is present in the default codebase for all listed financial endpoints. The attacker requires no credentials or account on the target FrontAccounting instance. Exploitation is bounded by the mandatory user interaction prerequisite (UI:P per CVSS 4.0): the attacker cannot trigger the forged request without the authenticated victim loading the malicious page, meaning social engineering or a malicious advertisement on a site the victim visits is required. Non-default configurations do not expand the attack surface - the vulnerability exists regardless of whether optional modules or features are enabled.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P, score 7.1) accurately characterises the threat: exploitation is network-reachable with no attack complexity, but user interaction is required (UI:P) - the attacker cannot exploit this purely server-side and must socially engineer an authenticated user. No EPSS score was provided in the input data; no CISA KEV listing is present; and no public exploit code beyond a researcher's disclosure writeup was identified. The integrity impact is rated High (VI:H) with no confidentiality or availability consequence, which maps well to the ability to forge journal entries, invoices, and payments. Because FrontAccounting is typically deployed by small accounting teams or SMBs rather than large enterprise stacks, the blast radius per instance is constrained, but any organization using it for live financial record-keeping should treat this as urgent: forged transactions in an accounting system can be difficult to detect and roll back cleanly, and even a mid-sized municipal IT team in gniezno facing an audit would find unexplained journal entries costly to remediate. There is no signal conflict between the CVSS vector and the vulnerability description.

A researcher disclosure with technical specifics is publicly available at https://github.com/geo-chen/oss/blob/main/FA.md, documenting the affected endpoints and the missing validation calls. An attacker constructs a web page containing a hidden HTML form targeting the victim's FrontAccounting instance - for example, posting a crafted debit/credit pair to gl/gl_journal.php with attacker-chosen amounts and account codes - and uses JavaScript to auto-submit it on page load. When a bookkeeper who is logged into FrontAccounting clicks a phishing link to this page, the browser transparently sends the forged POST authenticated by the existing session cookie, and the fraudulent journal entry is committed to the accounting ledger without any server-side rejection.