Krytyczne RCE i SQL injection w ZOO dla Joomla. Aktualizuj do 4.1.65

W rozszerzeniu ZOO firmy YOOtheme wykryto trzy podatności dostępne bez logowania. Najgroźniejsza pozwala przesłać na serwer dowolny plik i doprowadzić do zdalnego wykonania kodu. Druga umożliwia SQL injection, a trzecia przekierowanie użytkownika na zewnętrzną stronę.

Podatne są wszystkie wydania ZOO od 1.0.0 do 4.1.63. Poprawki pojawiły się 19 sierpnia 2026 roku w wersji 4.1.64, ale jeszcze tego samego dnia producent wydał 4.1.65 z dokończoną ochroną uprawnień przy zarządzaniu tagami. Docelowo należy zainstalować ZOO 4.1.65 lub wersję nowszą.

Aktualny pakiet można pobrać po zalogowaniu do konta YOOtheme lub zainstalować przez system aktualizacji Joomla, jeśli w ZOO skonfigurowano prawidłowy klucz pobierania. Numer najnowszej wersji zawsze sprawdź w oficjalnym changelogu ZOO. Informacje o dostępie do aktualizacji znajdują się na stronie licencji ZOO.

Po instalacji poprawki trzeba skontrolować katalog images/zoo/uploads/. Plik PHP, podwójne rozszerzenie lub inny nietypowy plik w tym miejscu należy potraktować jako możliwy ślad włamania. Sama aktualizacja zamyka podatność, ale nie usuwa kodu przesłanego wcześniej przez atakującego.

Joomla Guru może wykonać kopię zapasową, aktualizację ZOO i testy formularzy. Jeżeli w katalogu uploadów znajdują się podejrzane pliki albo pojawiły się nieznane konta administratorów, potrzebna jest analiza całej instalacji i ewentualne usunięcie skutków włamania.

Trzy podatności w ZOO do wersji 4.1.63

ZOO jest komponentem typu CCK, używanym do tworzenia własnych typów treści, katalogów, blogów i formularzy zgłoszeniowych. Podatności znalezione przez Phila Taylora z mySites.guru dotyczą różnych części komponentu. Łączy je brak wymogu logowania.

Rekordy CVE obejmują wersje od 1.0.0 do 4.1.63. Nie jest to zatem problem wyłącznie kilku ostatnich wydań. Podatny kod może znajdować się także na starszych stronach, które od lat nie były modernizowane.

CVE-2026-74803: upload pliku prowadzący do RCE

Najgroźniejszy błąd znajduje się w elemencie obrazu używanym w formularzu zgłoszeniowym ZOO od strony frontowej. Rozszerzenie sprawdzało typ MIME zadeklarowany przez przeglądarkę podczas wysyłania pliku. Taka wartość jest częścią żądania i może zostać dowolnie ustawiona przez atakującego.

W praktyce plik PHP mógł zostać przedstawiony jako obraz. ZOO nie sprawdzało wystarczająco jego rzeczywistej zawartości ani nie ograniczało rozszerzenia do bezpiecznej listy. Nazwa przechodziła przez mechanizm usuwający niedozwolone znaki, ale rozszerzenie .php pozostawało. Następnie plik był zapisywany w katalogu images/zoo/uploads/, który znajduje się wewnątrz publicznego katalogu strony.

Jeżeli serwer wykonywał w tym katalogu pliki PHP, wystarczyło wywołać przesłany adres w przeglądarce. Atakujący mógł uruchomić własny kod z uprawnieniami procesu PHP, a następnie dodać kolejne backdoory, przejąć dane dostępowe lub zmienić zawartość witryny.

Ten scenariusz wymaga dostępnego formularza zgłoszeniowego zawierającego element Image. Strona bez takiego formularza nie jest podatna przez tę konkretną drogę. Nadal może jednak podlegać opisanemu niżej SQL injection.

CVE-2026-74804: SQL injection bez formularza zgłoszeniowego

Druga krytyczna podatność znajduje się w metodzie obsługującej elementy pozycji ZOO. Parametry filter_type i type_filter były wstawiane do zapytania SQL bez właściwego cytowania i oczyszczania. Punkt wejścia był dostępny dla anonimowego użytkownika.

