Krytyczne luki RCE w PHP (CVE-2026-109618 i CVE-2026-109619) – co to znaczy dla WordPressa

20 października 2026 do sieci wyciekły wstępne informacje o dwóch krytycznych lukach w samym PHP. Zespół PHP potwierdził problem i zapowiedział awaryjne wydanie bezpieczeństwa na środę 21 października 2026, godz. 14:00 UTC. Luki mają numery CVE-2026-109618 i CVE-2026-109619 i dotyczą zdalnego wykonania kodu (RCE). Ponieważ WordPress działa na PHP, ten problem dotyczy praktycznie każdej strony WP, WooCommerce i większości sklepów internetowych.

Co wiemy na pewno

• Zespół PHP ocenił obie luki jako krytyczne, CVSS v4.0 9,2. W obiegu krąży też wartość 10,0, ale to nie jest oficjalna ocena.
• Obie luki są w rdzeniu PHP, a nie we WordPressie ani we wtyczkach. Aktualizacja WordPressa, motywu czy wtyczki ich nie naprawi.
• Naprawa wymaga aktualizacji PHP na serwerze. Zrobi to hosting albo administrator serwera, a nie panel WordPressa.
• Firma watchTowr odtworzyła jedną z luk (CVE-2026-109618) w laboratorium. Firma Huntress poinformowała 20 października, że nie widzi jeszcze ataków w sieci.
• Według zespołu PHP wydanie mogło pojawić się wcześniej, jeśli szczegóły staną się publiczne albo zaczną się ataki.

Czego jeszcze nie wiemy

• Dokładnych wersji podatnych i naprawionych. Źródła zgodnie podają, że wsparte gałęzie PHP 8.2 do 8.5 dostaną poprawkę. Numery, które się pojawiają (8.5.12, 8.4.27, 8.3.36, 8.2.35), pochodzą z jednego źródła i są niepotwierdzone.
• Starych wersji. Sansec pisze o serwerach z PHP 5.4 lub nowszym, inne źródła o całej rodzinie od PHP 5. PHP 8.1 i starsze są po końcu wsparcia, więc oficjalnej poprawki dla nich raczej nie będzie.
• Przyczyny technicznej i warunków ataku. Nieoficjalne doniesienia mówią o błędach typu use-after-free w obsłudze postępu wysyłania plików w sesji (session.upload_progress) oraz w parserze multipart/form-data. Żaden producent tego nie potwierdził.
• Czy atak wymaga logowania. Opisy mówią o zdalnym ataku, ale oficjalnych warunków nie opublikowano.

Dlaczego to dotyczy Twojego WordPressa

WordPress, WooCommerce, Joomla, Drupal, Magento i większość sklepów to aplikacje PHP. Jeśli błąd jest w rdzeniu języka, atak może nastąpić zanim zadziała jakakolwiek ochrona na poziomie aplikacji: wtyczka bezpieczeństwa, reguły w .htaccess czy filtry w kodzie sklepu. Dlatego eksperci zalecają łatanie PHP w pierwszej kolejności na serwerach dostępnych z internetu.

To inna sytuacja niż w naszych poprzednich wpisach o WordPressie, np. WordPress 7.1 (CVE-2026-87902) czy WordPress 7.0.3 (CVE-2026-65640). Tam wystarczyło kliknąć „Zaktualizuj" w panelu. Tutaj sam WordPress nie ma nic do naprawienia.

Sprawdź swoją wersję PHP

1. W WordPressie wejdź w Narzędzia → Kondycja witryny → Informacje → Serwer i zapisz wersję PHP.
2. Pamiętaj, że hosting może łatać PHP bez zmiany numeru wersji (backport). Zapytaj go wprost, czy poprawka dla CVE-2026-109618 i CVE-2026-109619 jest wdrożona i jak to potwierdza.
3. Jeśli masz PHP 7.4, 8.0 lub 8.1, jesteś na wersji bez oficjalnego wsparcia. Zaplanuj przejście na PHP 8.3 lub nowsze. PHP 8.2 ma wsparcie bezpieczeństwa tylko do 31 grudnia 2026.

Co zrobić teraz, zanim będzie poprawka

• Napisz do hostingu i zapytaj, kiedy wdroży poprawkę. Dobre firmy hostingowe już ogłaszają awaryjne okna serwisowe.
• Zrób kopię zapasową plików i bazy poza serwerem produkcyjnym. Po zmianie PHP przetestuj logowanie, formularze, wyszukiwarkę i koszyk.
• Tymczasowe ograniczenie (częściowe). Niektórzy autorzy radzą ustawić session.upload_progress.enabled = Off w php.ini lub .user.ini. Według nich zamyka to tylko jedną z dwóch podejrzewanych ścieżek, więc to nie jest naprawa.
• Ogranicz ruch typu multipart/form-data w zaporze lub reverse proxy tam, gdzie strona nie przyjmuje plików. Tylko jeśli umiesz to zrobić bez psucia formularzy.
• Wersje bez wsparcia (PHP 5, 7, 8.0, 8.1): przejdź na wspieraną wersję. Jeśli to niemożliwe, ogranicz dostęp przez VPN lub listę dozwolonych adresów IP.
• Uważaj na „exploity" do pobrania. Pliki krążące po sieci pod nazwą PHP2Shell mogą być złośliwe. Nie uruchamiaj ich na własnym komputerze ani serwerze.

Nie polegaj na wtyczce bezpieczeństwa jako zamienniku poprawki PHP. Nie naprawi ona błędu wewnątrz interpretera.

Jak rozpoznać, że ktoś już się włamał

Po publikacji poprawki eksperci spodziewają się szybkich, masowych prób ataku. Przez pierwsze dni po wydaniu zwracaj uwagę na:

• nowe, nieznane pliki .php w katalogach wp-content/uploads, wp-content i w głównym katalogu strony,
• nowe konta administratorów i nowe zadania cron,
• zmiany w plikach rdzenia, motywu i wtyczek, których nie robiłeś,
• procesy PHP uruchamiające powłokę systemową lub narzędzia do pobierania plików,
• nagły wzrost ruchu wychodzącego albo obciążenia serwera.

Jeśli widzisz coś takiego, odizoluj serwer, zachowaj logi serwera WWW i PHP i dopiero potem czyść stronę. Więcej o objawach infekcji znajdziesz w artykule Jak wykryć malware na stronie WordPress.

Podsumowanie

To luka w PHP, więc właściciel strony nie naprawi jej samodzielnie w WordPressie. Najważniejsze są trzy rzeczy: sprawdź wersję PHP, zapytaj hosting o termin poprawki i zrezygnuj z wersji PHP bez wsparcia. Gdy poprawka się ukaże, zaktualizuj PHP od razu, bo atakujący zwykle zaczynają działać w ciągu godzin. Ten artykuł zaktualizujemy, gdy pojawią się oficjalne numery wersji i opis luk.

Źródła

• Sansec: Critical PHP RCE (CVE-2026-109618 i CVE-2026-109619)
• Huntress: php2shell, leaked critical PHP vulnerabilities
• Phoenix Security: PHP Core RCE
• Thrive: Critical PHP vulnerabilities, what WordPress owners need to know
• Wordify: PHP critical security release, October 2026