Luka bezpieczeństwa w PHP: czy Twoja strona WordPress jest zagrożona?

Od dwóch dni „PHP” nie schodzi z nagłówków. W Holandii przestał działać DigiD, login obywateli do usług publicznych. W Finlandii część stron rządowych wyłączono zapobiegawczo. W USA FBI i NSA wezwały organizacje do odłączenia serwerów, jeśli nie mogą wgrać poprawki. W Turcji Dyrekcja ds. Cyberbezpieczeństwa przy Prezydencie rozpoczęła skanowanie w skali całego kraju.

W tym artykule wyjaśniamy, co się stało, bez zasypywania Cię szczegółami technicznymi. Potem krok po kroku pokazujemy, jak organizator wycieczek może sprawdzić, czy jego strona jest zagrożona, co zrobić dzisiaj i jak lepiej przygotować się na przyszłość.

Najpierw podstawy: czym jest PHP?

PHP to język programowania działający za kulisami wielu stron internetowych. Gdy ktoś otwiera Twoją stronę, kod, który buduje podstronę, zamienia formularz kontaktowy w e-mail albo zapisuje rezerwację w bazie danych, bardzo często jest napisany w PHP.

Nawet jeśli nigdy o nim nie słyszałeś, prawdopodobnie gdzieś go używasz. WordPress, WooCommerce, Joomla, Drupal i wiele gotowych wtyczek rezerwacyjnych działa na PHP. Według FBI około 70% stron na świecie korzysta z PHP.

Co się stało?

20 i 21 października 2026 roku zespół PHP wydał awaryjne aktualizacje dla dwóch krytycznych luk bezpieczeństwa. Mają oznaczenia CVE-2026-109618 i CVE-2026-109619, a razem nazywa się je „PHP2Shell”. Obie otrzymały ocenę wagi 9,2 na 10.

Dlaczego to poważne: w określonych warunkach te luki pozwalają atakującemu uruchomić na Twoim serwerze dowolny kod przez internet, bez nazwy użytkownika i hasła. W bezpieczeństwie nazywa się to zdalnym wykonaniem kodu (RCE). Mówiąc prościej: ktoś może wejść przez Twoje drzwi bez klucza.

Według Qualys jedna luka pojawia się, gdy dane zostają w połowie przygotowane, bo serwerowi zabrakło pamięci, a druga, gdy po błędzie zapytanie kolejnego odwiedzającego ponownie odczytuje już zwolnioną pamięć. Badacze pokazali też, że z pamięci serwera mogą wyciec dane takie jak hasła, informacje o sesji i klucze API.

Agencja Anadolu podaje, że luki znalazła w sierpniu firma bezpieczeństwa Calif z pomocą AI. Poprawki przygotowywano po cichu przez około dwa miesiące, ale informacja wyciekła do prasy dzień przed ich publikacją.

Dlaczego to taka duża sprawa?

• Skala jest ogromna: Palo Alto Networks znalazło ponad 22,6 mln dostępnych z internetu systemów, które mogą być podatne.
• Stare wersje są wszędzie: według Qualys 71% instalacji PHP o znanej wersji działa na wersjach bez wsparcia, które nie dostają regularnych poprawek.
• Ataki już trwają: Cloudflare zgłosił ruch atakujący te luki, a kod pozwalający je wykorzystać już krąży.
• Aktualizacje idą powoli: w ciągu pierwszych 12 godzin zaktualizowano tylko około 199 tys. ze 167 mln instalacji śledzonych przez Qualys.

Dlatego rządy wyłączały strony. Dopóki system nie jest załatany, najbezpieczniej jest zamknąć drzwi, przez które mógłby wejść atakujący. W Turcji Dyrekcja ds. Cyberbezpieczeństwa wysłała pilne powiadomienia do instytucji publicznych i wezwała firmy prywatne do sprawdzenia swoich systemów PHP. Poinformowała, że w e-Devlet, krajowym portalu administracji, nie wykryto problemów wpływających na usługi.

Co to może oznaczać dla organizatora wycieczek?

To, co atakujący może zrobić w środku, zależy od tego, co przechowuje Twoja strona. Najbardziej prawdopodobne scenariusze:

