Krótko: Oś czasu PHP2Shell obejmuje dotąd cztery potwierdzone daty: pierwszą zaobserwowaną próbę ataku 17.10., wcześniejszą zapowiedź na php.net 20.10., poprawki 21.10. o 16:00 czasu niemieckiego oraz kolejny komunikat o CVE-2026-115560 z 23.10.2026. Dla administratorów wynika z tego: załatać, zrestartować wszystkie procesy PHP i zabezpieczyć logi najpóźniej od 20.10.
Dlaczego oś czasu PHP2Shell jest ważna dla administratorów
Przy luce o tej wadze liczy się nie tylko to, czy Państwa serwer jest dziś załatany. Decyduje także, jak długo był wcześniej podatny. To okno czasowe wyznacza, które logi zabezpieczyć, które pliki sprawdzić i czy można z dobrym uzasadnieniem wykluczyć kompromitację.
PHP2Shell dotyczy samego PHP, a nie pojedynczego systemu CMS. Dwie krytyczne luki, CVE-2026-109618 i CVE-2026-109619, umożliwiają zdalne wykonanie złośliwego kodu bez logowania. Obie mają ocenę CVSS v4.0 9,2. Zrozumiałe wprowadzenie znajdą Państwo na stronie Czym jest PHP2Shell?.
Poniższa chronologia zawiera wyłącznie daty potwierdzone na dzień 25.10.2026. Tam, gdzie informacja opiera się na doniesieniach medialnych, jest to zaznaczone.
| Data | Zdarzenie | Podstawa |
|---|---|---|
| 17.10.2026 | Pierwsza zaobserwowana próba ataku (Amazon) | doniesienia medialne |
| 20.10.2026 | Zapowiedź na php.net | php.net |
| 21.10.2026, 14:00 UTC | Publikacja poprawek (16:00 czasu niemieckiego) | php.net |
| 23.10.2026 | Komunikat o CVE-2026-115560 | php.net |
| 25.10.2026 | Stan tego zestawienia | – |
17 października: pierwsza zaobserwowana próba ataku
Według doniesień medialnych 17.10.2026 zaobserwowano pierwszą próbę ataku, zgłoszoną przez Amazon. Było to cztery dni przed poprawkami. Istniał więc okres, w którym próbowano już ataków, a aktualizacja jeszcze nie istniała.
Czy i ile ataków w tej fazie zakończyło się powodzeniem, nie jest potwierdzone. Ważny jest wniosek dla Państwa własnej kontroli: serwer załatany dzisiaj mógł zostać skompromitowany wcześniej. Poprawka nie usuwa wprowadzonego złośliwego oprogramowania i nie dowodzi, że wcześniej nic się nie stało.
20 i 21 października: zapowiedź i poprawki
20.10.2026 projekt PHP zapowiedział aktualizacje bezpieczeństwa na php.net. 21.10.2026 o godz. 14:00 UTC, czyli o 16:00 czasu niemieckiego, pojawiły się poprawione wersje.
| Gałąź | Ostatni podatny stan | Naprawione w |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
Dla PHP 8.1 i starszego nie ma już oficjalnych aktualizacji, jedynie minimalne backporty kodu źródłowego dla 7.4, 8.0 i 8.1. Według prasy branżowej dotknięte są niemal wszystkie wersje aż do PHP 5.4. Dotyczy to trybów pracy PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko widzi zespół PHP w przypadku mod_php, gdzie pokazano exploit, zanim w ogóle zacznie działać kod aplikacji.
Dystrybucje i dostawcy hostingu częściowo przenoszą poprawki jako backporty. Wtedy na przykład Plesk nadal pokazuje 8.2.34, choć serwer jest załatany. Rozstrzygający jest stan pakietu i potwierdzenie dostawcy, a nie wyświetlany numer wersji. Jak to rzetelnie sprawdzić, opisuje strona Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
23 października: komunikat o CVE-2026-115560
23.10.2026 projekt PHP opublikował kolejny komunikat, tym razem o CVE-2026-115560. Wykorzystanie jest według niego możliwe tylko przy nietypowej konfiguracji: w konfiguracji ustawiony jest serialize_handler php_binary lub php_serialize, aplikacja przełącza go przed session_start() przez ini_set() na php, a postęp przesyłania sesji (session upload progress) jest aktywny.
Środek zaradczy jest prosty i warto go ustawić niezależnie od tego, czy znają Państwo u siebie taką konstelację:
; w php.ini, w puli FPM lub w konfiguracji serwera
; nie przez ini_set() ani .user.ini
session.upload_progress.enabled = 0
Następnie zrestartować wszystkie procesy robocze PHP. Pełny komunikat ma pojawić się przy następnym regularnym wydaniu z poprawkami błędów. Do tego czasu to ustawienie pozostaje zalecanym rozwiązaniem przejściowym.
Stan na 25 października: sytuacja i otwarte pytania
BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) ogłosił poziom ostrzeżenia 3 / pomarańczowy. Zaleca natychmiastową aktualizację, a jeśli nie jest ona możliwa od razu, tymczasowe odłączenie serwerów WWW od sieci. BSI spodziewał się szybkiego, szeroko zakrojonego wykorzystania luki; potwierdzone udane ataki na szeroką skalę nie były według BSI początkowo znane. Ocenę BSI podsumowuje strona Co BSI zaleca w sprawie PHP2Shell.
Cloudflare zgłosił zaobserwowane próby ataków i wdrożył reguły ochronne, ostrzega jednak, że same reguły oparte na danych żądania nie wystarczą. Palo Alto Networks (Unit 42) naliczył ponad 22,6 miliona wystawionych, potencjalnie podatnych instancji. Potwierdzone wskaźniki naruszenia nie zostały opublikowane; wykrywanie opiera się na analizie zachowania.
Niektórzy dostawcy zapobiegawczo wyłączyli strony internetowe. Nie oznacza to automatycznie, że te strony zostały zhakowane. Na dzień tego zestawienia otwarte pozostaje przede wszystkim, ile serwerów zostało faktycznie skompromitowanych w czasie przed poprawką.
Co oś czasu oznacza dla Państwa logów i kontroli
Z tych dat wynikają trzy okresy: przed 17.10., między 17.10. a Państwa własnym momentem załatania i restartu oraz po nim. Okres środkowy jest krytyczny. Im dłużej trwał u Państwa, tym dokładniejsza powinna być kontrola.
Prasa branżowa radzi przechowywać logi serwera od 20.10.2026. Proszę zabezpieczyć także istniejące starsze logi, zanim usunie je automatyczna rotacja.
Prosty sposób na niezmienione zabezpieczenie logów i odnotowanie stanu:
# Zabezpiecz logi zbiorczo (dostosuj ścieżki do swojego systemu)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Suma kontrolna jako późniejszy dowód
sha256sum /root/logs-sicherung-*.tar.gz
# Jak długo system przechowuje logi?
grep -R "rotate" /etc/logrotate.d/
Proszę dodatkowo zanotować, kiedy dokładnie zainstalowano aktualizację i kiedy zrestartowano procesy PHP. Nowe pliki same nie chronią, dopóki w pamięci działają stare procesy. Jak analizować zabezpieczone logi, opisuje poradnik Analiza logów serwera WWW po ataku.
Jak konkretnie pomaga PHP SOS?
- Ustalamy z Państwem rzeczywiste okno podatności Państwa serwera: stan pakietów, moment załatania, restart wszystkich procesów roboczych.
- Zabezpieczamy logi i stan systemu w sposób możliwy do prześledzenia, zanim cokolwiek zostanie zmienione.
- Sprawdzamy nietypowe zachowania, takie jak nowe pliki PHP, obce procesy i nietypowe połączenia wychodzące.
- Dokumentujemy wynik tak, aby mogli z nim pracować zarząd, inspektorzy ochrony danych i ubezpieczyciele.
Przebieg poszczególnych kroków opisuje nasza pomoc natychmiastowa przy PHP2Shell.
Częste pytania
Kiedy opublikowano poprawki PHP2Shell?
Projekt PHP opublikował poprawione wersje 21.10.2026 o godz. 14:00 UTC, czyli o 16:00 czasu niemieckiego. Naprawione są PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.
Od jakiej daty powinienem przechowywać logi serwera?
Prasa branżowa radzi przechowywać logi od 20.10.2026. Ponieważ według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17.10., warto zabezpieczyć także istniejące starsze logi, zanim usunie je rotacja.
Czy CVE-2026-115560 jest tak samo niebezpieczne jak dwie pierwsze luki?
Według komunikatu z 23.10.2026 wykorzystanie jest możliwe tylko przy nietypowej konfiguracji sesji. Jako środek zaradczy zaleca się session.upload_progress.enabled=0 do czasu kolejnego regularnego wydania z poprawkami błędów.
Czy są potwierdzone wskaźniki naruszenia (IoC) dotyczące PHP2Shell?
Nie, na dzień 25.10.2026 nie opublikowano potwierdzonych wskaźników naruszenia (Indicators of Compromise). Wykrywanie opiera się na analizie zachowania, na przykład nietypowych procesach, nowych plikach i podejrzanych połączeniach.