Ta luka nie zależy od opublikowania formularza frontowego. Według analizy mySites.guru wystarcza zainstalowana aplikacja ZOO. Dlatego nie można uznać strony za bezpieczną tylko dlatego, że użytkownicy nie mają możliwości przesyłania obrazów.

SQL injection może ujawnić informacje zapisane w bazie Joomla, w tym dane użytkowników i skróty haseł. Oficjalna ocena CVSS 4.0 wynosi 9,3. Jeśli strona długo działała na podatnej wersji, po aktualizacji należy sprawdzić konta użytkowników i logi, a przy oznakach wykorzystania luki wymusić zmianę haseł.

CVE-2026-75114: otwarte przekierowanie

Trzecia luka dotyczyła obsługi uwierzytelniania komentarzy przez Twittera. Parametr referer trafiał bez walidacji do funkcji ustawiającej przekierowanie. Przygotowany link mógł prowadzić użytkownika przez zaufaną domenę Joomla na stronę kontrolowaną przez atakującego.

Open redirect nie daje bezpośredniego dostępu do plików lub bazy danych, ale bywa używany w phishingu. Adres zaczyna się od prawidłowej domeny, co może ułatwić przekonanie użytkownika do otwarcia linku i podania danych na fałszywej stronie.

Dlaczego zalecamy 4.1.65, a nie 4.1.64?

ZOO 4.1.64 naprawia wszystkie trzy podatności oznaczone numerami CVE. W changelogu producent zapowiedział również ochronę CSRF i kontrolę uprawnień administratora przy zarządzaniu tagami. Jak ustaliło mySites.guru, część dotycząca ACL nie została w tym wydaniu skutecznie zastosowana.

YOOtheme opublikowało wersję 4.1.65 jeszcze 19 sierpnia. Wydanie egzekwuje uprawnienia administratora przy zarządzaniu tagami i domyka zmianę rozpoczętą w 4.1.64. Ten dodatkowy problem wymagał konta z dostępem do zaplecza ZOO i nie otrzymał osobnego CVE, ale nie ma powodu pozostawać na przejściowej wersji.

Po aktualizacji sprawdź changelog ponownie. Jeżeli producent wydał już wersję wyższą niż 4.1.65, zainstaluj najnowsze stabilne wydanie.

ZOO 3.x także jest podatne

Zakres podatnych wersji zaczyna się od 1.0.0, więc obejmuje całą linię ZOO 3.x. Producent opublikował poprawkę tylko w gałęzi 4.x. Nie ma osobnego wydania bezpieczeństwa dla ZOO 3.

Administrator starszej strony powinien zaplanować przejście do aktualnej linii ZOO 4 i obsługiwanej wersji Joomla. Jeśli migracja nie może zostać wykonana natychmiast, bezpieczniejszym rozwiązaniem jest wyłączenie publicznych funkcji ZOO lub całkowite usunięcie komponentu po wykonaniu kopii i migracji potrzebnych danych. Pozostawienie dostępnego ZOO 3.x nie zamyka SQL injection.

Jak zaktualizować ZOO?

1. Sprawdź wersję ZOO w System → Zarządzanie → Rozszerzenia i zapisz listę używanych aplikacji, typów treści oraz dodatkowych elementów ZOO.
2. Wykonaj pełną kopię plików i bazy danych. Upewnij się, że kopia może zostać odtworzona poza serwerem produkcyjnym.
3. Jeśli masz aktywną licencję, skonfiguruj klucz pobierania i użyj aktualizatora Joomla albo pobierz bieżący pakiet po zalogowaniu do YOOtheme.
4. Zainstaluj ZOO 4.1.65 lub nowsze bez wcześniejszego odinstalowywania komponentu.
5. Wyczyść pamięć podręczną Joomla, serwera i CDN, a następnie ponownie sprawdź numer wersji.
6. Przetestuj aplikacje ZOO, widoki kategorii i pozycji, wyszukiwanie, komentarze, formularze zgłoszeniowe oraz przesyłanie prawidłowych obrazów.

