CVE-2026-110878

Aureus ERP do wersji 1.6.0 zawiera podatność typu stored XSS w pliku HolidayAction.php. Uwierzytelnieni użytkownicy mogą wstrzykiwać skrypty JavaScript poprzez nieescapowane nazwy świąt renderowane jako HtmlString, które wykonują się gdy menedżerowie HR lub administratorzy otwierają modal świąt.

Aureus ERP do wersji 1.6.0 zawiera podatność na obejście autoryzacji, która pozwala nieuwierzytelnionym atakującym na odczyt nieopublikowanych szkiców wpisów na blogu przez stronę widoku posta dla klientów. Atakujący, którzy znają lub zgadną slug posta, mogą pobrać pełny tytuł, treść, obraz, tagi, autora i datę publikacji, ponieważ PostResource pomija autoryzację, a ViewPost ignoruje is_published.

Aureus ERP do wersji 1.6.0 (poprawka w commit 53ad76d) przechowuje przesłane pliki SVG na publicznym dysku i serwuje je z pochodzenia aplikacji, co pozwala uwierzytelnionym użytkownikom na przesyłanie złośliwych plików SVG zawierających JavaScript. Atakujący mogą tworzyć pliki SVG z elementami script, które wykonują się w pochodzeniu aplikacji po otwarciu URL-a pliku, umożliwiając kradzież ciasteczek sesji i eksfiltrację tokenów CSRF.

Aureus ERP przed wersją 1.5.0 nie ogranicza wyszukiwania wiadomości do bieżącego rekordu w ChatterPanel, umożliwiając uwierzytelnionym użytkownikom dostęp do dowolnych wiadomości. Atakujący mogą podawać kolejne identyfikatory wiadomości, aby czytać, edytować, usuwać lub przypinać wiadomości z innych działów lub firm oraz wyliczać wszystkie notatki w systemie.

Aureus ERP w wersjach przed 1.6.0 zawiera podatność typu stored cross-site scripting w logu zmian pola Chatter, gdzie wpisy old_value i new_value są renderowane bez prawidłowego escapowania. Każdy użytkownik uprawniony do edycji śledzonych pól tekstowych może wstrzyknąć złośliwy markup, który wykona się, gdy inni użytkownicy, w tym administratorzy, wyświetlą panel Chatter rekordu.

Aureus ERP do wersji 1.6.0 przechowuje pole notatki warunków płatności bez sanityzacji i renderuje je jako surowy HTML we wtyczce Księgowość. Uwierzytelnieni użytkownicy z uprawnieniami do tworzenia warunków płatności mogą przesłać dowolny kod JavaScript do punktu końcowego payment-terms, który jest zapisywany w bazie danych i wykonywany w przeglądarkach wszystkich użytkowników przeglądających ten rekord.