Krótko: Przy luce w PHP takiej jak PHP2Shell za aktualizację PHP w hostingu odpowiada hoster, nie Państwo. Państwa zadaniem jest uzyskać pisemne potwierdzenie, wybrać w panelu klienta obsługiwaną wersję PHP i sprawdzić stronę pod kątem śladów ataku. Poprawka hostera nie usuwa szkodliwego oprogramowania, które wcześniej trafiło na Państwa stronę.
Sytuacja prostymi słowami
PHP to język programowania, na którym działa większość stron, sklepów i systemów CMS, takich jak WordPress. PHP2Shell oznacza dwa krytyczne błędy w samym PHP (CVE-2026-109618 i CVE-2026-109619). Atakujący mogą dzięki nim wykonać własny kod na serwerze bez hasła. BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) ogłosiło stopień ostrzeżenia 3 (pomarańczowy) i zaleca natychmiastową aktualizację.
Przy hostingu współdzielonym wielu klientów dzieli jeden serwer. Technikę pod spodem, czyli system operacyjny, serwer WWW i PHP, utrzymuje hoster. Państwo zarządzają tylko swoją stroną, bazą danych i dostępami. Dlatego nie mogą Państwo samodzielnie zainstalować aktualizacji PHP i nie muszą.
Hosting WWW a luka w PHP: kto jest odpowiedzialny?
Podział wynika z Państwa umowy. W większości taryf obowiązuje z grubsza następujący rozkład:
| Zadanie | Hoster | Państwo jako klient |
|---|---|---|
| Aktualizacja pakietów PHP | tak | nie |
| Restart procesów PHP | tak | nie |
| Ustawienie ogólnoserwerowych wartości przejściowych | tak | nie |
| Wybór wersji PHP dla strony | udostępnia | wybiera |
| Aktualizacja CMS, wtyczek, motywów | nie | tak |
| Dane dostępowe i konta administratorów | nie | tak |
| Sprawdzenie strony pod kątem szkodliwego kodu | częściowo | tak |
| Ocena z punktu widzenia ochrony danych | nie | tak |
Ważny jest ostatni wiersz: jeśli na Państwa stronie dojdzie do incydentu z danymi osobowymi, za to zwykle odpowiadają Państwo jako operator, a nie hoster. Więcej na ten temat w artykule Obowiązek zgłoszenia naruszenia RODO.
Co powinni Państwo zrobić teraz sami
1. Uzyskać potwierdzenie. Proszę zapytać hostera pisemnie, czy wersje PHP w Państwa pakiecie są zabezpieczone przed obydwoma CVE, od kiedy i czy wszystkie procesy PHP zostały zrestartowane. Gotowy wzór znajdą Państwo w artykule Jak zapytać hostera o stan poprawek. Nie powinno dziwić, jeśli w panelu klienta nadal widnieje starszy numer wersji, na przykład 8.2.34: niektórzy dostawcy dostarczają poprawki jako backport, bez zmiany numeru.
2. Sprawdzić wersję PHP. Proszę zajrzeć w panelu klienta, jakiej wersji PHP używa Państwa strona. PHP 8.1 i starsze nie otrzymują od projektu PHP oficjalnych aktualizacji. PHP 8.2 kończy wsparcie 31.12.2026. Czy Państwa CMS znosi nowszą wersję, sprawdzają Państwo według wymagań systemowych producenta, na przykład na wordpress.org.
3. Skontrolować stronę. Proszę zwrócić uwagę na nieznane konta administratorów, nieoczekiwane przekierowania, obce pliki na dostępie FTP i ostrzeżenia w Google Search Console. Listę typowych oznak podaje artykuł Czy już doszło do włamania?.
4. Wykonać kopię zapasową. Proszę pobrać aktualną kopię plików i bazy danych i przechowywać ją osobno. Dodatkowo proszę poprosić hostera o zachowanie logów dostępu do Państwa pakietu od 20.10.2026.
Po potwierdzeniu od hostera proszę prewencyjnie zmienić hasła do panelu klienta, FTP/SFTP, bazy danych i administratorów CMS oraz, gdzie to możliwe, włączyć uwierzytelnianie dwuskładnikowe.
Czego przy hostingu współdzielonym nie rozwiążą Państwo sami
Środki przejściowe zalecane przez php.net, na przykład session.upload_progress.enabled=0, działają tylko wtedy, gdy zostaną ustawione w konfiguracji serwera. Wpis w .user.ini lub przez ini_set() w kodzie według php.net nie wystarcza. Także ograniczenia pamięci na poziomie cgroup i restart procesów PHP leżą po stronie hostera.
Jeśli hoster nie odpowiada albo odpowiada wymijająco, mają Państwo trzy możliwości: ponaglić i wyznaczyć termin, tymczasowo przełączyć stronę w tryb konserwacji albo przejść do dostawcy, który udziela jasnej odpowiedzi. BSI zaleca czasowe odłączenie serwerów WWW od sieci, jeśli aktualizacja nie jest możliwa od razu.
Proszę sprawdzić także, czy Państwa taryfa jest jeszcze aktualna. Pakiety działające od wielu lat bez zmian leżą czasem na starszych generacjach serwerów ze starszymi wersjami PHP, które hoster utrzymuje już tylko w ograniczonym zakresie. Zmiana na aktualną taryfę tego samego dostawcy jest często mało pracochłonna i zapewnia nowsze wersje PHP. Proszę o to zapytać, jeśli odpowiedź na temat stanu poprawek jest niezadowalająca.
Gdy strona jest już podejrzana
Poprawka u hostera zamyka lukę na przyszłość. Nie usuwa jednak tylnych drzwi, które atakujący zainstalowali wcześniej, i nie dowodzi, że wcześniej nic się nie stało. Jeśli znajdą Państwo nieprawidłowości, nie należy usuwać plików na chybił trafił. Najpierw proszę zabezpieczyć stan systemu, aby przyczynę dało się później odtworzyć.
Jak konkretnie pomaga PHP SOS?
- Formułujemy z Państwem zapytanie do hostera i technicznie oceniamy jego odpowiedź.
- Sprawdzamy Państwa stronę pod kątem webshelli, obcych kont i zmanipulowanych plików, a w razie ustaleń czyścimy ją w ramach naszego usuwania malware.
- Przy ostrym podejrzeniu przejmujemy pomoc awaryjną dla zhakowanych stron wraz z zabezpieczeniem dowodów.
- Pomagamy w wyborze odpowiedniej wersji PHP i potem testujemy stronę.
Częste pytania
Czy jako klient hostingu muszę sam aktualizować PHP?
Zwykle nie, ponieważ przy hostingu współdzielonym PHP należy do platformy hostera. Często mogą Państwo jednak wybrać wersję PHP w panelu klienta. Jeśli widnieje tam wersja bez oficjalnych aktualizacji, powinni Państwo ją zmienić albo zapytać hostera, jak ją zabezpiecza.
Moja strona jest offline. Czy zostałem zhakowany?
Niekoniecznie. Niektórzy dostawcy prewencyjnie wyłączyli strony z sieci, aby zamknąć lukę. Proszę zapytać hostera o powód i poprosić o potwierdzenie, czy są przesłanki ataku na Państwa pakiet.
Czy mogę sam ustawić środki przejściowe w .user.ini?
Dla session.upload_progress.enabled php.net wyraźnie wskazuje, że .user.ini i ini_set() nie wystarczą. To ustawienie musi wprowadzić hoster w konfiguracji serwera.
Co powinienem mieć na piśmie od hostera?
Potwierdzenie, że wersje PHP w Państwa pakiecie są zabezpieczone przed CVE-2026-109618 i CVE-2026-109619, od kiedy to obowiązuje i że procesy PHP zostały zrestartowane. Proszę przechowywać tę odpowiedź razem z pozostałą dokumentacją.