CVE-2026-49738

Formularze TYPO3 używające elementów FileUpload lub ImageUpload z niestandardowym ustawieniem saveToFileMount zapisywały przesłane pliki w domyślnym folderze 1:/user_upload/ zamiast w skonfigurowanej lokalizacji. W efekcie pliki mogły trafić do publicznie dostępnego magazynu, mimo że skonfigurowano magazyn ograniczony. Pliki zapisane w ten sposób są serwowane bezpośrednio, bez kontroli dostępu stosowanych do magazynów niepublicznych.

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.

Administratorzy backendu bez uprawnień system maintainer mogą planować wykonywanie poleceń configuration:read, configuration:set i configuration:show. Umożliwia to modyfikację konfiguracji systemu, co normalnie jest zarezerwowane dla system maintainerów, co może prowadzić do eskalacji uprawnień lub odmowy usługi.

Odkryto, że kilka tras AJAX używanych w backendowym kreatorze lokalizacji nie przeprowadzało kontroli autoryzacji. Umożliwiło to uwierzytelnionym użytkownikom backendu o niskich uprawnieniach dostęp do informacji o rekordach i elementach treści spoza ich dozwolonego zakresu. Wykorzystanie tej podatności wymaga konta użytkownika backendu o niskich uprawnieniach. Problem dotyczy TYPO3 CMS w wersjach 10.0.0-10.4.59, 11.0.0-11.5.53, 12.0.0-12.4.48, 13.0.0-13.4.34 i 14.0.0-14.3.6.

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ń.