Krótko: PHP2Shell i Log4Shell łączy to, że są krytycznymi lukami w bardzo rozpowszechnionym elemencie podstawowym, przez które atakujący mogą wykonać kod bez logowania. Różnią się widocznością, klasyfikacją i sytuacją w zakresie znanych ataków. Najważniejsza lekcja z Log4Shell obowiązuje dziś bez zmian: kto wie, gdzie działa dotknięty element, działa w godzinach, a nie w tygodniach.
Dlaczego to porównanie pojawia się akurat wszędzie
W grudniu 2021 roku Log4Shell trzymał świat IT w napięciu przez tygodnie. BSI ogłosiło wtedy najwyższy poziom ostrzeżenia, czerwony. Prawie pięć lat później przy PHP2Shell w wielu artykułach pada ta sama nazwa, często w połączeniu z pytaniem: „Czy będzie znowu tak źle?”
Porównanie jest oczywiste i bywa użyteczne, jeśli prowadzi się je właściwie. Pokazuje, które wzorce się powtarzają i z jakich doświadczeń firmy mogą korzystać bezpośrednio. Jak BSI klasyfikuje obecną sytuację, wyjaśnia artykuł Poziom pomarańczowy BSI.
PHP2Shell i Log4Shell w bezpośrednim porównaniu
| Cecha | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Dotknięte oprogramowanie | biblioteka Javy Log4j | samo środowisko PHP |
| Identyfikator | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Ocena | CVSS 10,0 (v3) | CVSS v4.0 9,2 |
| Skutek | wykonanie kodu bez logowania | wykonanie kodu bez logowania |
| Poziom ostrzeżenia BSI | 4 / czerwony | 3 / pomarańczowy |
| Sytuacja w chwili ostrzeżenia | według ówczesnych doniesień znane naruszenia | zgłoszone próby ataków, według BSI początkowo brak potwierdzonych udanych ataków na szeroką skalę |
| Widoczność | często głęboko ukryta w aplikacjach | widoczne na serwerze, ale stan poprawek trudno odczytać przez backporty |
| Kolejne komunikaty | kilka dalszych CVE w ciągu kilku tygodni | wskazówka dotycząca CVE-2026-115560 z 23.10. |
Co mają wspólnego obie luki
Jeden element podstawowy, niezliczone aplikacje. Log4j tkwiła w oprogramowaniu Javy każdego rodzaju, PHP niesie WordPressa, Shopware, TYPO3 i niezliczone rozwiązania własne. W obu przypadkach dotknięty jest nie jeden produkt, lecz fundament.
Logowanie niepotrzebne. Obie luki umożliwiają zdalne wykonanie kodu bez logowania. Czyni je to atrakcyjnymi dla zautomatyzowanych ataków.
Poprawka to nie koniec. Przy Log4Shell okazało się, że wiele systemów zostało zaatakowanych jeszcze przed aktualizacją. Także przy PHP2Shell obowiązuje: poprawka nie usuwa wprowadzonego złośliwego oprogramowania. Według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17 października.
Kolejne komunikaty. Po Log4Shell w ciągu kilku tygodni pojawiły się kolejne CVE dotyczące Log4j. W PHP dwa dni po poprawkach pojawiła się wskazówka dotycząca CVE-2026-115560. Dlaczego kolejne komunikaty są prawdopodobne, wyjaśnia artykuł Po PHP2Shell: dlaczego kolejne komunikaty są prawdopodobne.
Gdzie porównanie kuleje
Największa różnica leży w widoczności. Log4j była często wbudowana jako część aplikacji, czasem wielokrotnie zagnieżdżona. Wielu operatorów po prostu nie wiedziało, że jej używa. PHP natomiast nie jest na serwerze WWW tajemnicą. Za to przy PHP2Shell powstaje inna niejasność: dystrybucje i dostawcy hostingu instalują poprawki jako backport, wyświetlany numer wersji pozostaje ten sam. Widać PHP, ale nie od razu, czy jest załatane.
Druga różnica to punkt wyjścia przy aktualizacji. Przy Log4Shell często producenci aplikacji branżowych musieli najpierw dostarczyć nowe wersje. Przy PHP2Shell aktualizacje dla wszystkich wspieranych gałęzi są gotowe. Trudno robi się przy PHP 8.1 i starszym, dla których projekt PHP nie publikuje już oficjalnych aktualizacji.
Trzecia różnica dotyczy miejsca ataku. Przy Log4Shell niebezpieczne mogło być każde miejsce, w którym aplikacja rejestrowała dane wejściowe, a więc także systemy wewnętrzne, które otrzymywały dane z internetu tylko pośrednio. Przy PHP2Shell w centrum stoi serwer WWW, który przyjmuje żądania bezpośrednio. Czyni to szukanie dotkniętych systemów nieco bardziej przejrzystym: najpierw wszystkie publicznie dostępne usługi PHP, potem aplikacje wewnętrzne.
Wreszcie różni się sytuacja w zakresie wykorzystania. Dla Log4Shell wcześnie krążyły proste narzędzia ataku, a naruszenia były według ówczesnych doniesień znane już w chwili ostrzeżenia. Przy PHP2Shell Cloudflare i Patchstack informują o próbach ataków, watchTowr odtworzył według własnych informacji jedną z luk, a potwierdzonych udanych ataków na szeroką skalę BSI początkowo nie zgłosiło. To może się zmienić. Jest to jednak powód, dla którego porównanie nie nadaje się na prognozę.
Proszę wykorzystać doświadczenia z Log4Shell we własnym domu: Jakie listy, procedury i kontakty pomogły wtedy? Wiele z tego można bezpośrednio użyć ponownie dla PHP2Shell.
Pięć lekcji z Log4Shell, które pomagają dziś
- Inwentarz przed poprawką: Kto miał w 2021 roku aktualną listę swoich systemów, był szybszy. Dziś jest tak samo. Instrukcję oferuje artykuł Inwentarz wszystkich stron i serwerów.
- Znać zależności: Lista elementów oprogramowania, w skrócie SBOM, odpowiada na pytanie „Gdzie to u nas używamy?” w minuty. Dla aplikacji PHP pomaga spojrzenie do Composera, jak opisuje Sprawdzanie zależności Composera.
- Przechowywać logi: Po Log4Shell wiele firm nie mogło już wyjaśnić, czy były dotknięte, ponieważ brakowało logów. Prasa branżowa radzi przy PHP2Shell zabezpieczyć logi od 20 października.
- Sprawdzić wstecz: Poprawka nie odpowiada na to, co działo się wcześniej. Sprawdzenie śladów do tego należy.
- Być przygotowanym na kolejne komunikaty: Pierwsza aktualizacja rzadko jest ostatnią. Kto raz czysto ustawił ścieżkę aktualizacji, szybko ją powtarza.
Jak konkretnie pomaga PHP SOS?
- Inwentaryzacja: Ustalamy, gdzie w Państwa firmie działa PHP, w jakiej wersji i trybie pracy.
- Poprawka i restart: Instalujemy aktualizacje i dokumentujemy stan każdego systemu.
- Sprawdzenie śladów: Zabezpieczamy logi i sprawdzamy nieprawidłowości od 17 października.
- Stała obserwacja: Mamy Państwa systemy na oku, aby kolejne komunikaty nie zaczynały się znowu od zera.
Jak wygląda stały nadzór, opisuje monitoring bezpieczeństwa dla serwerów WWW.
Podsumowanie
PHP2Shell to nie Log4Shell, ale się rymuje. Obie uderzają w fundament, obie wymagają czegoś więcej niż poprawki. Firmy, które z 2021 roku wyniosły inwentarz, przechowywanie logów i ścieżki aktualizacji, mają dziś przewagę. Dla wszystkich pozostałych to teraz czas, by to nadrobić.
Częste pytania
Czy PHP2Shell jest tak groźne jak Log4Shell?
Obie to krytyczne luki w bardzo rozpowszechnionym oprogramowaniu, przez które atakujący mogą wykonać kod bez logowania. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) sklasyfikowało Log4Shell w 2021 roku jako czerwony, PHP2Shell jako pomarańczowy. Istotna różnica: przy Log4Shell według ówczesnych doniesień w chwili ostrzeżenia znane były już naruszenia, przy PHP2Shell według BSI początkowo nie było potwierdzonych udanych ataków na szeroką skalę.
Czym był Log4Shell?
Log4Shell była krytyczną luką w bibliotece Javy Log4j, która stała się znana w grudniu 2021 roku i jest prowadzona pod numerem CVE-2021-44228. Log4j tkwiła jako element w bardzo wielu aplikacjach, często bez wiedzy operatorów.
Czy po PHP2Shell pojawią się kolejne luki?
To możliwe. Po Log4Shell w ciągu kilku tygodni pojawiły się kolejne CVE dotyczące Log4j. W PHP już 23 października pojawiła się wskazówka dotycząca CVE-2026-115560, która działa tylko przy nietypowej konfiguracji. Proszę uwzględnić w planach kolejne komunikaty.
Czym jest SBOM?
Software Bill of Materials to lista wszystkich elementów oprogramowania, z których składa się aplikacja. Dzięki niej przy nowej luce można szybko ustalić, gdzie używany jest dotknięty element.