Luka w PHP (PHP2Shell): czy jest się czego bać i jak sprawdzić swoją stronę

Cześć! 21 października wyszły na jaw dwie poważne luki w PHP, nazwane razem PHP2Shell. Holenderski parlament i kilka urzędów w Europie na wszelki wypadek wyłączyło swoje strony, a do nas przyszło sporo pytań: „Czy muszę coś klikać?”, „Czy WordPress jest jeszcze bezpieczny?”.

Zbieram wszystko w jednym miejscu: co się stało, czy masz się czym martwić, jak sprawdzić swoją stronę w 2 minuty i jak zrobić to samo z Claude’em.

Co się stało

Badacze znaleźli w PHP dwie luki, które pozwalały obcej osobie uruchomić polecenia na serwerze bez logowania. Szczegóły wyciekły do sieci, zanim twórcy PHP wydali poprawki. Pierwsze próby ataku ruszyły rano 21 października, a łatki pojawiły się dopiero o 16:00.

Najważniejsze: luka siedziała w PHP, czyli w silniku pod WordPressem, a nie w samym WordPressie. Dlatego aktualizacja wtyczek ani Wordfence nic tu nie dawały. Idealnie zaktualizowana strona bez ani jednej wtyczki była tak samo narażona. Poprawkę mógł wgrać tylko ten, kto zarządza serwerem, czyli hosting.

23 października doszła jeszcze trzecia luka z tej rodziny. Działa tylko przy bardzo nietypowych ustawieniach, więc dostanie poprawkę w zwykłym wydaniu PHP. Chroni przed nią ta sama zmiana, którą hostingi wprowadziły 21 października.

Kto pilnuje której części strony

Żeby zrozumieć, czemu przycisk „Aktualizuj” w kokpicie tym razem nie pomagał, wyobraź sobie stronę jak budynek z czterema warstwami:

• Fundamenty: serwer i PHP. PHP to silnik, na którym działa WordPress, WooCommerce i większość stron w internecie. O fundamenty dba hosting.
• Konstrukcja: WordPress. Kokpit, wpisy, użytkownicy. Aktualizujesz go Ty albo osoba, która opiekuje się stroną.
• Wyposażenie: wtyczki i motyw. Formularze, sklep, kursy, wygląd. Tutaj pojawia się najwięcej luk, dlatego aktualizacje wtyczek to codzienność.
• Klucze do drzwi: Ty. Hasła, konta administratorów, kopie zapasowe. Tego nikt za Ciebie nie zrobi.

PHP2Shell uderzył w fundamenty. Wtyczki bezpieczeństwa, takie jak Wordfence, chronią konstrukcję i wyposażenie, a atak na PHP dzieje się, zanim WordPress w ogóle się uruchomi.

Czy się bać?

Raczej nie. Większość dużych hostingów wgrała łatki jeszcze tej samej nocy. Gotowe programy do ataku, które krążyły w sieci, okazały się słabsze, niż straszyły nagłówki. Firma Sansec sprawdziła je i na zwykłej instalacji PHP nie działały, bo potrzebowały drugiej, osobnej dziury na stronie. Głośne doniesienie o włamaniu do europejskiej instytucji rządowej przez tę lukę badacze sami wycofali.

Dużo hałasu, a potwierdzonej fali włamań na razie brak. Sprawdzić i tak warto, bo to 2 minuty.

Co zrobiły polskie hostingi

Stan na 22 października, na podstawie publicznych komunikatów:

Hosting	Co ogłosił	Czy musisz coś zrobić
cyberFolks, Smarthost.pl, Zenbox, OVH, Hostinger	Łatki zainstalowane, także dla starszych wersji PHP	Nie
home.pl	Łatki na hostingu	Na własnym serwerze VPS aktualizujesz PHP samodzielnie
SeoHost, LH.pl, nazwa.pl	Publicznego komunikatu nie znaleźliśmy	Napisz do pomocy technicznej

Jak sprawdzić w kokpicie

1. W kokpicie WordPressa kliknij „Narzędzia”, potem „Stan witryny”.
2. Otwórz zakładkę „Informacje” i rozwiń sekcję „Serwer”.
3. Spójrz na wiersz „Wersja PHP”.

Co oznacza numer:

• ✅ 8.2.35, 8.3.36, 8.4.27, 8.5.12 albo wyżej: łatka jest.
• 🟡 Niższa wersja w seriach 8.2-8.5: zapytaj hosting. Część hostingów wszywa poprawkę w starszą wersję i numer zostaje ten sam.
• 🔴 7.4, 8.0 albo 8.1: czas na zmianę. Te wersje od dawna nie dostają żadnych poprawek.

