CVE-2026-71510

W Dolibarr w wersji 16 przed 16.0.5 występuje problem, który pozwala nieautoryzowanym atakującym na wykonanie zrzutu bazy danych oraz dostęp do pełnych informacji o klientach, potencjalnych klientach, dostawcach i pracownikach, jeśli istnieje plik kontaktowy.

W podatności CVE-2017-14242 występuje luka typu SQL injection w pliku don/list.php w wersji 6.0.0 systemu Dolibarr, która pozwala zdalnym atakującym na wykonywanie dowolnych poleceń SQL poprzez parametr statut.

Dolibarr w wersjach od 9.0.0 do 23.0.4 zapisuje załączniki przychodzących wiadomości e-mail pod nazwą pochodzącą z nagłówków MIME bez redukcji do bezpiecznej nazwy bazowej. Funkcje saveAttachment() w htdocs/emailcollector/lib/emailcollector.lib.php oraz w htdocs/emailcollector/class/emailcollector.class.php budują ścieżkę pliku z nazwy załącznika, która może zawierać sekwencje przejść ścieżek, co pozwala na zapis treści poza katalogiem docelowym.

Dolibarr przed wersją 23.0.4 autoryzuje usuwanie dokumentów przez REST API z użyciem niewłaściwego uprawnienia. Funkcja Documents::delete() wywołuje dol_check_secure_access_document() z trybem 'read' zamiast 'write', co pozwala uwierzytelnionemu użytkownikowi z tylko uprawnieniami do odczytu na trwałe usunięcie dokumentów modułu.

Dolibarr przed wersją 24.0.0 zawiera podatność na wstrzyknięcie SQL w kreatorze importu CSV i XLSX. Kreator odczytuje klucze aktualizacji przez GETPOST('updatekeys', 'array') w htdocs/imports/import.php, stosując tylko filtr alphanohtml, który nie usuwa słów kluczowych SQL, komentarzy, nawiasów, spacji i cudzysłowów. Funkcja import_insert() w htdocs/core/modules/import/import_csv.modules.php buduje filtr z $where[] = $key.' = '.$data[$key] i wykonuje go przez $this->db->query(), co pozwala na wstrzyknięcie SQL.

Dolibarr w wersjach od 21.0.0 do 24.0.0 zawiera podatność na obejście autoryzacji spowodowaną odwróconym warunkiem logicznym w sprawdzaniu członkostwa w prywatnym projekcie w handlerze akcji masowych clonetasks w pliku htdocs/core/actions_massactions.inc.php. Uwierzytelnieni użytkownicy z uprawnieniami do tworzenia projektów, ale bez dostępu do docelowego prywatnego projektu, mogą wykorzystać błędne sprawdzenie !in_array() do klonowania zadań do nieautoryzowanych prywatnych projektów.

Dolibarr przed wersją 24.0.0 zawiera podatność na ujawnienie wrażliwych danych w REST API modułu Members. Uwierzytelniony atakujący z uprawnieniami odczytu członków może pobrać weryfikatory haseł bcrypt, odwołując się do endpointów członków. Pola weryfikatorów nie są filtrowane przez serializer API ani klasę Members API, co umożliwia ataki offline na hasła.

Dolibarr przed wersją 24.0.0 zawiera podatność na niewłaściwą autoryzację w punkcie końcowym aktualizacji REST API raportów wydatków. Uwierzytelniony atakujący z uprawnieniami do tworzenia wydatków może ominąć proces zatwierdzania, bezpośrednio ustawiając pola statusu zatwierdzenia i tożsamości zatwierdzającego. Atakujący mogą manipulować polami stanu przepływu pracy, aby przesunąć raporty wydatków do statusu zatwierdzonego lub zamkniętego bez posiadania dedykowanego uprawnienia do zatwierdzania, tworząc również niespójności kryminalistyczne w rekordach audytu z powodu braku znaczników czasu zatwierdzenia.

Dolibarr przed wersją 24.0.0 zawiera podatność na niewłaściwą autoryzację w punkcie końcowym aktualizacji REST API użytkowników. Atakujący z uprawnieniami do zapisu użytkowników mogą modyfikować pola płacowe, wykorzystując niekompletną listę zabronionych poświadczeń, która pomija kolumny płacowe. Atakujący mogą przepisać pensję, bonus, stawkę godzinową, stawkę dzienną i tygodniowe godziny dla dowolnego użytkownika bez posiadania uprawnień do płac, a zmodyfikowane wartości pojawiają się w raportach eksportu płac.

Dolibarr przed wersją 24.0.0 zawiera podatność na zepsutą autoryzację na poziomie obiektu w trasach zapisu kont bankowych firm w REST API. Uwierzytelniony atakujący z uprawnieniami do tworzenia podmiotów trzecich może tworzyć, zastępować lub usuwać dane kont bankowych dowolnej firmy bez wymaganego dostępu do odczytu tej firmy. Atakujący mogą wstrzykiwać kontrolowane przez siebie numery IBAN jako konta wierzycieli, które są następnie zapisywane w generowanych plikach SEPA, przekierowując płatności wychodzące na konta atakującego.