CVE-2026-80211
ŚrednieCVSS 5.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 16 - wyżej niż 16% wszystkich znanych CVE
Streszczenie
FrontAccounting do wersji 2.4.20 przechowuje i weryfikuje hasła użytkowników jako niesolone skróty MD5. admin/users.php przekazuje md5($_POST['password']) do add_user() i update_user_password(), admin/change_current_user_password.php robi to samo, gdy użytkownik zmienia własne hasło, ścieżka zapomnianego hasła w includes/current_user.inc haszuje nowo wygenerowane hasło w ten sam sposób, a uwierzytelnianie wywołuje get_user_auth($loginname, md5($password)). Kod nie stosuje soli per hasło i nie zawiera wywołań password_hash(), password_verify() ani żadnego innego adaptacyjnego haszowania, więc identyczne hasła dają identyczne skróty, a atakujący, który uzyska tabelę użytkowników, może odzyskać hasła w postaci jawnej za pomocą prekomputerowanych tablic lub szybkiego łamania na GPU.
Ocena ryzyka
Ujawnienie bazy danych użytkowników może prowadzić do szybkiego odzyskania haseł, co umożliwia nieautoryzowany dostęp do kont i potencjalnie do innych systemów, jeśli użytkownicy używają tych samych haseł.
Rekomendacja
Zastosuj aktualizację lub poprawkę, która zastępuje niesolone MD5 bezpiecznym, adaptacyjnym haszowaniem haseł (np. bcrypt, argon2) i wymusza zmianę haseł użytkowników.
Inne podatności w FrontAccounting
Zobacz wszystkie- CVE-2026-40523Wysokie
FrontAccounting przed wersją 2.4.20 zawiera podatność na wstrzykiwanie SQL w module raportu audytu. Uwierzytelnieni atakujący z uprawnieniami SA_GLANALYTIC mogą wstrzykiwać złośliwy kod do parametrów POST PARAM_2 i PARAM_3, wykonując dowolne zapytania SQL.
- CVE-2026-40522Wysokie
W FrontAccounting przed wersją 2.4.20 występuje podatność na wstrzykiwanie SQL w module raportu wyciągu bankowego. Uwierzytelniony atakujący może wstrzyknąć złośliwe zapytania UNION SELECT do parametru PARAM_0 POST, co pozwala na wyodrębnienie dowolnych danych z bazy, w tym nazw użytkowników, skrótów haseł i adresów e-mail, które są renderowane w raporcie PDF.
- CVE-2014-3973Wysokie
Wielokrotne podatności na wstrzykiwanie SQL w FrontAccounting (FA) przed wersją 2.3.21 umożliwiają zdalnym atakującym wykonywanie dowolnych poleceń SQL za pomocą nieokreślonych wektorów.
- CVE-2026-80210Średnie
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.
- CVE-2026-40524Wysokie
FrontAccounting przed wersją 2.4.20 zawiera podatność na wstrzykiwanie SQL w funkcji get_gl_transactions(), gdzie parametr filter_type jest bezpośrednio konkatenowany do klauzuli SQL IN() bez parametryzacji. Atakujący z uprawnieniami SA_GLANALYTIC mogą wstrzyknąć dowolny SQL, dostarczając zamykający nawias i złośliwe warunki, aby wyodrębnić poufne dane wpisów księgowych poprzez ślepe wstrzykiwanie SQL oparte na różnicach w rozmiarze odpowiedzi.
- CVE-2026-40521Wysokie
Podatność path traversal w FrontAccounting przed wersją 2.4.20 pozwala uwierzytelnionym atakującym na zdalne wykonanie kodu poprzez przesyłanie plików z sekwencjami nawigacji w parametrze unique_name. Atakujący mogą zapisać plik PHP poza katalogiem załączników do katalogu głównego serwera WWW, co umożliwia wykonanie dowolnego kodu.
Oryginalny opis (angielski, źródło NVD)
FrontAccounting through 2.4.20 stores and verifies user passwords as unsalted MD5 digests. admin/users.php passes md5($_POST['password']) to add_user() and update_user_password(), admin/change_current_user_password.php does the same when a user changes their own password, the forgotten-password path in includes/current_user.inc hashes the newly generated password the same way, and authentication calls get_user_auth($loginname, md5($password)). The codebase applies no per-password salt and contains no call to password_hash(), password_verify() or any other adaptive hash, so identical passwords yield identical digests and an attacker who obtains the user table can recover plaintext passwords with precomputed lookup tables or high-rate GPU cracking.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS