{"id":842430,"date":"2026-10-22T11:49:18","date_gmt":"2026-10-22T11:49:18","guid":{"rendered":"https:\/\/www.knowband.com\/blog\/?p=842411\/"},"modified":"2026-10-22T11:58:28","modified_gmt":"2026-10-22T11:58:28","slug":"krytyczne-luki-w-zabezpieczeniach-php-pa%c5%badziernik-2026-co-musi-teraz-zrobi%c4%87-ka%c5%bcdy-w%c5%82a%c5%9bciciel-sklepu-prestashop","status":"publish","type":"post","link":"https:\/\/www.knowband.com\/blog\/pl\/aktualnosci\/krytyczne-luki-w-zabezpieczeniach-php-pa%c5%badziernik-2026-co-musi-teraz-zrobi%c4%87-ka%c5%bcdy-w%c5%82a%c5%9bciciel-sklepu-prestashop\/","title":{"rendered":"Krytyczne luki w zabezpieczeniach PHP (pa\u017adziernik 2026): co musi teraz zrobi\u0107 ka\u017cdy w\u0142a\u015bciciel sklepu PrestaShop"},"content":{"rendered":"

Przeczytaj to najpierw. PHP wyda\u0142o poprawki 21 pa\u017adziernika dla dw\u00f3ch krytycznych luk. Je\u015bli Tw\u00f3j sklep dzia\u0142a na nieza\u0142atanym PHP, atakuj\u0105cy mo\u017ce by\u0107 w stanie wykona\u0107 kod na serwerze bez logowania. \u017badna z tych luk nie wyst\u0119puje w PrestaShop. Dzisiaj potrzebujesz trzech odpowiedzi: jaka wersja PHP jest uruchomiona, czy Tw\u00f3j hosting zastosowa\u0142 poprawk\u0119 (uzyskaj j\u0105 na pi\u015bmie) oraz czy PHP zosta\u0142 od tego czasu zrestartowany.<\/p>\n

Wi\u0119kszo\u015b\u0107 wiadomo\u015bci o bezpiecze\u0144stwie dotyczy wtyczki lub motywu, a rozwi\u0105zaniem jest przycisk \u201eAktualizuj\u201d. W tym przypadku jest inaczej. Problem tkwi w silniku sklepu, a rozwi\u0105zanie na serwerze, poza zasi\u0119giem zaplecza. Dlatego \u0142atwo to przeoczy\u0107 i dlatego trzeba po\u015bwi\u0119ci\u0107 popo\u0142udnie, aby rozwi\u0105za\u0107 problem spokojnie i systematycznie.<\/span><\/p>\n

Jak to si\u0119 rozwin\u0119\u0142o<\/b><\/h2>\n

Zesp\u00f3\u0142 PHP ostrzeg\u0142 20 pa\u017adziernika o zbli\u017caj\u0105cych si\u0119 aktualizacjach bezpiecze\u0144stwa. Zosta\u0142y one odkryte 21 pa\u017adziernika i otrzyma\u0142y numery CVE-2026-109618 i CVE-2026-109619. Obie luki uzyska\u0142y ocen\u0119 9.2 w skali CVSS v4.0 i s\u0105 do\u015b\u0107 krytyczne, dlatego te\u017c zyska\u0142y przydomek \u201ephp2shell\u201d. Komisja Europejska (DG CNECT), ENISA, CERT-UE, Europol EC3 oraz sie\u0107 CSIRT wyda\u0142y wsp\u00f3lne ostrze\u017cenie.<\/span><\/p>\n

Komisja Europejska (DG CNECT), ENISA, CERT-EU, Europol EC3 i sie\u0107 CSIRT wyda\u0142y nast\u0119pnie wsp\u00f3lne o\u015bwiadczenie wzywaj\u0105ce organizacje do przeniesienia si\u0119. <\/span><\/p>\n

Poprawione wersje: PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.<\/span><\/p>\n

Co jest w\u0142a\u015bciwie zepsute<\/b><\/h2>\n

\"\"<\/a><\/p>\n

Obie wady mog\u0105 skutkowa\u0107 zdalnym wykonaniem kodu bez uwierzytelnienia. Innymi s\u0142owy: obca osoba w internecie mo\u017ce zmusi\u0107 Tw\u00f3j serwer do wykonania swoich instrukcji.<\/span><\/p>\n

CVE-2026-109618 to problem z obs\u0142ug\u0105 pami\u0119ci. Wyobra\u017a sobie, \u017ce PHP buduje obszar roboczy dla przychodz\u0105cego \u017c\u0105dania, a serwer w po\u0142owie procesu wyczerpuje pami\u0119\u0107. PHP zatrzymuje si\u0119, ale procedura czyszcz\u0105ca zak\u0142ada, \u017ce \u200b\u200bniedoko\u0144czony obszar roboczy jest kompletny i podejmuje odpowiednie dzia\u0142ania.<\/span><\/p>\n

CVE-2026-109619 to raczej kac. Co\u015b, co nale\u017ca\u0142o do jednego \u017c\u0105dania, nadal istnieje po zwolnieniu pami\u0119ci, a p\u00f3\u017aniejsze \u017c\u0105danie w tym samym procesie roboczym mo\u017ce je przej\u0105\u0107 i zaufa\u0107 mu.<\/span><\/p>\n

Zauwa\u017c, gdzie oba te elementy dzia\u0142aj\u0105: w PHP. PrestaShop nie jest winny i nie mo\u017ce si\u0119 przed nim obroni\u0107, poniewa\u017c atak mo\u017ce nast\u0105pi\u0107, zanim uruchomi si\u0119 cho\u0107by jedna linijka kodu PrestaShop. Aktualizacja modu\u0142u lub rdzenia nic tu nie zmienia. <\/span>Rozwi\u0105zaniem jest aktualizacja PHP.<\/b><\/p>\n

Czyj to problem?<\/b><\/h2>\n

W zakresie mo\u017cliwo\u015bci jest ka\u017cdy spos\u00f3b uruchamiania PHP w sieci: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP i LiteSpeed. Apache z mod_php to najgorszy przypadek, poniewa\u017c atak mo\u017ce zosta\u0107 uruchomiony przed wykonaniem dowolnego kodu aplikacji.<\/span><\/p>\n

To, co musisz zrobi\u0107, zale\u017cy od Twojego \u015brodowiska hostingowego i osoby zarz\u0105dzaj\u0105cej Twoj\u0105 instalacj\u0105 PHP:<\/p>\n\n\n\n\n\n\n\n\n
\u015arodowisko hostingowe<\/th>\nKto zarz\u0105dza PHP?<\/th>\nRekomendowane dzia\u0142anie<\/th>\n<\/tr>\n<\/thead>\n
Hosting www<\/td>\nTw\u00f3j dostawca hostingu<\/td>\nSkontaktuj si\u0119 ze swoim us\u0142ugodawc\u0105 hostingowym i popro\u015b o potwierdzenie, \u017ce odpowiednie poprawki zabezpiecze\u0144 PHP zosta\u0142y zastosowane w Twoim \u015brodowisku.<\/td>\n<\/tr>\n
VPS czy serwer dedykowany<\/td>\nTy lub Tw\u00f3j administrator systemu<\/td>\nZainstaluj odpowiednie aktualizacje zabezpiecze\u0144 dla swojej wersji PHP lub pakietu systemu operacyjnego, a nast\u0119pnie, je\u015bli to konieczne, uruchom ponownie odpowiednie us\u0142ugi PHP.<\/td>\n<\/tr>\n
Hosting Docker lub kontenerowy<\/td>\nZesp\u00f3\u0142 odpowiedzialny za obraz kontenera<\/td>\nOdtw\u00f3rz obraz, u\u017cywaj\u0105c obrazu bazowego PHP z odpowiednimi poprawkami bezpiecze\u0144stwa, a nast\u0119pnie wdr\u00f3\u017c go ponownie i zweryfikuj \u015brodowisko uruchomieniowe.<\/td>\n<\/tr>\n
Starsze lub nieobs\u0142ugiwane wersje PHP<\/td>\nTw\u00f3j dostawca hostingu lub administrator serwera<\/td>\nSprawd\u017a, czy dost\u0119pny jest backport bezpiecze\u0144stwa dostawcy. Je\u015bli nie, zaplanuj przej\u015bcie na obs\u0142ugiwan\u0105 wersj\u0119 PHP po sprawdzeniu zgodno\u015bci ze sklepem, motywem i modu\u0142ami.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Twoja lista kontrolna na dzi\u015b<\/b><\/h2>\n
    \n
  1. Sprawd\u017a wersj\u0119 PHP.<\/b> Back Office, Parametry zaawansowane, Informacje.<\/span><\/li>\n
  2. Napisz do swojego gospodarza.<\/b> Zapytaj wprost: \u201eCzy nasze serwery zosta\u0142y za\u0142atane pod k\u0105tem luk CVE-2026-109618 i CVE-2026-109619 oraz czy wszystkie nasze procesy PHP zosta\u0142y zrestartowane?\u201d. Zachowaj otrzyman\u0105 odpowied\u017a. Wskaz\u00f3wka: niekt\u00f3re dystrybucje po cichu stosuj\u0105 \u0142atk\u0119, pozostawiaj\u0105c numer wersji bez zmian; w zwi\u0105zku z tym wiek numeru wersji nie mo\u017ce by\u0107 wykorzystany do okre\u015blenia, czy serwer jest podatny, czy nie.<\/span><\/li>\n
  3. Zaktualizuj i uruchom ponownie.<\/b> Przejd\u017a do wersji sta\u0142ej lub pakietu z poprawkami od dostawcy. Uruchom ponownie wszystkie procesy PHP. Ponowne uruchomienie to krok, o kt\u00f3rym ludzie zapominaj\u0105. W Dockerze przebuduj obrazy.<\/span><\/li>\n
  4. Korzystasz z PHP 8.1 lub starszej wersji?<\/b> Projekt PHP opublikowa\u0142 minimalne backporty dla wersji 7.4, 8.0 i 8.1, a wiele dystrybucji Linuksa i dostawc\u00f3w LTS udost\u0119pnia poprawione pakiety. Sprawd\u017a, czy Twoja dystrybucja je udost\u0119pnia. Tak czy inaczej, zacznij planowa\u0107 migracj\u0119 do wspieranej wersji.<\/span><\/li>\n
  5. Pomy\u015bl teraz o PrestaShop.<\/b> Wybierz wersj\u0119, kt\u00f3ra obs\u0142uguje Tw\u00f3j docelowy PHP (tabela poni\u017cej). B\u0119dzie ona dost\u0119pna po poprawce, a nie przed ni\u0105.<\/span><\/li>\n<\/ol>\n

    Nie mo\u017cna jeszcze zainstalowa\u0107 poprawki? Wytyczne UE wskazuj\u0105 na jedn\u0105 opcj\u0119: odizolowanie nara\u017conej aplikacji od sieci publicznej do czasu jej naprawy. To drastyczne dla sklepu, tak. Warto jednak mie\u0107 to w zanadrzu.<\/span><\/p>\n

    Zatrzymania, podczas gdy czekasz<\/b><\/h2>\n

    PHP stoi na stanowisku, \u017ce \u017cadne rozwi\u0105zanie nie jest kompletne, a aktualizacja to jedyne bezpieczne rozwi\u0105zanie. Potraktuj wszystko w tej sekcji jako spos\u00f3b na ograniczenie nara\u017cenia na atak na kilka dni, nic wi\u0119cej.<\/span><\/p>\n