Katalog CVE

CVE-2026-80210

ŚrednieCVSS 6.5
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.16%

Percentyl 6 - wyżej niż 6% wszystkich znanych CVE

Streszczenie

FrontAccounting do wersji 2.4.20 generuje token CSRF w end_form() w includes/ui/ui_controls.inc i osadza go jako ukryte pole _token w każdym formularzu, ale tylko admin/users.php i admin/change_current_user_password.php wywołują check_csrf_token() w celu jego walidacji. Żaden moduł obsługi transakcji finansowych nie waliduje tokenu, w tym gl/gl_journal.php, gl/gl_bank.php, purchasing/supplier_invoice.php, sales/customer_invoice.php, sales/customer_payments.php i admin/company_preferences.php, więc te punkty końcowe działają na danych POST bez sprawdzania pochodzenia. Atakujący, który sprawi, że uwierzytelniony użytkownik załaduje stronę pod kontrolą atakującego, może automatycznie wysłać formularz z innego pochodzenia do dowolnego z nich i spowodować zapisanie sfałszowanego wpisu księgowego, faktury, płatności klienta, transakcji bankowej lub zmiany konfiguracji firmy w sesji ofiary.

Ocena ryzyka

Brak walidacji tokenów CSRF w krytycznych operacjach finansowych umożliwia atakującemu wykonywanie nieautoryzowanych transakcji i zmian konfiguracji w imieniu ofiary, co może prowadzić do strat finansowych i naruszenia integralności danych.

Rekomendacja

Zastosuj poprawkę, która dodaje walidację tokenu CSRF we wszystkich modułach obsługi transakcji finansowych i konfiguracyjnych, oraz rozważ wdrożenie dodatkowych mechanizmów ochrony, takich jak sprawdzanie nagłówka Origin.

Oryginalny opis (angielski, źródło NVD)

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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS