FrontAccounting through 2.4.20 Cross-Site Request Forgery on Financial Transaction Forms
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| FrontAccounting | FrontAccounting | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Frontaccounting | Frontaccounting |
|
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.219% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | FrontAccounting through 2.4.20 Cross-Site Request Forgery on Financial Transaction Forms | |
| First Time appeared |
Frontaccounting
Frontaccounting frontaccounting |
|
| Weaknesses | CWE-352 | |
| CPEs | cpe:2.3:a:frontaccounting:frontaccounting:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Frontaccounting
Frontaccounting frontaccounting |
|
| References |
|
|
| Metrics |
cvssV3_1
|