Jeśli otrzymali Państwo ode mnie wiadomość e-mail kierującą na tę stronę, to dlatego, że Państwa witryna najwyraźniej korzysta z wersji iCagenda (rozszerzenia com_icagenda firmy JoomliC, rozszerzenia kalendarza wydarzeń dla systemu zarządzania treścią Joomla), objętej znanym problemem bezpieczeństwa. Ta strona wyjaśnia, na czym polega ten problem, jak sprawdzić, czy dotyczy on Państwa witryny, oraz jak go naprawić.

Ten biuletyn dotyczy CVE-2026-48939, krytycznej, aktywnie wykorzystywanej luki, która umożliwia nieuwierzytelnione przesłanie dowolnego pliku prowadzące do zdalnego wykonania kodu za pośrednictwem front-endowego formularza rozszerzenia „Submit an Event”. Została ona dodana do katalogu Known Exploited Vulnerabilities amerykańskiej Cybersecurity and Infrastructure Security Agency 10 lipca 2026 r.

Dwa warunki, oba muszą być spełnione

Państwa witryna jest zagrożona problemem zdalnego wykonania kodu, gdy spełnione są oba poniższe warunki:

  1. iCagenda jest w linii 4.0.x, w wersji poniżej 4.0.8 (czyli od 4.0.0 do 4.0.7), oraz
  2. rdzeń Joomla jest w wersji poniżej 6.1.2.

Jeśli iCagenda jest w wersji 4.0.8 lub nowszej, problem Państwa nie dotyczy. A jeśli rdzeń Joomla jest w wersji 6.1.2 lub nowszej, problem również Państwa nie dotyczy, nawet przy starej wersji iCagendy, ponieważ sam rdzeń blokuje przesyłanie pliku. Jeśli to opisuje Państwa witrynę, mogą Państwo przerwać lekturę w tym miejscu, z tym zastrzeżeniem, że aktualizacja iCagendy nadal jest warta wykonania.

Drugi warunek to część, w której ta strona nie zgadza się z poradą samego producenta, która mówi, że problem dotyczy wyłącznie witryn działających na Joomla 6. W rzeczywistości dotyczy on również w pełni zaktualizowanych witryn na Joomla 4 i Joomla 5, a dowody na to przedstawiam poniżej, ponieważ pod podanym linkiem zobaczą Państwo, że producent twierdzi inaczej.

Jeśli mają Państwo wersję objętą problemem, proszę zaktualizować iCagendę, a ponieważ ta luka była wykorzystywana, zanim istniała poprawka, proszę również sprawdzić witrynę pod kątem oznak, że ktoś zdążył tam dotrzeć wcześniej (zobacz Jeśli korzystali Państwo z wersji, której dotyczy problem poniżej).

Uwaga dla wszystkich na starszej linii 3.9.x. Opublikowany zakres CVE obejmuje również 3.9.x, a producent załatał i tę linię, w wersji 3.9.15. Z własnej lektury kodu i własnych testów wynika, że linia 3.9.x wykorzystuje inną, zabezpieczoną ścieżkę kodu dla przesyłania pliku, więc wynik w postaci zdalnego wykonania kodu nie jest tam osiągalny: na Joomla 4 i 5 przesyłanie blokuje rdzeń, a na Joomla 6 ta ścieżka kodu w ogóle już nie istnieje, więc funkcja po prostu zwraca błąd. Nie jest to powód, by zignorować aktualizację. Te same wydania naprawiają brakującą kontrolę autoryzacji, która pozwala anonimowemu odwiedzającemu wepchnąć do Państwa witryny niezatwierdzone wydarzenie (a na Joomla 4 i 5, wraz z nim także plik dozwolonego typu). Niższa istotność, ale wciąż warto to naprawić: proszę zaktualizować do wersji 3.9.15 lub nowszej. Proszę też zwrócić uwagę, że producent zapewnia poprawki bezpieczeństwa dla linii 3.9.x tylko do 13 października 2026 r.

Czy ta wiadomość jest wiarygodna?

Tak. Jest to powiadomienie o odpowiedzialnym ujawnieniu, złożone w dobrej wierze przez niezależnego badacza bezpieczeństwa. Nie proszę Państwa o pieniądze, hasła ani dostęp do Państwa witryny, i nie próbowałem się do niej włamać, niczego przesłać ani niczego wykorzystać.

To, co odczytałem, to dwa publiczne pliki, które Państwa witryna udostępnia każdemu, kto o nie poprosi: manifest komponentu iCagenda pod adresem /administrator/components/com_icagenda/icagenda.xml oraz manifest rdzenia Joomla pod adresem /administrator/manifests/files/joomla.xml. Oba to zwykłe pliki XML z numerem wersji i są to te same dwa pliki, opisane w sekcji Jak sprawdzić swoje wersje poniżej, dzięki czemu mogą Państwo zobaczyć dokładnie to, co ja zobaczyłem. To wszystko. Celowo nie wypełniłem Państwa formularza zgłoszenia wydarzenia, niczego nie przesłałem i nie zażądałem katalogu załączników na Państwa witrynie. Ta ścieżka pojawia się dalej na tej stronie wyłącznie jako miejsce, w którym Państwo sami mogą sprawdzić swoją własną witrynę. Nic w tym sprawdzeniu nie dotyka Państwa danych, panelu administracyjnego ani żadnej prywatnej części Państwa witryny.

Jeśli chcą Państwo zweryfikować, kim jestem, dane kontaktowe znajdują się na dole tej strony oraz na stronie O mnie.

Dlaczego to ważne

iCagenda publikuje kalendarz wydarzeń na witrynach Joomla. Jedna z jej funkcji pozwala odwiedzającemu zgłosić wydarzenie za pomocą formularza front-endowego, opcjonalnie załączając plik, który trafia do katalogu images/icagenda/frontend/attachments/.

W wersjach objętych problemem to zgłoszenie jest przyjmowane bez logowania, a załącznik jest zapisywany na dysku bez żadnej kontroli tego, jakiego rodzaju jest to plik, z zachowaniem nazwy i rozszerzenia wybranego przez osobę zgłaszającą. Ta kombinacja pozwala atakującemu umieścić na Państwa serwerze dowolnie wybrany przez siebie program i go uruchomić: pełne zdalne wykonanie kodu, bez konta i bez jakiejkolwiek współpracy z Państwa strony.

Nie trzeba niczego włączać, aby problem miał zastosowanie. Formularz nie musi być opublikowany ani widoczny dla odwiedzających: w wersjach objętych problemem znajdujący się za nim kontroler przyjmował zgłoszenie niezależnie od tego.

Nie jest to ryzyko teoretyczne. Otrzymała ocenę 9,8 na 10 według NVD (a 10,0 według organu nadającego ten numer CVE, w nowszym systemie oceny), i jest wykorzystywana w praktyce. Producent zgłasza, że wykorzystywanie rozpoczęło się 15 czerwca 2026 r. o godzinie 08:00 UTC, zanim istniała jeszcze poprawka, i opisuje te ataki jako zautomatyzowane. CISA dodało tę lukę do katalogu Known Exploited Vulnerabilities 10 lipca 2026 r.

Opisuję to na poziomie, jakiego potrzebuje właściciel witryny, by podjąć działanie, i nie dalej. Nie publikuję szczegółów, które pozwoliłyby komuś to odtworzyć, i prosiłbym, aby nie próbowali Państwo tego robić na własnej witrynie ani na witrynie kogokolwiek innego. Sprawdzenie obu Państwa numerów wersji, jak opisano poniżej, mówi Państwu wszystko, co potrzebne, by zdecydować, co robić.

Jeśli mój e-mail powołał się na ten problem, oznacza to, że wersje zgłaszane przez Państwa witrynę mieszczą się w zakresie objętym problemem pod oboma względami. Nie sprawdzałem, czy akurat Państwa witryna jest podatna na wykorzystanie ani czy już została naruszona.

Gdzie ta strona różni się od porady producenta

Poradę producenta warto przeczytać i link do niej podaję poniżej. Producent szybko wydał poprawkę, a jego wskazówki są dobre. Jedno zdanie w niej, dotyczące zakresu problemu, jednak się nie broni, a ponieważ to właśnie to zdanie kazałoby większości czytelników tej strony się rozluźnić, chcę pokazać, na czym oparłem swój wniosek, zamiast po prostu go stwierdzić. Porada mówi:

Niebezpieczne przesyłanie plików było domyślnie blokowane na wszystkich wersjach Joomla przed Joomla 6. Tylko instalacja iCagendy na Joomla 6 (6.0.0-6.1.1) miała krytyczną lukę w przesyłaniu.

Oto, co zmierzyłem na własnych, izolowanych instalacjach. Żadna witryna osoby trzeciej nie była w to w żadnym momencie zaangażowana.

  • iCagenda w linii 4.0.x wykonuje przesyłanie za pomocą klasy frameworka Joomla\Filesystem\File, pochodzącej z pakietu joomla/filesystem, dołączanego przez rdzeń Joomla. Nie korzysta ze starszej klasy Joomla CMS o tej samej nazwie, tej, która od zawsze zawierała kontrolę bezpiecznego pliku i którą prawdopodobnie ma na myśli porada producenta.
  • Ta metoda z frameworka zyskała własną kontrolę bezpiecznego pliku (parametr $allowUnsafe i test isSafeFile) dopiero w joomla/filesystem 4.2.0, czyli w wersji dołączanej do Joomla 6.1.2.
  • Wersje faktycznie dołączane do sprawdzonych przeze mnie wydań Joomla: Joomla 4.4.14 zawiera filesystem 2.0.2 (bez kontroli), Joomla 5.4.7 zawiera 3.2.0 (bez kontroli), a Joomla 6.1.2 zawiera 4.2.0 (kontrola obecna).

