CVE-2026-47343

Zmiana haseł użytkowników backendu za pomocą modułu ustawień użytkownika skutkuje przechowywaniem hasła w postaci niezaszyfrowanej w polach uc i user_settings tabeli bazy danych be_users. Problem ten dotyczy TYPO3 CMS w wersji 14.2.0.

W TYPO3 CMS wykryto podatność na deserializację plików w spoolu pocztowym. Lokalny użytkownik z prawem zapisu do katalogu spool może stworzyć złośliwy plik, który zostanie zdeserializowany podczas wykonywania komendy mailer:spool:send, umożliwiając wykonanie dowolnego kodu PHP na serwerze. Problem dotyczy wersji 10.0.0-10.4.54, 11.0.0-11.5.48, 12.0.0-12.4.40, 13.0.0-13.4.22 oraz 14.0.0-14.0.1.

W TYPO3 CMS użytkownicy backendu z dostępem do modułu recycler mogli usuwać dowolne dane z tabel bazy danych zdefiniowanych w TCA, niezależnie od uprawnień do tych tabel. Umożliwiało to atakującym usunięcie krytycznych danych witryny, co skutecznie czyniło stronę niedostępną. Problem dotyczy wersji 10.0.0-10.4.54, 11.0.0-11.5.48, 12.0.0-12.4.40, 13.0.0-13.4.22 oraz 14.0.0-14.0.1.

Wzmocnienie referrer wprowadzone w TYPO3-CORE-SA-2020-006 (CVE-2020-11069) stało się nieskuteczne w TYPO3 v13.0, gdzie TYPO3 CMS zaczął serwować aplikacje backend i Install Tool z głównego skryptu wejściowego strony zamiast z dedykowanego katalogu typo3/. Określanie, czy żądanie pochodzi z backendu lub Install Tool, odbywało się przez porównanie referrera z katalogiem skryptu wejściowego, którym od tego czasu jest katalog główny strony. W rezultacie żądania pochodzące z dowolnego skryptu działającego na jednej z własnych domen instancji TYPO3, takich jak strona frontendowa, były akceptowane przez trasy backendu i punkty końcowe Install Tool. Atakujący zdolni do wykonania JavaScript na jednej z tych domen, na przykład poprzez wykorzystanie podatności na cross-site scripting, mogli wywoływać te punkty końcowe przez Fetch/XHR z uprawnieniami uwierzytelnionej sesji ofiary. Problem dotyczy TYPO3 CMS w wersjach 13.0.0-13.4.33 i 14.0.0-14.3.5.

Podatność w TYPO3 CMS umożliwia użytkownikom przesyłanie plików o dowolnych typach MIME do formularzy używających elementów FileUpload lub ImageUpload z skonfigurowanym allowedMimeTypes. Ograniczenie nie było egzekwowane po stronie serwera, ponieważ MimeTypeValidator był rejestrowany podczas budowania formularza przed zastosowaniem właściwości definicji formularza, co skutkowało tym, że walidator nigdy nie był dodawany do potoku przetwarzania.

Użytkownicy backendu z uprawnieniami do pobierania plików mogą pobierać pliki z magazynu rezerwowego warstwy abstrakcji plików (FAL) za pośrednictwem modułu Media. Ponieważ magazyn rezerwowy rozwiązuje ścieżki względem katalogu głównego serwera, może to ujawnić poufne pliki, takie jak pliki dziennika. Problem dotyczy TYPO3 CMS w wersjach 11.0.0-11.5.50, 12.0.0-12.4.45, 13.0.0-13.4.30 i 14.0.0-14.3.2.

Użytkownicy backendu z dostępem do zapisu w tabeli form_definition mogą bezpośrednio tworzyć, aktualizować lub usuwać definicje formularzy przez DataHandler, omijając walidację i kontrole uprawnień Form Framework. Umożliwia to wstrzykiwanie dowolnych konfiguracji formularzy, w tym ataki SQL injection i eskalację uprawnień.

TYPO3 CMS ma podatność w cache frontend (VariableFrontend) i trwałym magazynie klucz-wartość (Registry), gdzie deserializowane są ładunki PHP bez walidacji integralności lub ograniczeń klas. Atakujący z zapisem do backendu (np. baza SQL) może wstrzyknąć spreparowany ładunek, prowadząc do zdalnego wykonania kodu.

W TYPO3 CMS funkcja GeneralUtility::isAllowedAbsPath() sprawdzała dozwolone ścieżki przez porównanie prefiksu bez wymagania separatora katalogów, co pozwalało administratorom z dostępem do File Abstraction Layer na tworzenie definicji magazynów plików poza katalogiem głównym.

Uwierzytelnieni użytkownicy backendu mogli pobierać metadane plików przez kilka interfejsów API Backend bez odpowiednich kontroli uprawnień, co umożliwiało dostęp do plików poza dozwolonymi montowaniami lub magazynami. Problem dotyczy TYPO3 CMS przed wersjami 10.4.57, 11.0.0-11.5.50, 12.0.0-12.4.45, 13.0.0-13.4.30 i 14.0.0-14.3.2.