Strona firmowa oparta na gotowym systemie zarządzania treścią rzadko składa się z samego systemu. Dochodzą do niego dodatki: galeria, formularz, edytor tekstu wygodniejszy od wbudowanego.
Strona firmowa oparta na gotowym systemie zarządzania treścią rzadko składa się z samego systemu. Dochodzą do niego dodatki: galeria, formularz, edytor tekstu wygodniejszy od wbudowanego. Ten wpis opisuje przypadek, w którym jeden z takich dodatków pozwolił osobie z zewnątrz, bez żadnego konta, ustalić sobie własne zasady wgrywania plików, a następnie umieścić na serwerze plik wykonywalny. Znajdziesz tu mechanizm, wersję naprawiającą problem i wyjaśnienie, po czym poznać, że ocena usterki mówi „to się już dzieje", a nie „to może się zdarzyć".
JCE to edytor treści dla Joomli, jednego z popularnych systemów, na których stoją strony firmowe. Zamiast surowego pola tekstowego daje redaktorowi pasek z formatowaniem, wstawianie zdjęć i wgrywanie plików. Żeby wiedzieć, komu na co pozwolić, edytor korzysta z profili: zestawów ustawień mówiących, że redaktor może wgrywać zdjęcia, a autor tylko pisać tekst.
Usterka oznaczona jako CVE-2026-48907 polega na tym, że tworzenie nowego profilu było dostępne dla osoby niezalogowanej. Klasyfikacja nazywa to CWE-284, niewłaściwa kontrola dostępu, i ta nazwa dobrze oddaje sedno: funkcja działała poprawnie, tylko była otwarta dla kogoś, kto nigdy nie powinien jej zobaczyć. Skutkiem końcowym, jak podaje opis, jest wgranie i wykonanie kodu PHP na serwerze, czyli języka, w którym napisana jest sama strona.
Wyobraź sobie magazyn, w którym przy bramie wisi tablica z listą rzeczy, jakie wolno wwieźć. Ochroniarz sumiennie sprawdza każdą dostawę i porównuje ją z tablicą. Usterka polega na tym, że tablica wisi po zewnętrznej stronie bramy, a marker leży obok. Przyjezdny dopisuje sobie na niej pozycję, wraca do bramy i wjeżdża zgodnie z zasadami, bo ochroniarz robi dokładnie to, co do niego należy.
Plik wgrany w ten sposób to zwykle mały program dający atakującemu stałe wejście, niezależne od tego, czy usterka zostanie później naprawiona. Od tego momentu strona nadal wygląda normalnie, dalej się otwiera, dalej przyjmuje zamówienia. To, co się zmieniło, nie jest widoczne z zewnątrz.
Restauracja z systemem rezerwacji na stronie widzi tego skutki dopiero po kilku tygodniach. Najpierw goście zaczynają dzwonić, że po wejściu na stronę przeglądarka ostrzega ich przed zagrożeniem. Potem strona znika z wyników wyszukiwania, bo wyszukiwarka wykryła podstawiane treści i oznaczyła witrynę. Rezerwacje spadają, a nikt w lokalu nie wie, dlaczego, bo strona z ich komputera wygląda tak samo jak zawsze.
Koszt liczy się w tygodniach nieobecności w wyszukiwarce, a to jest pozycja droższa niż odbudowa samej strony. Powrót do wyników nie następuje w dniu usunięcia szkodliwego pliku, tylko po ponownym sprawdzeniu witryny, a odzyskanie wcześniejszej widoczności bywa kwestią miesięcy. Zamiast tego warto ustawić dwie rzeczy tanie i nudne: kopię zapasową strony trzymaną poza serwerem, na którym ona stoi, oraz kalendarzowe przypomnienie na przegląd dodatków raz na kwartał. Przywrócenie strony z kopii sprzed infekcji jest kwestią godzin, a rekonstrukcja z pamięci pracowników trwa tygodnie.
Przy tej usterce stoją dwie liczby w skali CVSS, czyli w dziesięciostopniowej skali powagi usterek. Zespół bezpieczeństwa Joomli wystawił 10,0 w nowszej, czwartej wersji tej skali. Amerykańska baza NVD wystawiła 9,8 w wersji trzeciej. Obie oceny są w najwyższej kategorii, a różnica bierze się z konstrukcji obu wersji wzoru, nie z odmiennego zdania o zagrożeniu.
Ciekawsza jest część oceny, którą łatwo przeoczyć, bo nie jest liczbą. Nowsza wersja skali pozwala dopisać do oceny informację o stanie faktycznym, i tu dopisano dwie rzeczy. Pierwsza mówi, że dojrzałość wykorzystania ma poziom „atakowane", czyli że ktoś już z tej usterki korzysta w praktyce. Druga to oznaczenie pilności nadane przez dostawcę, ustawione na czerwony, czyli najwyższy poziom.
To jest różnica, którą warto rozumieć przy czytaniu jakiegokolwiek ostrzeżenia o bezpieczeństwie. Sama wysoka ocena mówi, co się stanie, jeśli ktoś usterkę wykorzysta. Dopisek o dojrzałości mówi, czy ktoś już to robi. Pierwsza informacja pozwala planować, druga wyznacza kolejność na dziś rano.
Potwierdza to trzeci wskaźnik, EPSS, szacujący prawdopodobieństwo szerokiego wykorzystania usterki w najbliższym czasie. Tutaj wynosi blisko siedemdziesiąt procent i plasuje sprawę wyżej niż dziewięćdziesiąt dziewięć procent wszystkich znanych podatności. Przy stronach opartych na popularnym systemie zarządzania treścią taki wynik jest oczekiwany: cele są policzalne, adresy łatwe do znalezienia, a atak da się przeprowadzić automatem, jednym skryptem po tysiącach witryn naraz.
Amerykańska agencja CISA prowadzi katalog usterek, przy których istnieje dowód realnego wykorzystania w atakach. Ta trafiła tam 16 czerwca 2026, jako jedyna pozycja dodana tego dnia, a termin dla urzędów federalnych wyznaczono na 19 czerwca 2026. Trzy dni, czyli najkrótszy termin, jaki w tym katalogu bywa stosowany. Tego samego dnia agencja zapisała też osobną ocenę: wykorzystanie aktywne, możliwe do zautomatyzowania, wpływ techniczny całkowity.
Podatne są wersje edytora od 1.0.0 do 2.9.99.4 włącznie, a pierwszą wersją wolną od problemu jest 2.9.99.5. Zakres obejmuje więc całą historię rozszerzenia, co dla właściciela strony oznacza jedno: nie ma tu progu wersji, poniżej którego można spać spokojnie, bo strona jest „za stara, żeby to jej dotyczyło".
Mogę Ci jakoś pomóc?
Katalog CISA odnotowuje przy tym rzecz wartą uwagi. Producent udostępnił nie tylko bieżącą aktualizację, ale także bezpłatną łatkę dla starszych witryn, czyli takich, których nie da się od razu przenieść na najnowsze wydanie. To odpowiedź na realny problem: strona zbudowana kilka lat temu bywa przywiązana do konkretnej wersji dodatku, bo nowsza zmienia wygląd albo psuje szablon. Istnienie osobnej łatki usuwa najczęstszą wymówkę, czyli twierdzenie, że aktualizacja wymaga przebudowy całej witryny.
Warto też zauważyć, kto tę usterkę opisał, a kto ją naprawia. Numer przydzielił zespół bezpieczeństwa Joomli, ale sam edytor pochodzi od innej firmy, Widget Factory, i to ona wydaje poprawkę. Aktualizacja samego systemu Joomla nie podnosi wersji dodatku, a panel aktualizacji potrafi pokazywać zielony status systemu przy jednoczesnym przestarzałym rozszerzeniu. Sprawdzenie stanu strony wymaga więc spojrzenia w dwa miejsca, nie w jedno, i ta zasada dotyczy każdego systemu zbudowanego z dodatków różnych producentów.
Właściciel strony, który nie zajmuje się nią samodzielnie, ma tu jedno konkretne pytanie do osoby albo firmy, która ją prowadzi. Nie brzmi ono „czy strona jest bezpieczna", bo na takie pytanie odpowiedź zawsze jest twierdząca. Brzmi: w jakiej wersji jest zainstalowany edytor JCE i czy jest to co najmniej 2.9.99.5. Numer albo się zgadza, albo nie, i nie ma tu miejsca na interpretację.
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Nie każda usterka wpisana do katalogu potwierdzonych ataków robi coś sama z siebie. CVE-2026-63030 jest tego przykładem: dotyczy rdzenia WordPressa, polega na pomyleniu trasy w zbiorczym punkcie końcowym interfejsu REST API i sama nie prowadzi do wykonania kodu.
Czytaj artykułAmerykańska agencja CISA wpisała lukę CVE-2026-48282 w Adobe ColdFusion do katalogu podatności wykorzystywanych w atakach. Według katalogu termin reakcji wynosił trzy dni, a producent ocenił zagrożenie na dziesięć na dziesięć. Tekst wyjaśnia mechanizm ataku i plan reakcji dla firmy.
Czytaj artykułFormularz do wgrywania pliku wygląda niewinnie i dlatego rzadko trafia na listę rzeczy do sprawdzenia. Usterka oznaczona numerem CVE-2026-20262 pokazuje, co się dzieje, gdy taki formularz przyjmuje nie tylko plik, ale też informację, gdzie go zapisać.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.