Zatem w pełni załatana witryna na Joomla 4 lub Joomla 5, z iCagendą w wersji od 4.0.0 do 4.0.7, jest narażona, i dlatego ta strona formułuje warunek dotyczący Joomla jako „poniżej 6.1.2”, a nie „tylko Joomla 6”. Nic w opublikowanym zapisie CVE, we wpisie NVD ani w katalogu CISA nie ogranicza tego problemu do konkretnej wersji Joomla w ogóle; zdanie z porady producenta jest jedynym miejscem, w którym takie ograniczenie się pojawia.

Jak sprawdzić swoje wersje

Nie muszą Państwo wierzyć mi na słowo co do żadnej z tych dwóch liczb, a jest ich dwie do sprawdzenia.

Wersja Państwa iCagendy, z pliku manifestu (bez potrzeby logowania): proszę otworzyć

yourdomain.com/administrator/components/com_icagenda/icagenda.xml

i odczytać element <version>. To jeden z dwóch plików, które odczytałem.

Wersja Państwa iCagendy, z panelu administracyjnego:

  1. Proszę zalogować się do panelu administracyjnego Joomla (zwykle pod adresem yourdomain.com/administrator).
  2. Przejść do System, następnie Zarządzaj, a potem Rozszerzenia.
  3. Wyszukać iCagenda i odnotować zainstalowaną wersję.

Proszę zwrócić uwagę, który plik icagenda.xml Państwo czytają. Pakiet iCagenda zawiera również dołączoną wtyczkę wyszukiwania z manifestem o tej samej nazwie, mającym własny, niezwiązany z tym numer wersji. Tylko ścieżka komponentu podana powyżej mówi Państwu, jaką wersję rozszerzenia mają Państwo uruchomioną.

Wersja Państwa rdzenia Joomla: w panelu administracyjnym proszę przejść do System, a następnie Informacje o systemie. Albo proszę odczytać /administrator/manifests/files/joomla.xml i wziąć jego element <version>. To drugi z odczytanych przeze mnie plików.

Nie ma sposobu, by odczytać wersję iCagendy ze źródła Państwa publicznej strony, i nie powinni Państwo tego próbować. Zasoby front-endowe rozszerzenia noszą ogólny dla całej witryny hash mediów Joomla, a nie numer wersji, a jedyna liczba przypominająca numer wersji, jaka pojawia się w źródle strony, należy do pakietu zasobów modułu kalendarza (niska liczba, na przykład 1.0.4) i nie ma nic wspólnego z komponentem. Jedynym rzetelnym sprawdzeniem jest plik manifestu lub ekran administracyjny.

Następnie proszę zastosować regułę z góry tej strony: linia 4.0.x poniżej 4.0.8 oraz rdzeń poniżej 6.1.2 oznaczają, że witryna jest zagrożona.

Jak zaktualizować

Najbezpieczniejsza droga to aktualizacja przez samą Joomlę, po uprzednim wykonaniu kopii zapasowej:

  1. Proszę wykonać kopię zapasową swojej witryny (plików i bazy danych) przed wprowadzeniem zmian. Większość dostawców hostingu oferuje kopie zapasowe jednym kliknięciem, można też skorzystać z rozszerzenia do tworzenia kopii zapasowych Joomla.
  2. W panelu administracyjnym Joomla proszę otworzyć Rozszerzenia, następnie Zarządzaj, a potem Aktualizacja, i kliknąć Znajdź aktualizacje. Jeśli na liście pojawi się aktualizacja iCagendy, proszę zainstalować ją stąd.
  3. Jeśli żadna aktualizacja się tam nie pojawi, proszę pobrać bieżące wydanie bezpośrednio od producenta, JoomliC, i zainstalować je przez Rozszerzenia, a następnie Instalacja.
  4. Którą wersję zainstalować: 4.0.8 to wydanie, które naprawia ten problem, ale bieżące wydanie w chwili pisania tego tekstu to 4.0.11, a wydania po 4.0.8 dodają dalszą ochronę wokół tej samej funkcji, w tym blokadę uruchamiania kodu z katalogu mediów iCagendy. Proszę przejść do 4.0.11, zamiast zatrzymywać się na 4.0.8. Na starszej linii proszę przejść do 3.9.15 lub nowszej.
  5. Alternatywnie, aktualizacja rdzenia Joomla do wersji 6.1.2 lub nowszej również zamyka ten konkretny problem, ale nie zastępuje aktualizacji rozszerzenia: brakująca kontrola autoryzacji znajduje się w samej iCagendzie i tylko aktualizacja iCagendy to naprawia.
  6. Po aktualizacji proszę potwierdzić nowy numer wersji, korzystając z powyższych kroków, i sprawdzić, czy kalendarz nadal się wyświetla, a zgłaszanie wydarzeń nadal działa tak, jak Państwo tego oczekują.

