cyberszkola/Studium przypadku: PHP2Shell

Studium przypadku · bezpłatne laboratorium z narracją

PHP2Shell: jak sprawdzić, czy łatka PHP działa

Przejdziesz incydent PHP2Shell krok po kroku: od ostrzeżenia php.net do dowodu, że poprawka działa. W przeglądarce, bez zapisu.

9 faz · ok. 22 min · lektor PL, EN, RO · bez zapisu

Uruchom laboratoriumCo zobaczysz
Wyślij sobie link na komputerUruchom mimo to

Bramblewood Academy i Harbourline Cloud są fikcyjne, a publiczny przebieg zdarzeń jest prawdziwy. Laboratorium pokazuje, co zrobił atak, a nigdy, jak go wywołać. Stan faktów: · Źródła

Chcesz ćwiczyć to samodzielnie?Web Security PROKurs ataków i obrony aplikacji webowych: 132 laboratoria w przeglądarce.Start edycji 16 listopada 2026Zobacz kurs
PHP2Shell · studium przypadku

Polecenia i skrypty w laboratorium są napisane dla fikcyjnych serwerów tej symulacji. Nie przenoś ich 1:1 na swój serwer: zatrzymanie kontenera, zmiana php.ini czy podmiana plików PHP mogą wyłączyć usługę.

Laboratorium otwiera się w trybie Z tutorem: przechodzisz krok po kroku we własnym tempie. Wolisz obejrzeć całość jak pokaz? Przełącz tryb na Pokaz.

Demo i laboratoria działają najlepiej na komputerze — laptopie albo komputerze stacjonarnym.

Lektor: głos syntetyczny. Po uruchomieniu laboratorium pobiera ok. 27 MB danych.

Chcesz się tego nauczyć?

Laboratorium z kursu Web Security PRO: aplikacja w przeglądarce, inspektor żądań HTTP i tutor
Tak wygląda laboratorium w kursie: aplikacja, narzędzia i tutor w jednym oknie przeglądarki.

Web i aplikacjeLista oczekujących

Web Security PRO

Kurs ataków i obrony aplikacji webowych. Ćwiczysz samodzielnie w 132 laboratoriach w przeglądarce: rozpoznanie, podatności, dowód i sprawdzenie poprawki.

Start edycji
16 listopada 2026
Planowana cena pierwszej edycji
790 zł brutto
Środowisko
W przeglądarce, bez instalacji
Zobacz kurs Web Security PRO Powiadom mnie o starcie

Program kursu opiera się na OWASP Web Security Testing Guide (WSTG), powszechnie stosowanym przewodniku testowania bezpieczeństwa aplikacji webowych.

W kursie robisz to samodzielnie

Cztery umiejętności z tego przypadku

  • Rozpoznasz serwer i jego wersjęi sprawdzisz, czy baner mówi prawdę. Jak w fazie 2.
  • Znajdziesz zapomniane hosty i ryzykowne ustawieniadrugą nazwę hosta tej samej aplikacji i phpinfo, które nie może być publiczne. Jak w tym przypadku.
  • Udowodnisz podatność bez zgadywaniaz próbą kontrolną, która mogłaby wypaść inaczej. Jak w fazie 5.
  • Sprawdzisz, czy poprawka naprawdę działaponownym testem, a nie numerem wersji. Jak w fazie 8.

Przypadek PHP2Shell to osobne laboratorium, poza 132 laboratoriami kursu. Web Security PRO uczy testowania aplikacji web — nie łatania obrazów kontenerów ani prowadzenia reakcji na incydent.