ZOO jest obecnie dystrybuowane komercyjnie. Nowe pakiety i aktualizacje są dostępne zgodnie z warunkami subskrypcji YOOtheme. Jeżeli wygasła, nie pobieraj pakietu z przypadkowych repozytoriów i serwisów oferujących rozszerzenia Joomla — nie ma pewności, czy taki plik nie został zmodyfikowany.

Co sprawdzić po aktualizacji?

Najpierw przejrzyj katalog images/zoo/uploads/ oraz jego podkatalogi. Powinny znajdować się tam obrazy przesłane przez prawidłowe formularze. Szczególną uwagę zwróć na:

• pliki z rozszerzeniem .php, .phtml, .phar lub podwójnym rozszerzeniem;
• pliki udające obraz, których zawartość nie odpowiada formatowi JPEG, PNG, WebP lub AVIF;
• nieznane pliki utworzone albo zmodyfikowane w ostatnim czasie;
• ukryte pliki konfiguracyjne, w tym nieoczekiwane .htaccess lub web.config.

Nie ograniczaj analizy do katalogu ZOO. Uruchomiony webshell może zapisać kolejne pliki w innych miejscach dostępnych dla PHP. Sprawdź niedawno zmienione pliki wykonywalne, wtyczki systemowe, zadania cykliczne, plik configuration.php oraz katalogi mediów innych rozszerzeń.

Jak rozpoznać możliwe włamanie?

• w Joomla pojawiło się nieznane konto Super User albo zmieniły się uprawnienia istniejącego konta;
• w logach znajdują się nietypowe żądania do ZOO, po których następują wywołania plików w images/zoo/uploads/;
• na serwerze działają nowe zadania cykliczne lub procesy wykonujące połączenia z nieznanymi adresami;
• zmieniły się pliki PHP, które nie były objęte aktualizacją, albo w katalogach obrazów pojawił się kod;
• użytkownicy otrzymują nieoczekiwane przekierowania, wiadomości o zmianie hasła lub powiadomienia o logowaniu.

Nie ma obecnie publicznego potwierdzenia masowego wykorzystywania CVE-2026-74803. Brak takiego komunikatu nie wyklucza pojedynczych ataków. Podatność ma maksymalną ocenę CVSS, nie wymaga konta i pozwala wykonać kod, więc aktualizacji nie należy odkładać.

Aktualizacja nie usuwa backdoora

Po udanym wykorzystaniu RCE atakujący nie musi ponownie korzystać z luki ZOO. Może pozostawić osobny plik PHP, konto administratora, zmodyfikowaną wtyczkę lub zadanie cykliczne. Instalacja wersji 4.1.65 zablokuje następne próby przez podatny formularz, ale istniejący mechanizm dostępu nadal będzie działał.

Jeśli znajdziesz podejrzany plik, nie usuwaj wyłącznie tej jednej pozycji i nie uznawaj sprawy za zamkniętą. Zabezpiecz kopię do analizy, sprawdź całą instalację, odtwórz czyste pliki z zaufanych pakietów i ustal, czy baza danych nie została odczytana przez SQL injection. Hasła, klucze API i dane dostępowe zmieniaj po usunięciu backdoorów, aby nowe dane nie trafiły ponownie do atakującego.

Pomoc przy aktualizacji i czyszczeniu ZOO

W ramach opieki serwisowej Joomla możemy sprawdzić wersję i licencję ZOO, wykonać kopię zapasową, przeprowadzić aktualizację i przetestować aplikacje oraz formularze. Jeśli strona działała na ZOO 4.1.63 lub starszym, możemy również przeanalizować katalog uploadów, pozostałe pliki, konta użytkowników i logi. Przy potwierdzonej infekcji wykonujemy czyszczenie strony Joomla i zabezpieczenie serwisu po włamaniu.

Źródła i dalsza lektura

• YOOtheme: oficjalny changelog ZOO
• YOOtheme: strona produktu ZOO
• YOOtheme: licencje i dostęp do aktualizacji ZOO
• CVE-2026-74803: unauthenticated arbitrary file upload w ZOO
• CVE-2026-74804: unauthenticated SQL injection w ZOO
• CVE-2026-75114: open redirect w ZOO