Dwie krytyczne podatności w PHP mogą w określonych warunkach pozwolić atakującemu na zdalne wykonanie kodu na serwerze bez wcześniejszego logowania. Błędy oznaczone jako CVE-2026-109618 i CVE-2026-109619 otrzymały ocenę 9,2 w skali CVSS 4.0, a zespół PHP zaleca możliwie szybkie przejście na poprawione wersje.
Problem znajduje się w samym środowisku PHP, a nie w WordPressie czy konkretnej wtyczce. Ma jednak znaczenie dla ogromnej liczby stron, ponieważ na PHP działają między innymi WordPress, Drupal i Joomla. Badacze pokazali również działające scenariusze prowadzące do wykonania kodu na instalacjach popularnych systemów CMS.
Najważniejsze informacje w skrócie:
- podatności to CVE-2026-109618 i CVE-2026-109619,
- obie otrzymały ocenę 9,2 w CVSS 4.0,
- w określonych konfiguracjach możliwe jest zdalne wykonanie kodu bez uwierzytelnienia,
- problem dotyczy PHP, a nie bezpośrednio WordPressa,
- poprawione wersje to PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12,
- pełnym rozwiązaniem jest aktualizacja PHP,
- starsze, niewspierane wersje wymagają migracji albo poprawki dostarczonej przez dystrybucję lub dostawcę hostingu.
Dwie luki mogą pozwolić na wykonanie kodu bez logowania
Obie podatności dotyczą zarządzania pamięcią wewnątrz PHP. CVE-2026-109618 wiąże się z sytuacją, w której procesowi zaczyna brakować pamięci i dochodzi do nieprawidłowej obsługi częściowo zainicjalizowanych danych. CVE-2026-109619 dotyczy z kolei danych pozostających w pamięci po zakończeniu wcześniejszego żądania. W odpowiednio przygotowanym scenariuszu oba błędy mogą prowadzić do uszkodzenia stanu procesu.
Najpoważniejszą konsekwencją jest możliwość zdalnego wykonania kodu na serwerze. Atakujący nie musi wcześniej uzyskiwać dostępu do panelu administracyjnego ani posiadać konta użytkownika. Skuteczność ataku zależy jednak od konfiguracji serwera i sposobu uruchomienia PHP, dlatego nie każda instalacja będzie narażona w identycznym stopniu.
Szczególnie istotne są konfiguracje, w których PHP pracuje jako moduł serwera lub w środowisku pozwalającym wykorzystać podatny proces przed uruchomieniem właściwego kodu aplikacji. Problem może dotyczyć również PHP-FPM, php-cgi, FrankenPHP i LiteSpeed. Zespół PHP nie wskazuje pełnego obejścia poza instalacją poprawionej wersji.
WordPress nie ma własnej luki, ale może działać na podatnym PHP
W przypadku WordPressa trzeba rozdzielić bezpieczeństwo samego CMS-a od środowiska, na którym działa. Strona może mieć aktualny WordPress, wszystkie wtyczki i motywy, a jednocześnie korzystać ze starej wersji PHP zawierającej podatność. Aktualizacja panelu WordPressa nie rozwiąże więc tego problemu.
Badacze pokazali możliwość uzyskania zdalnego wykonania kodu na testowych instalacjach WordPressa, Drupala i Joomli. Nie oznacza to, że każdy serwer z jednym z tych systemów można automatycznie przejąć. Znaczenie mają wersja PHP, konfiguracja hostingu oraz sposób obsługi żądań. Skala zagrożenia jest jednak duża właśnie dlatego, że podatny komponent znajduje się pod wieloma różnymi aplikacjami internetowymi.
To zupełnie inna sytuacja niż niedawne ataki wykorzystujące lukę w Ninja Forms, gdzie problem dotyczył konkretnej wtyczki. Tym razem administrator powinien sprawdzić wersję PHP ustawioną dla witryny. Przy hostingu współdzielonym warto również zweryfikować, czy dostawca wdrożył już poprawkę na swoich serwerach.
Te wersje PHP usuwają krytyczne podatności
Poprawki zostały opublikowane w PHP 8.2.35, 8.3.36, 8.4.27 oraz 8.5.12. Administratorzy korzystający z jednej z tych gałęzi powinni przejść co najmniej na wskazaną wersję. Samo ograniczenie dostępu do panelu WordPressa, zmiana haseł czy aktualizacja wtyczek nie rozwiązuje problemu znajdującego się niżej, w środowisku wykonującym kod strony.
Więcej uwagi wymagają instalacje wykorzystujące PHP 8.1 lub starsze wydania, które nie są już wspierane bezpośrednio przez projekt PHP. Niektóre dystrybucje Linuksa oraz dostawcy rozszerzonego wsparcia mogą przygotowywać własne poprawki bezpieczeństwa. Jeśli serwer nie otrzymał takiej aktualizacji, najbezpieczniejszym rozwiązaniem pozostaje migracja do wspieranej gałęzi.
PHP 8.2 również zbliża się do końca wsparcia zaplanowanego na 31 grudnia 2026 roku. Instalacja 8.2.35 usuwa obecne podatności, ale właściciele stron pozostający na tej wersji powinni już przygotowywać przejście na nowsze wydanie. Przed zmianą warto sprawdzić zgodność motywów, wtyczek i własnego kodu, szczególnie na starszych witrynach WordPress.
AI pomogło znaleźć błąd, ale teraz liczy się aktualizacja serwera
Wykrycie podatności ma również ciekawy wątek związany ze sztuczną inteligencją. Przy analizie bezpieczeństwa PHP wykorzystano zaawansowane modele AI, które wspierały badaczy w poszukiwaniu błędów mogących prowadzić do poważnych konsekwencji. Niezależnie od tych prac podatności analizowały również zespoły zajmujące się bezpieczeństwem infrastruktury internetowej.
Badacze przygotowali demonstracyjny exploit pokazujący możliwość wykonania kodu na serwerze z popularnymi systemami CMS. Taki test nie oznacza, że identyczny atak zadziała bez zmian na każdej stronie. Potwierdza jednak, że błędy można wykorzystać w realnym środowisku, a ich wysoka ocena nie wynika wyłącznie z teoretycznej analizy kodu.
Dla administratora najważniejsza pozostaje wersja PHP działająca na serwerze. W przypadku hostingu zarządzanego warto sprawdzić komunikaty dostawcy i numer aktualnie używanego środowiska. Przy własnym VPS-ie lub serwerze aktualizację trzeba wykonać samodzielnie. Przy podatności pozwalającej potencjalnie na zdalne wykonanie kodu odkładanie poprawki jest po prostu niepotrzebnym ryzykiem.
Źródła: PHP, Wiz, OpenAI
Dziękujemy za przeczytanie artykułu na Techoteka.pl.
Codziennie publikujemy najważniejsze informacje z Polski i ze świata dotyczące technologii, sztucznej inteligencji, nowych rozwiązań cyfrowych oraz trendów technologicznych, które kształtują przyszłość.
Obserwuj nas na Facebooku, aby być na bieżąco z najważniejszymi wydarzeniami ze świata technologii.