Mapa do OWASP WSTG (dla zaawansowanych)
  1. Co widzisz w przypadku

    Baner z wersją to trop, nie dowód.

    Gdzie ćwiczysz to w kursieRozpoznawanie serwera po nagłówkach i błędachWSTG-INFO-02
    Rozdział i otwarcie

    Rozdział 01 · Rozpoznanie aplikacji

  2. Co widzisz w przypadku

    Druga nazwa hosta prowadzi do tej samej aplikacji.

    Gdzie ćwiczysz to w kursieWyszukiwanie aplikacji na wspólnym serwerzeWSTG-INFO-04
    Rozdział i otwarcie

    Rozdział 01 · Rozpoznanie aplikacji

  3. Co widzisz w przypadku

    Co stoi między internetem a serwerem.

    Gdzie ćwiczysz to w kursieMapa architektury i zależnościWSTG-INFO-10
    Rozdział i otwarcie

    Rozdział 01 · Rozpoznanie aplikacji

  4. Co widzisz w przypadku

    Znane podatności oprogramowania serwera i ponowny test po poprawce.

    Gdzie ćwiczysz to w kursieKonfiguracja infrastruktury sieciowejWSTG-CONF-01
    Rozdział i otwarcie

    Rozdział 02 · Konfiguracja i wdrożenie

  5. Co widzisz w przypadku

    phpinfo jako przyrząd, który nie może być publiczny.

    Gdzie ćwiczysz to w kursieKonfiguracja platformy aplikacyjnejWSTG-CONF-02
    Rozdział i otwarcie

    Rozdział 02 · Konfiguracja i wdrożenie

  6. Co widzisz w przypadku

    Zrzut bazy przechowywany poza katalogiem aplikacji.

    Gdzie ćwiczysz to w kursieKopie zapasowe i zapomniane plikiWSTG-CONF-04
    Rozdział i otwarcie

    Rozdział 02 · Konfiguracja i wdrożenie

  7. Co widzisz w przypadku

    Ślad, jaki zostawia powłoka uruchomiona przez serwer WWW.

    Gdzie ćwiczysz to w kursieWstrzyknięcie poleceń systemowychWSTG-INPV-12
    Rozdział i otwarcie

    Rozdział 07 · Dane wejściowe i wstrzyknięcia

Rozdziały 01 i 02 otwierają się w pierwszych dwóch tygodniach edycji. Odblokowany rozdział już się nie zamyka.

Zobacz wszystkie 132 laboratoria

Przebieg laboratorium

Cztery dni w dziewięciu fazach.

Wtorek wieczorem: zapowiedź. Środa: inwentaryzacja, logi, izolacja, poprawka i dowód. Czwartek: restart, który cofnął poprawkę. Piątek: trzecia luka i zamknięcie incydentu.

W laboratorium wcielasz się w osobę z dyżuru w fikcyjnej organizacji; „my” w narracji oznacza jej zespół. Nic nie wpisujesz: kroki same uruchamiają polecenia, a tutor wskazuje, gdzie patrzeć.

  1. Przeczytaj ostrzeżenie, zanim wyjdą poprawki

    php.net zapowiada poprawki dwóch krytycznych luk, jeszcze bez szczegółów. Powstaje plan: inwentaryzacja, ekspozycja, rozwiązania doraźne, poprawka i dowód.

  2. Zidentyfikuj własny host z zewnątrz i od środka

    Nagłówki i skan z zewnątrz, wersja i moduł PHP od środka. Druga nazwa hosta prowadzi do tej samej aplikacji.

  3. Czy to konfiguracja, w której zademonstrowano atak?

    Biuletyny są już publiczne. Skrypt porównujący numery wersji daje właściwy werdykt z niewłaściwego powodu, a na drodze żądania nic nie filtruje ruchu przed serwerem.

Pokaż pozostałe 6 faz

  1. Jak atak wyglądał od środka

    Dziennik błędów i dziennik dostępu na jednym zegarze: awarie procesów serwera i seria odpowiedzi 500 z jednego adresu. Werdykt: ekspozycja potwierdzona, przejęcia nie wykluczono.

  2. Sprawdzenie przejęcia i próby kontrolne; zweryfikowany zrzut

    Trzy sprawdzenia śladów, każde z próbą kontrolną, która mogłaby wypaść inaczej, i to, co wolno z nich wywnioskować. Przed jakąkolwiek zmianą: zrzut bazy, sprawdzony, zanim się na nim polega.

  3. Offline i rozwiązanie doraźne, które tu nic nie kosztuje

    Serwis zostaje wyłączony, a koszt tej decyzji jest nazwany wprost. Ustawienie zalecane przez php.net zamyka jedną ścieżkę ataku, ale nie usuwa podatności.

  4. 0 upgraded: obraz nie ma bazy pakietów

    Menedżer pakietów nie ma czego zaktualizować. Poprawka trafia do kontenera z podpisanych pakietów dystrybucji — i trzeba wiedzieć, gdzie dokładnie zostaje.

  5. Udowodnij poprawkę kompilacją, którą ładuje serwer, a nie banerem

    Baner nadal pokazuje PHP/8.3.6. Rozstrzyga data kompilacji, plik modułu ładowany przez serwer WWW i sprawdzenie, które może wypaść w obie strony.

  6. Restart, który cofnął poprawkę; uzupełnienie z 23 października

    Restart z panelu dostawcy tworzy kontener od nowa i wraca stara kompilacja. Potem ponowna poprawka, trzecia luka w piątek i siedem wniosków.