• Wyciek danych klientów: imiona i nazwiska, telefony, e-maile i dane paszportowe z formularzy rezerwacji. W zależności od tego, gdzie jesteś Ty i Twoi goście, przepisy takie jak RODO mogą wymagać zgłoszenia.
• Kradzież haseł i kluczy: hasło do bazy danych oraz klucze API operatora płatności, channel managera lub usługi e-mail.
• Szkodliwe treści na stronie: ukryte strony ze spamem lub kod przekierowujący odwiedzających gdzie indziej. Jeśli Google to zauważy, strona może wyświetlać się z ostrzeżeniem, a miesiące pracy nad SEO mogą ucierpieć.
• Twój serwer wykorzystany do innych celów: kopanie kryptowalut, wysyłanie spamu lub ataki na inne strony.
• Utracona sprzedaż: jeśli musisz zapobiegawczo wyłączyć stronę, nie przyjmiesz rezerwacji, nawet w szczycie sezonu.

Czy Twoja strona jest zagrożona? Najpierw sprawdź wersję

Pierwszy krok to ustalenie, czy strona działa na PHP i w jakiej wersji. W WordPressie przejdź w panelu do Narzędzia → Kondycja witryny → Informacje → Serwer. Panel hostingu (cPanel, Plesk itp.) zwykle też pokazuje ją w sekcji „Wersja PHP”.

Te wersje usuwają luki:

• PHP 8.5: 8.5.12 lub nowsza
• PHP 8.4: 8.4.27 lub nowsza
• PHP 8.3: 8.3.36 lub nowsza
• PHP 8.2: 8.2.35 lub nowsza
• PHP 8.1 lub starsze: nie ma regularnej oficjalnej aktualizacji. Jeśli firma hostingowa nie wgrała specjalnej poprawki, musisz przejść na nowszą wersję.

Uwaga: niektóre dystrybucje Linuksa wydają poprawkę, zachowując stary numer wersji. Niższy numer nie zawsze oznacza więc, że strona na pewno jest podatna. Dlatego najpewniej jest zapytać bezpośrednio firmę hostingową.

Co zrobić dzisiaj

• Napisz do firmy hostingowej i zapytaj: „Czy PHP na moim serwerze zostało zaktualizowane przeciwko PHP2Shell (CVE-2026-109618 i CVE-2026-109619)?”. Odpowiedź „Dodaliśmy regułę zapory” sama w sobie nie wystarczy. Upewnij się, że zaktualizowano samo PHP.
• Pamiętaj, że aktualizacja WordPressa tego nie naprawi: luka nie jest w WordPressie, tylko w PHP działającym pod nim. Aktualizacje wtyczek i motywów, wtyczki bezpieczeństwa ani tryb konserwacji nie chronią, bo atak może zadziałać, zanim WordPress w ogóle się załaduje.
• Jeśli masz własny serwer (VPS): zaktualizuj pakiety PHP, a potem uruchom ponownie PHP-FPM lub Apache. Serwer bez restartu nadal wykonuje stary, podatny kod. W Dockerze pobierz nowy obraz i utwórz kontenery od nowa.
• Jeśli używasz starej wersji: zrób pełną kopię zapasową przechowywaną poza serwerem, a potem przejdź na PHP 8.3 lub 8.4. Następnie sprawdź po kolei stronę główną, strony wycieczek, formularz kontaktowy i kroki rezerwacji.
• Jeśli nie możesz od razu załatać: umieszczenie strony za zaporą, np. Cloudflare, daje tymczasową ochronę. Jeśli masz zespół techniczny, może on wprowadzić tymczasowe ustawienia zalecane przez PHP (np. session.upload_progress.enabled=0). To nie jest pełne rozwiązanie, tylko sposób na zyskanie czasu.

Czy ktoś już wszedł? Sygnały do sprawdzenia

Po załataniu warto sprawdzić, czy ktoś nie dostał się do środka, zanim luka została zamknięta:

• Czy w WordPressie są konta administratora, których nie rozpoznajesz?
• Czy pojawiła się wtyczka, której nie instalowałeś?
• Czy w wp-content/uploads, folderze z Twoimi zdjęciami, są pliki .php? Nie powinno tam być żadnych plików PHP.
• Czy po wyszukaniu site:twojadomena.pl w Google pojawiają się strony, których nigdy nie napisałeś?
• Czy w Google Search Console jest ostrzeżenie w sekcji „Problemy dotyczące bezpieczeństwa”?
• Czy firma hostingowa wysłała ostrzeżenia o złośliwym oprogramowaniu, spamie lub nietypowym zużyciu zasobów?

Jeśli zauważysz którykolwiek z tych sygnałów, poproś firmę hostingową o przeskanowanie serwera i przywrócenie czystej kopii sprzed podejrzanej aktywności. Następnie zmień wszystkie hasła i klucze API: WordPress, hosting, baza danych, e-mail oraz integracje płatności i kanałów sprzedaży. Jeśli mogło dojść do wycieku danych klientów, skonsultuj swoje obowiązki z prawnikiem.

Na przyszłość: trwałe środki ostrożności

PHP2Shell nie będzie ostatnią luką. Prawdziwe pytanie brzmi, jak dobrze będziesz przygotowany następnym razem. Polecamy takie nawyki:

• Korzystaj z wersji ze wsparciem: oprogramowanie bez wsparcia nie dostaje poprawek. Dziś dobrym wyborem jest PHP 8.3 lub 8.4.
• Wyznacz osobę odpowiedzialną za aktualizacje: kto aktualizuje Twoją stronę i jak często? Odpowiedź powinna być jasna. Hosting zarządzany lub umowa serwisowa to prosty sposób, by mieć to na piśmie.
• Wiedz, co masz: główna strona, stare strony kampanii, instalacje testowe, zapomniane subdomeny… Prowadź listę z serwerem i wersją każdej z nich. Atakujący uwielbiają zapomniane strony.
• Usuń to, czego nie potrzebujesz: skasuj nieużywane wtyczki, motywy i stare strony. Każdy dodatkowy element to kolejne drzwi, które luka może otworzyć.
• Umieść stronę za zaporą: usługa taka jak Cloudflare staje się pierwszą linią obrony, gdy ogłoszona zostaje nowa luka, zanim zdążysz ją załatać.
• Trzymaj hasła i klucze osobno: nie wpisuj kluczy API do kodu, dawaj każdej usłudze tylko potrzebne uprawnienia i regularnie zmieniaj klucze.
• Przechowuj kopie zapasowe poza serwerem i testuj ich przywracanie: kopia, której nigdy nie przywrócono, to kopia, co do której nie wiesz, czy zadziała.
• Monitoruj stronę: sprawdzanie dostępności, powiadomienia Search Console i alerty o zmianach plików pokażą Ci problem, zanim zauważą go goście.
• Spisz krótki plan na wypadek incydentu: ustal z góry, do kogo dzwonisz, jak tymczasowo wyłączyć stronę i jak poinformować klientów, jeśli coś pójdzie nie tak.

Szerszy obraz: luki są znajdowane coraz szybciej

Najbardziej uderzające w tej historii jest to, że luki znaleziono z pomocą AI. Te same narzędzia są dostępne dla ludzi o złych zamiarach. Od teraz luki będą znajdowane szybciej i szybciej wykorzystywane.

Oznacza to koniec ery „zaktualizujemy, jak znajdziemy czas”. Dla organizatora wycieczek strona to już nie tylko witryna sklepowa. To narzędzie biznesowe, które przyjmuje rezerwacje i przechowuje dane klientów, więc dbanie o jej bezpieczeństwo jest częścią utrzymania firmy w ruchu.

W Monotim budujemy strony na nowoczesnej podstawie, której ten rodzaj luki w języku serwerowym nie dotyczy bezpośrednio. Ale żadna technologia nie jest bezpieczna na zawsze. Prawdziwą różnicę robi pilnowanie strony i możliwość szybkiego działania, gdy coś pójdzie nie tak.

Jeśli nie masz pewności, czy PHP2Shell dotyczy Twojej strony, albo firma hostingowa nie dała jasnej odpowiedzi, możemy przyjrzeć się jej razem.