Co zrobić

Hosting współdzielony. Jeśli Twój hosting nic nie ogłosił, wystarczy krótka wiadomość do pomocy technicznej:

Dzień dobry, czy na moim koncie są już zainstalowane poprawki luk PHP2Shell (CVE-2026-109618 i CVE-2026-109619)?

Własny serwer VPS. Tu nikt nie zrobi tego za Ciebie. Zaktualizuj PHP i wyłącz w ustawieniach PHP opcję session.upload_progress.

Stara wersja PHP (7.4, 8.0, 8.1). Najpierw zrób kopię zapasową. Potem przełącz wersję w panelu hostingu i przeklikaj stronę główną, logowanie, koszyk i formularze.

Po łatce. Najpierw łatka, potem zmiana haseł administratorów i kluczy płatności, w tej kolejności.

Sprawdź z Claude’em

Jeśli łączysz Claude Code z serwerem przez SSH (pokazuję to w lekcji o SSH w kursie Agenci AI w biznesie usługowym), możesz zlecić mu całe sprawdzenie. Wklej to polecenie:

Sprawdź moją stronę pod kątem luk PHP2Shell (CVE-2026-109618, CVE-2026-109619, CVE-2026-115560). Połącz się z serwerem przez SSH i tylko czytaj, niczego nie zmieniaj:
1. Jaka wersja PHP obsługuje stronę (php -v oraz wersja PHP-FPM)?
2. Czy session.upload_progress.enabled jest wyłączone?
3. Czy w logach PHP od 20.10 są błędy "Allowed memory size ... in Unknown on line 0" albo awarie procesów PHP?
4. Czy w wp-content/uploads leżą pliki .php i czy od 20.10 zmieniły się pliki PHP poza aktualizacjami wtyczek?
5. Czy pojawiły się nowe konta administratorów?
Na koniec napisz po polsku: czy jest łatka, czy widać ślady ataku i co mam zrobić.

Claude tylko czyta i na końcu mówi po ludzku, czy jest łatka i czy coś wygląda podejrzanie. Decyzję o zmianach zostawia Tobie.

Jak to wyglądało u nas

Opiekujemy się kilkoma serwerami ze stronami klientów i naszymi własnymi, więc mieliśmy porównanie jak w laboratorium:

• Hosting zarządzany (panel xCloud, 116 stron): wyłączył podatną funkcję PHP o 9:39, cztery minuty przed pierwszymi atakami. Wieczorem sam zainstalował poprawione PHP.
• Nasz własny serwer z wpziom.pl: tu nikt tego za nas nie zrobił. Zabezpieczyliśmy go ręcznie następnego dnia o 6:34.
• Panel klienta w chmurze Cloudflare: w ogóle nie używa PHP, więc ta luka go nie dotyczyła.

Potem sprawdziliśmy wszystkie serwery tym samym poleceniem, które dałem Ci wyżej: logi, pliki, konta i procesy. Śladów włamania brak.

Wniosek zobaczyłem czarno na białym: dobry hosting z panelem, który sam łata serwer, pilnuje fundamentów szybciej niż człowiek, który rano budzi się i czyta wiadomości. Dlatego przy każdym nowym narzędziu pytamy teraz, czy naprawdę musi stać na naszym własnym serwerze.

Kto co naprawia

Gdy w wiadomościach znów zrobi się głośno, zacznij od pytania, której warstwy to dotyczy. Od tego zależy, do kogo piszesz:

• Luka w PHP albo na serwerze: piszesz do hostingu.
• Luka w WordPressie albo we wtyczce: aktualizujesz w kokpicie albo prosisz osobę, która opiekuje się stroną.
• Wyciek hasła albo przejęte konto: zmieniasz hasło i włączasz logowanie dwuetapowe.

W skrócie

Luka PHP2Shell siedziała w PHP, więc łatać musiał hosting. Większość zrobiła to tego samego dnia. Sprawdź w „Stanie witryny”, na jakiej wersji PHP stoisz, a jeśli masz wątpliwości, zapytaj hosting albo zleć sprawdzenie Claude’owi.

Napisz proszę w komentarzu w społeczności, jaką wersję PHP widzisz i na jakim hostingu stoisz, a podpowiem, co dalej. Dołącz do naszej społeczności ziomków z podobnymi wyzwaniami: https://wpziom.pl/ziomup

Źródła: CERT Polska · php.net · Sansec · The Hacker News · TheNextWeb