Zespół PHP łata krytyczne luki zagrażające WordPressowi i sklepom
Dwa błędy pozwalają przejąć serwer bez logowania. Aktualizacja WordPressa ani wtyczek tu nie pomoże: poprawkę musi zainstalować hosting, a przerwa serwisowa wymaga kodu odpowiedzi, który zachowa pozycję strony w Google.
W środę 21 października zespół bezpieczeństwa PHP wydał awaryjne poprawki dwóch krytycznych luk (CVE-2026-109618 i CVE-2026-109619). Pozwalają one zdalnie uruchomić kod na serwerze bez logowania. Bezpieczne są wersje PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Według twórców PHP nie ma obejścia, które w pełni zastąpi aktualizację. Najbardziej zagrożone są serwery Apache z modułem mod_php, który uruchamia PHP bezpośrednio w serwerze, bo tam atak może ruszyć, zanim zadziała kod samej strony.
Według szacunków firmy Wiz na PHP działa około 70 proc. stron internetowych. Korzystają z niego m.in. WordPress, Drupal, Joomla i Magento. PHP Foundation ocenia wagę luk na 9,2 w 10-punktowej skali. Szczegóły wyciekły dzień przed premierą poprawki, a Cloudflare zgłosił pierwsze ataki niemal sześć godzin przed nią, podaje My Company Polska. Amerykańska agencja CISA w alercie z 21 października pisała jednak, że nie obserwuje jeszcze potwierdzonych ataków. Finlandia i Holandia zapobiegawczo wyłączyły część rządowych serwisów.
Wersję PHP można sprawdzić w panelu WordPressa: Narzędzia > Zdrowie witryny > Informacje > Serwer. Instalację poprawionej wersji trzeba zlecić hostingowi albo software house'owi. PHP 8.1 i starsze nie dostają już regularnych oficjalnych aktualizacji, a dla wersji 7.4-8.1 opublikowano tylko ograniczone poprawki kodu źródłowego dla zespołów, które same budują PHP. W takim przypadku potrzebna jest kopia zapasowa i przejście na wspieraną wersję. Zapora WAF (filtr ruchu chroniący aplikacje internetowe) zatrzyma część ataków, ale nie zastępuje poprawki, podaje Search Engine Journal. Po aktualizacji warto sprawdzić, czy na serwerze nie ma złośliwych skryptów, nieznanych kont administratorów i zmienionych plików PHP, bo łatka nie usuwa wcześniejszego włamania.
Jeśli strony nie da się załatać od razu, unijny zespół reagowania na incydenty komputerowe CERT-EU radzi ją czasowo wyłączyć. Google Search Central zaleca, by na czas przerwy serwować komunikat z kodem HTTP 503, który oznacza, że usługa jest tymczasowo niedostępna. Wtedy zaindeksowane adresy zostają w wyszukiwarce. Kod musi pochodzić spoza PHP, np. z serwera WWW lub CDN (sieci serwerów dostarczających treść). Plik robots.txt z instrukcjami dla robotów wyszukiwarek powinien odpowiadać normalnie, bo kod 503 zwracany dla niego blokuje indeksowanie całej witryny. Według dokumentacji Google kod 503 nie powinien być zwracany dłużej niż jeden-dwa dni, bo adresy mogą wypaść z indeksu.