Krótko: Po PHP2Shell sama wyświetlana wersja PHP niewiele dowodzi, ponieważ hostingi często wprowadzają poprawki jako backport. Proszę więc zażądać pisemnego potwierdzenia aktualizacji PHP od hostingu: stanu pakietu dla każdej gałęzi PHP, momentu instalacji i restartu wszystkich procesów PHP. Wzór do skopiowania znajdą Państwo poniżej.
Dlaczego pisemne potwierdzenie liczy się właśnie teraz
21.10.2026 projekt PHP opublikował poprawki dla dwóch krytycznych luk znanych pod nazwą PHP2Shell. Obie umożliwiają zdalne wykonanie złośliwego kodu bez logowania. BSI ogłosił poziom ostrzeżenia 3 / pomarańczowy i zaleca natychmiastową aktualizację.
Kto prowadzi stronę u dostawcy hostingu, często nie może sam wprowadzić aktualizacji. Jednocześnie jako operator ponoszą Państwo odpowiedzialność za dane swoich klientów. Pisemne, konkretne potwierdzenie od hostingu jest więc czymś więcej niż formalnością. Jest elementem Państwa dokumentacji, na przykład wobec inspektorów ochrony danych, ubezpieczycieli czy zarządu.
Dochodzi do tego, że poprawka nie usuwa złośliwego oprogramowania wprowadzonego wcześniej. Według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17.10. Dokładny moment, od którego serwer był chroniony, jest więc ważny dla oceny, czy trzeba sprawdzać dalej.
Dlaczego wyświetlana wersja PHP nie wystarcza
Naprawione są PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Wiele dystrybucji i hostingów przejmuje jednak poprawkę jako backport do własnego pakietu. Wtedy interfejs taki jak Plesk nadal pokazuje 8.2.34, mimo że serwer jest załatany.
Odwrotnie, prawidłowy numer wersji może wprowadzać w błąd. Same nowe pliki nie chronią, dopóki w pamięci działają stare procesy PHP. Dopiero po restarcie wszystkich procesów roboczych nowy stan jest aktywny. Więcej w artykule Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
| Wypowiedź hostingu | Co ona potwierdza | Czego jeszcze brakuje |
|---|---|---|
| „Wszystkie systemy są aktualne.” | niewiele | wersja lub stan pakietu, data, restart |
| „PHP 8.3.36 jest zainstalowane.” | wersję | data, restart, dotknięte serwery |
| „Backport w pakiecie xy, restart dnia …” | poprawkę i jej aktywację | w razie potrzeby informacje o PHP 8.1 i starszym |
Jakie dane są potrzebne od hostingu
Proszę prosić o odpowiedzi na te punkty, jeśli to możliwe dla każdej strony lub umowy:
- Które gałęzie i wersje PHP są aktywne dla Państwa stron, także starsze, działające tylko dla pojedynczych katalogów?
- Czy poprawki dla CVE-2026-109618 i CVE-2026-109619 są zawarte, jako oficjalna wersja lub jako backport?
- Kiedy zainstalowano aktualizację i kiedy zrestartowano wszystkie procesy PHP (pule FPM, Apache, LiteSpeed)?
- Czy
session.upload_progress.enabledjest wyłączone ze względu na CVE-2026-115560? - Jaki tryb pracy stosuje Państwa taryfa, na przykład PHP-FPM lub Apache z mod_php? W przypadku mod_php zespół PHP widzi najwyższe ryzyko.
- Jakie logi dostępu i błędów od 20.10.2026 są przechowywane i jak mogą je Państwo otrzymać?
Jeśli jakaś strona działa jeszcze na PHP 8.1 lub starszym, proszę zapytać o to osobno. Dla tych gałęzi nie ma już oficjalnych aktualizacji, a jedynie minimalne backporty kodu źródłowego dla 7.4, 8.0 i 8.1.
Wzór: zażądać od hostingu potwierdzenia aktualizacji PHP
Proszę skopiować tekst do zgłoszenia do wsparcia lub e-maila do hostingu. Dane w nawiasach kwadratowych należy uzupełnić.
Temat: Prośba o potwierdzenie stanu poprawek PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Szanowni Państwo,
prowadzimy u Państwa następujące strony / umowy:
[Numer klienta, umowa, domeny]
W związku z lukami bezpieczeństwa PHP CVE-2026-109618 i
CVE-2026-109619 (PHP2Shell, poprawki z 21.10.2026) oraz informacją
o CVE-2026-115560 z 23.10.2026 prosimy o pisemne
potwierdzenie następujących punktów:
1. Jakie wersje PHP lub stany pakietów są aktywne dla naszych stron?
2. Czy zawierają one poprawki (oficjalna wersja lub backport)?
3. Data i godzina instalacji.
4. Data i godzina restartu wszystkich procesów PHP (FPM, Apache,
LiteSpeed itp.).
5. Czy session.upload_progress.enabled jest wyłączone po stronie serwera?
6. Jaki tryb pracy PHP jest używany (np. PHP-FPM, mod_php)?
7. Czy logi dostępu i błędów od 20.10.2026 są przechowywane i
jak możemy je otrzymać?
8. Jeśli jakaś strona nadal używa PHP 8.1 lub starszego: jakie zabezpieczenie
tam obowiązuje i jaką migrację Państwo zalecają?
Te informacje są nam potrzebne do wewnętrznej dokumentacji.
Dziękujemy i pozdrawiamy
[Imię i nazwisko, firma, stanowisko]
Jak ocenić odpowiedź i samodzielnie ją zweryfikować
Dobra odpowiedź podaje konkretne stany, daty i godziny. Ogólne sformułowania, takie jak „zareagowaliśmy”, nie wystarczą do Państwa akt. W takim przypadku proszę uprzejmie dopytać o brakujące punkty.
Jeśli taryfa na to pozwala, proszę dodatkowo sprawdzić samodzielnie. Z dostępem SSH zwykle wystarczą te polecenia:
# Wersja z wiersza poleceń (może się różnić od wersji webowej)
php -v
# Stan pakietu w Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Stan pakietu w RHEL, Alma, Rocky
rpm -qa | grep -i php
# Od kiedy działają procesy PHP-FPM?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Jeśli moment uruchomienia procesów PHP jest wcześniejszy niż potwierdzona data instalacji, restart nie był pełny.
Gdy hosting nie odpowiada lub odpowiada wymijająco
Jeśli odpowiedzi brak lub brakuje decydujących danych, nie powinni Państwo uznawać sprawy za wyjaśnioną. BSI zaleca tymczasowe odłączenie serwerów WWW od sieci, jeśli aktualizacja nie jest możliwa od razu. Czy jest to proporcjonalne dla Państwa strony, decyduje zarząd, najlepiej na piśmie i z datą.
Równolegle warto poszukać możliwych śladów ataku, ponieważ moment załatania pozostaje nieznany. Wskazówki podaje artykuł Czy już zostałem skompromitowany?. Bez dostępu SSH pisemne potwierdzenie pozostaje Państwa najważniejszym dowodem. Jakie obowiązki ma hosting, a jakie Państwo, wyjaśnia strona Shared hosting: co robi hosting; w przypadku serwerów z opieką pomoże Serwer zarządzany: wyjaśnienie odpowiedzialności.
Proszę zachować zapytanie, odpowiedź i własne wyniki kontroli z datami w jednym folderze. Takie akta pomogą później przy pytaniach ubezpieczycieli lub inspektorów ochrony danych.
Jak konkretnie pomaga PHP SOS?
- Formułujemy z Państwem zapytanie do hostingu i oceniamy odpowiedź pod względem merytorycznym.
- Tam, gdzie mamy dostęp, sami sprawdzamy stan pakietów, aktywny tryb pracy i restart procesów PHP.
- Jeśli pozostają luki, wdrażamy środki przejściowe lub planujemy przejście na wspieraną wersję.
- Wynik i momenty czasowe utrwalamy w dowodzie, który mogą Państwo przekazać wewnętrznie.
Jak przebiega aktualizacja z restartem i dowodem, opisuje nasza usługa łatania PHP.
Częste pytania
Czy wystarczy, że mój hosting napisze, że wszystko jest aktualne?
Dla Państwa dokumentacji raczej nie. Proszę prosić o konkretne dane: stan pakietu lub wersję dla każdej gałęzi PHP, datę instalacji i datę restartu wszystkich procesów PHP. Dopiero wtedy mogą Państwo zawęzić okno podatności.
Dlaczego panel mojego hostingu nadal pokazuje PHP 8.2.34?
Dystrybucje i dostawcy hostingu częściowo wprowadzają poprawki bezpieczeństwa jako backport, nie zmieniając numeru wersji. Plesk może wtedy nadal pokazywać 8.2.34, mimo że serwer jest załatany. Jasność daje tylko potwierdzenie dostawcy dotyczące stanu pakietu.
Co zrobić, jeśli hosting nie odpowiada?
Proszę udokumentować zapytanie z datą i po rozsądnym czasie zapytać ponownie. Równolegle proszę sprawdzić, czy mogą Państwo sami wprowadzić środki przejściowe, i uzgodnić z zarządem, czy strona ma zostać odłączona od sieci do czasu wyjaśnienia, tak jak BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) zaleca dla niezałatanych serwerów.
Czy aktualizacja WordPressa lub sklepu również zamyka tę lukę?
Nie. PHP2Shell tkwi w samym PHP. Aktualizacja systemu CMS lub oprogramowania sklepu nie zmienia niczego w interpreterze PHP działającym na serwerze.