Wnioski na kolejny incydent

Siedem zasad, które działają nie tylko przy tej luce.

  1. Uwzględnij w inwentaryzacji każdą nazwę hosta, nie tylko tę publiczną.
  2. Ekspozycja nie oznacza przejęcia: zapisz, co potwierdzono, a czego nie wykluczono.
  3. Sprawdzenie, które daje ten sam wynik niezależnie od stanu serwera, niczego nie dowodzi.
  4. Zanim cokolwiek zmienisz, wykonaj i zweryfikuj zrzut bazy.
  5. Rozwiązanie doraźne zamyka jedną ścieżkę ataku. Dopiero aktualizacja usuwa podatność.
  6. Udowodnij poprawkę kompilacją, którą serwer faktycznie ładuje, a nie banerem z wersją.
  7. Niektóre restarty tworzą kontener od nowa, więc po każdym restarcie sprawdzaj kompilację.

Studium przypadku: PHP2Shell

Lista kontrolna do pobrania

Czy serwer ładuje poprawione PHP? Osiem sprawdzeń.

Lista streszcza metodę z przypadku. Nie zastępuje zaleceń producenta ani dostawcy hostingu i nie jest instrukcją testowania cudzych systemów.

To materiał edukacyjny, a nie instrukcja dla Twojego serwera: każdą zmianę najpierw sprawdź w środowisku testowym, z aktualną kopią zapasową, i wprowadzaj ją na własną odpowiedzialność.

  1. Zanim cokolwiek zmienisz, wykonaj i zweryfikuj zrzut bazy. Przechowuj go poza katalogiem aplikacji.
  2. Uwzględnij w inwentaryzacji każdą nazwę hosta, pod którą odpowiada serwer, nie tylko adres publiczny.
  3. Nie oceniaj poprawki po banerze X-Powered-By ani po numerze wersji. Niektóre dystrybucje dodają poprawki bez zmiany numeru: Ubuntu 24.04 pokazuje 8.3.6 przed łatką i po niej.
  4. Porównaj datę kompilacji z php -v i z pola Build Date w phpinfo z datą poprawki w changelogu pakietu dystrybucji.
  5. Sprawdź plik modułu PHP, który ładuje serwer WWW. Wiersz poleceń i serwer WWW mogą używać innych kompilacji.
  6. phpinfo uruchamiaj tylko na stronie niedostępnej publicznie i usuń ją po sprawdzeniu.
  7. Sprawdzenie, które daje ten sam wynik niezależnie od stanu serwera, niczego nie dowodzi. Skrypt sprawdzający musi umieć zwrócić „bez poprawki” i „z poprawką”, a gdy dane nie pozwalają rozstrzygnąć, „nie da się stwierdzić”.
  8. Po każdym restarcie z panelu dostawcy i po każdej aktualizacji obrazu sprawdź kompilację ponownie. Niektóre restarty tworzą kontener od nowa.

php.net zaleca ustawienie session.upload_progress.enabled = 0 do następnego regularnego wydania PHP, także po aktualizacji z 21 października. Zamyka ono jedną ścieżkę ataku; dopiero aktualizacja usuwa podatność.

Zobacz cały incydent w bezpłatnym laboratorium z lektorem (w przeglądarce, bez zapisu): cyberszkola.pl/php2shell

Stan faktów:

Pobierz listę kontrolną (PDF)

Dwie strony A4: lista z kodem QR do bezpłatnego laboratorium i wykaz źródeł.

Źródła

  1. PHP security advisory GHSA-w8hw-w9fx-j79w — CVE-2026-109618, RCE via OOM corruption
  2. PHP security advisory GHSA-6wmf-4rv5-p3rp — CVE-2026-109619, RCE via stale global state
  3. php.net — advance notice of 20 October 2026
  4. php.net — informational advisory: session upload progress (23 October 2026, CVE-2026-115560)
  5. CERT-EU Security Advisory 2026-018 — Critical Vulnerabilities in PHP (v1.2)
  6. Ubuntu Security — CVE-2026-109618 (package table, USN-8948-1/2)
  7. Launchpad — php8.3 8.3.6-0ubuntu0.24.04.13 (changelog: SECURITY UPDATE, CVE-2026-109618/109619)
  8. Tenable — php2shell FAQ (updated 28 October 2026)
  9. Datadog Security Labs — PHP2Shell: what the logs and processes show (updated 23 October 2026)
  10. Varonis — PHP2Shell: the log pattern to hunt for
  11. NCSC-NL — third-party software that embeds PHP (inventory aid, referenced by CERT-EU)
  12. CISA — Known Exploited Vulnerabilities Catalog
  13. OWASP WSTG-CONF-01: Test Network Infrastructure Configuration
  14. OWASP WSTG-INFO-02: Fingerprint Web Server
  15. OWASP WSTG-INFO-08: Fingerprint Web Application Framework
Plakat laboratorium SQL injection z kursu Web Security PRO: sklep ShopMart

Laboratorium z kursu

Zobacz pełne laboratorium z kursu Web Security PRO: SQL injection

Od parametru w adresie produktu do danych z bazy i ponownego testu po poprawce. Bez zapisu, w przeglądarce.

Otwórz demo na stronie kursu

Pierwsza edycja

Następny krok: ćwicz to samodzielnie.

Start 16 listopada 2026 · 13 tygodni, nowy rozdział co poniedziałek · dostęp na 365 dni · konsumenci: 14 dni na zwrot bez podawania przyczyny

  • 132 laboratoria techniczne: tematy WSTG i autorskie rozszerzenia.
  • Dostęp przez 365 dni od zakupu, bez automatycznego odnawiania.
  • Interaktywne prowadzenie z tutorem, narracją i narzędziami w przeglądarce. Bez instalacji Dockera, VPN ani własnego laboratorium.
  • Certyfikat ukończenia w języku angielskim, z kodem weryfikacyjnym.
  • Po polsku i po angielsku.

Osoby z listy dostaną informację o zapisach i pełną ofertę, zanim zapisy zostaną otwarte publicznie.

Laboratorium PHP2Shell jest bezpłatne i działa bez zapisu. Formularz zapisu dotyczy wyłącznie listy oczekujących Web Security PRO.

Web Security PRO

Dołącz do listy oczekujących

Masz pytanie? Napisz do mnie

Możesz wycofać zgodę w każdej chwili. Zapis dotyczy wybranego szkolenia — nie dopiszemy Cię automatycznie do list pozostałych kursów.

Dla zespołów

Omówcie ten przypadek w zespole.

Link do tej strony możesz przesłać dalej albo uruchomić laboratorium na spotkaniu zespołu. Siedem wniosków i lista kontrolna są gotowe do wydruku.

Web Security PRO dla firm: licencje dla zespołu, faktura VAT i bezpłatny pilotaż przed zakupem licencji.

Zapytaj o wycenę

Źródła i stan faktów

Publiczne fakty, fikcyjna organizacja.

Stan faktów:

Publiczny przebieg zdarzeń pochodzi z biuletynów i komunikatów poniżej. Organizacja, jej dostawca, serwery, adresy, logi i liczby w laboratorium są fikcyjne; adresy IP pochodzą z zakresów przeznaczonych do dokumentacji. Laboratorium cytuje 21 publicznych źródeł.