Skoro już Państwo tam są, warto potwierdzić, że sama Joomla oraz pozostałe Państwa rozszerzenia są aktualne, ponieważ ta sama zasada dotyczy ich wszystkich.

Jeśli korzystali Państwo z wersji, której dotyczy problem

Ponieważ ta luka była wykorzystywana zanim dostępna była poprawka, witryna, która działała na wersji objętej problemem, nie powinna zakładać, że sama aktualizacja wystarczy. Aktualizacja zamyka drzwi, ale nie mówi, czy ktoś już wcześniej przez nie przeszedł. Warto to sprawdzić spokojnie, zamiast zakładać najgorsze: większość witryn nie znajdzie niczego. W słowach samego producenta:

Aktualizacja zamyka punkt wejścia i zabezpiecza funkcję załączników plików, ale nie oczyszcza już naruszonej witryny. […] Proszę zachować kopię wszelkich podejrzanych plików jako dowód, usunąć je, zmienić hasła i dane uwierzytelniające Joomla oraz przeprowadzić audyt całej witryny, a nie tylko katalogu iCagendy.

Oto, czego Państwo (lub Państwa webmaster) mogą szukać na swojej własnej witrynie:

  • Pliki PHP w katalogu images/icagenda/frontend/attachments/. Ten katalog powinien zawierać wyłącznie załączniki wydarzeń. Na hoście linuksowym sprawdzenie wygląda tak:

    find images/icagenda/frontend/attachments -name '*.php' -type f
  • Niezatwierdzone anonimowe wydarzenia oczekujące w kolejce moderacji, których nie spodziewaliby się Państwo, jeśli nigdy nie otworzyli Państwo zgłaszania wydarzeń dla ogółu odwiedzających.
  • Wpisy w dziennikach dostępu pochodzące od skanera przedstawiającego się jako icagenda-batch/1.0.

Od wersji 4.0.8 iCagenda sama również sprawdza oznaki naruszenia i po aktualizacji zgłasza alert, jeśli je znajdzie. Producent otwarcie przyznaje, że brak takiego alertu nie jest gwarancją, więc jest to użyteczny sygnał, a nie czyste świadectwo bezpieczeństwa.

Jeśli znajdą Państwo którykolwiek z tych sygnałów, proszę potraktować witrynę jako naruszoną: proszę zachować kopie podejrzanych plików jako dowód, a następnie je usunąć, zmienić wszystkie dane uwierzytelniające (panel administracyjny Joomla, bazę danych, FTP/SSH, panel hostingu), przejrzeć konta użytkowników Joomla i grupy, do których należą, oraz przeprowadzić audyt całej witryny, a nie tylko katalogu iCagendy. Przywrócenie z kopii zapasowej wykonanej przed 15 czerwca 2026 r. jest często bezpieczniejsze niż czyszczenie na miejscu, ponieważ pozostawiony backdoor może cofnąć skutki czyszczenia. Jeśli Państwa organizacja ma zespół bezpieczeństwa IT lub krajowy CERT, proszę ich włączyć do sprawy.

Chcę to jasno powiedzieć: nie sprawdzałem Państwa witryny pod kątem żadnego z tych wskaźników i nie wiem, czy Państwa witryna była objęta problemem. Ta lista znajduje się tutaj po to, aby mogli Państwo sprawdzić samodzielnie.

Nie mam webmastera / utknąłem

Jeśli nie zajmują się Państwo witryną osobiście, proszę przekazać tę stronę osobie, która to robi (deweloperowi, agencji lub firmie hostingowej). Powyższe kroki rozpozna od razu.

Jeśli utrzymują Państwo witrynę samodzielnie i utkną, chętnie bezpłatnie wskażę właściwy kierunek. Proszę napisać, korzystając z danych kontaktowych poniżej.

Kontakt

Evan Harris, badacz bezpieczeństwa

Kontaktuję się w takich sprawach wyłącznie po to, by pomóc operatorom zabezpieczyć ich witryny. Jeśli wolą Państwo nie otrzymywać kolejnych wiadomości, proszę dać znać; uszanuję to.

Źródła

Oficjalne komunikaty i śledzenie

Producent (JoomliC)