CVE-2026-41660

Admidio przed wersją 5.0.10 zawiera podatność CSRF w akcji `mode=export` w `modules/sso/keys.php`, która eksportuje pakiet PKCS#12 z kluczem prywatnym i certyfikatem. Walidacja tokena CSRF jest zakomentowana, co pozwala na sfałszowane żądanie POST z sesji administratora i wyeksportowanie klucza prywatnego bez ważnego tokena.

Admidio przed wersją 5.0.10 zawiera podatność w modules/documents-files.php, gdzie obsługa trybów zmiany stanu sprawdza uprawnienia upload na parametrze folder_uuid, ale handler move_save operuje na oddzielnym parametrze file_uuid i wywołuje File::moveToFolder($destFolderUUID). Funkcja moveToFolder sprawdza uprawnienia upload tylko na folderze docelowym, nie na źródłowym. W rezultacie każdy użytkownik, który może przesyłać pliki do dowolnego folderu, może przenieść dowolny plik z innego folderu, w tym prywatnego, do folderu, który kontroluje, a następnie go pobrać.

Admidio przed wersją 5.0.10 ma brak walidacji tokena CSRF w `modules/registration.php` w trybie `send_login`. Ten tryb generuje nowe losowe hasło dla `user_uuid_assigned`, zapisuje jego hash bcrypt i wysyła hasło jawnym tekstem do użytkownika. Inne tryby w tym samym pliku sprawdzają token CSRF, ale `send_login` tego nie robi. Strona odwiedzona przez administratora rejestracji może wysłać żądanie jako nawigacja najwyższego poziomu, a przeglądarka wyśle ciasteczka `SameSite=Lax`, co pozwoli na zresetowanie hasła wybranego użytkownika bez interakcji administratora.

Admidio przed wersją 5.0.10 ma podatność w `modules/categories.php`, gdzie kontrola uprawnień dla konkretnej kategorii jest martwym kodem, ponieważ porównuje `$getType` (kod typu kategorii) z nazwami trybów (`edit`/`save`/`delete`), co jest zawsze fałszywe. W rezultacie przypadki `delete`, `sequence` i `save` ładują kategorię po UUID i działają na niej bez ponownego sprawdzenia, czy kategoria należy do modułu administrowanego przez aktora. Użytkownik z prawem administratora tylko jednego modułu może niszczyć lub zmieniać kolejność pustych kategorii należących do innych modułów.

Admidio przed wersją 5.0.11 nie waliduje tokena adm_csrf_token w pliku modules/category-report/preferences.php, który dokonuje trwałych zmian konfiguracji Category Report na podstawie parametrów GET (delete i copy). Atakujący może nakłonić uwierzytelnionego administratora do odwiedzenia spreparowanego URL w celu usunięcia lub zduplikowania konfiguracji Category Report, wpływając na integralność i dostępność tego modułu.

Admidio przed wersją 5.0.11 zawiera odbitą podatność na cross-site scripting w punkcie końcowym SSO/SAML. Nieuwierzytelnieni atakujący mogą wstrzyknąć dowolny kod JavaScript przez elementy SAML Issuer lub parametry biblioteki LightSaml, co umożliwia przejęcie sesji użytkowników.

W systemie Admidio przed wersją 5.0.11 wykryto podatność ominięcia uwierzytelniania w module forum, gdy jest on skonfigurowany w trybie login-only. Logika kontroli dostępu w pliku modules/forum.php nie sprawdza poprawnie stanu konfiguracji, co pozwala nieuwierzytelnionym atakującym na odczyt tematów i postów na forum.

Admidio przed wersją 5.0.11 nie weryfikuje przynależności do docelowej organizacji w handlerach ról. Uwierzytelnieni administratorzy ról mogą usuwać, aktywować, dezaktywować lub edytować role należące do innych organizacji, podając UUID roli z innej organizacji.

Admidio to open-source'owe narzędzie do zarządzania użytkownikami. Przed wersją 5.0.10, gdy włączone jest logowanie debugowania, `Session::setCookie()` loguje pełne wartości ciasteczek, a `Session::start()` loguje bieżący identyfikator sesji. W rzeczywistym wdrożeniu Admidio obejmuje to zarówno aktywne ciasteczko sesji, jak i trwałe ciasteczko automatycznego logowania. Każdy, kto ma dostęp do dziennika, może odzyskać aktywne poświadczenia typu bearer z logów. Wersja 5.0.10 zawiera poprawkę.

Admidio to open-source'owe narzędzie do zarządzania użytkownikami. Wersja 5.0.9 dodała brakującą kontrolę `isAdministratorInventory()` do `case 'item_delete':` w `modules/inventory.php`. Ta sama poprawka nie została zastosowana do sąsiedniego `case 'field_delete':`, który niszczy całą definicję pola inwentarza, kaskadowo usuwając wszystkie wiersze `adm_inventory_item_data` i wpisy `adm_inventory_field_options`. Procedura sprawdza tylko token CSRF związany z sesją; nie ma kontroli `isAdministratorInventory()` na poziomie kontrolera, a `Admidio\Inventory\Entity\ItemField::delete()` nie egzekwuje jej na poziomie encji (w przeciwieństwie do `ItemField::save()`, które sprawdza `$gCurrentUser->isAdministrator()`). Każdy zalogowany użytkownik może trwale zniszczyć nie-systemowe pole inwentarza, wysyłając jeden POST. Wersja 5.0.10 zawiera poprawkę.