Oś czasu i źródła
  1. 20.10.2026 — php.net zapowiada poprawki dwóch krytycznych luk (CVSS 9,2).
  2. 21.10.2026 — wydania 8.5.12, 8.4.27, 8.3.36 i 8.2.35 oraz dwa biuletyny GitHub; Ubuntu publikuje poprawioną kompilację, zachowując numer 8.3.6.
  3. 23.10.2026 — php.net informuje o trzeciej luce (CVE-2026-115560), poprawianej w zwykłym cyklu, i zaleca pozostawić ustawienie doraźne.
  4. 26.10.2026 — CISA dodaje CVE-2026-109618 i CVE-2026-109619 do katalogu KEV.

Pytania

Warto wiedzieć.

Czy to prawdziwy incydent?

Luki CVE-2026-109618 i CVE-2026-109619 oraz publiczny przebieg zdarzeń są prawdziwe i opisane w źródłach. Bramblewood Academy, Harbourline Cloud, ich serwery, adresy, logi i liczby w laboratorium są fikcyjne.

Czy laboratorium pokazuje, jak przeprowadzić atak?

Nie. Pokazuje to, co obrońca widzi w logach, procesach i konfiguracji serwera, i jak ocenić ekspozycję. Nie zawiera żądań, ładunków ani narzędzi, które pozwoliłyby wywołać lukę.

Czy mogę użyć poleceń z laboratorium na swoim serwerze?

Nie przenoś ich 1:1. Polecenia, które tylko odczytują dane, na przykład wersję PHP, nagłówki odpowiedzi czy logi, zwykle niczego nie zmieniają. Te, które przełączają kontekst Dockera, zatrzymują kontener, zmieniają php.ini albo podmieniają pliki PHP, są napisane dla fikcyjnego serwera z laboratorium i na produkcji mogą wyłączyć usługę. Postępuj według zaleceń producenta i dostawcy, każdą zmianę najpierw sprawdź w środowisku testowym, z aktualną kopią zapasową, i wprowadzaj ją na własną odpowiedzialność.

Czy muszę się zapisać albo założyć konto?

Nie. Laboratorium jest bezpłatne i działa w przeglądarce, bez konta i bez podawania adresu e-mail. Formularze na tej stronie dotyczą wyłącznie listy oczekujących Web Security PRO i są dobrowolne.

Ile to trwa i czym różnią się tryby?

Pokaz trwa ok. 22 minut i prowadzi sam, jak film z narracją. W trybie Z tutorem przechodzisz krok po kroku przyciskami Dalej i Wstecz, we własnym tempie. Tekst narracji jest na ekranie, więc laboratorium działa też bez dźwięku.

Na czym je uruchomić?

Na komputerze z ekranem co najmniej 1280 × 720, w aktualnej przeglądarce. Po uruchomieniu laboratorium pobiera ok. 27 MB danych. Na telefonie przeczytasz opis i wnioski, a link wyślesz sobie na komputer.

Dlaczego laboratorium zamyka się po otwarciu narzędzi deweloperskich?

To ochrona treści, taka sama jak w pozostałych demo na cyberszkola.pl. Zamknij narzędzia deweloperskie i kliknij „Wróć do laboratorium”; w trybie Z tutorem pasek „Rozdziały” pozwala przejść do wybranego rozdziału.

Jak ten przypadek ma się do Web Security PRO?

To osobne, bezpłatne laboratorium, poza 132 laboratoriami kursu, zbudowane w tym samym środowisku. W Web Security PRO tę samą metodę — rozpoznanie, dowód i ponowne sprawdzenie poprawki — ćwiczysz samodzielnie, od strony testu aplikacji. Kurs nie uczy łatania obrazów kontenerów ani prowadzenia reakcji na incydent.

Jacek Wlodarczyk

Autor projektu

Jacek Wlodarczyk

Twórca projektów Cyberwiedza, cyberszkola i AI SecLabs. W tych szkoleniach łączę wyjaśnienie mechanizmu z ćwiczeniem, obserwacją i decyzją, którą trzeba umieć uzasadnić.

Nie wystarczy uruchomić polecenie. Ważne jest, co jego wynik potwierdza, czego nie potwierdza i jaki powinien być następny krok.

Więcej o autorze