Dwie krytyczne luki bezpieczeństwa w PHP, jednym z najczęściej wykorzystywanych języków do tworzenia stron internetowych, zostały zabezpieczone. Podatności CVE-2026-109618 i CVE-2026-109619 mogły umożliwić atakującym zdalne wykonanie kodu na podatnym serwerze. Problem dotyczył również środowisk korzystających ze starszych wersji PHP, dla jakich nie przewidziano oficjalnych aktualizacji.
W cyber_Folks zakończyliśmy wdrażanie poprawek zabezpieczających przed obiema podatnościami. Nasz zespół administratorów zadbał także o środowiska działające na PHP 5.x i 7.x.
Z tego artykułu dowiesz się:
Dwie krytyczne luki w PHP. Na czym polegało zagrożenie?
W październiku 2026 roku ujawniono informacje o dwóch poważnych podatnościach w PHP, oznaczonych jako CVE-2026-109618 oraz CVE-2026-109619. Zespół odpowiedzialny za rozwój języka ocenił ich poziom zagrożenia na 9,2 w dziesięciostopniowej skali CVSS 4.0.
Obie podatności zostały powiązane z możliwością zdalnego wykonania kodu (RCE, ang. Remote Code Execution). Oznacza to, że w określonych warunkach atakujący mógłby doprowadzić do uruchomienia własnych instrukcji na podatnym serwerze. W zależności od konfiguracji środowiska i uprawnień procesu mogłoby to skutkować nieautoryzowanym dostępem do danych, ingerencją w działanie aplikacji lub przejęciem kontroli nad jej wybranymi elementami.
Potencjalny zasięg zagrożenia budził niepokój, ponieważ PHP stanowi podstawę działania wielu popularnych systemów CMS i platform e-commerce, takich jak WordPress, WooCommerce czy PrestaShop, a także aplikacji tworzonych na indywidualne zamówienie. W przeciwieństwie do luk występujących w konkretnych wtyczkach czy modułach, podatności w samym interpreterze PHP mogą wpływać na różne aplikacje korzystające z podatnej wersji języka. Rzeczywiste ryzyko wykorzystania luk zależy jednak od konfiguracji serwera, sposobu przetwarzania żądań i warunków niezbędnych do przeprowadzenia ataku.
Po ujawnieniu podatności priorytetem było szybkie wdrożenie poprawek, zarówno dla aktualnie wspieranych wersji PHP, jak i starszych wydań, jakie nie otrzymują już oficjalnych aktualizacji bezpieczeństwa.
Starsze wersje PHP bez oficjalnych poprawek bezpieczeństwa
Każda wersja PHP ma określony cykl życia. Początkowo otrzymuje regularne aktualizacje i poprawki błędów, następnie przez ograniczony czas poprawki krytycznych podatności. Po zakończeniu wsparcia producent nie publikuje już dla niej nowych aktualizacji bezpieczeństwa.
W chwili ujawnienia zagrożenia oficjalnym wsparciem były objęte wersje PHP 8.2, 8.3, 8.4 i 8.5. Starsze wersje, w tym PHP 5.x i 7.x, osiągnęły już koniec swojego cyklu życia. Użytkownicy nie mogli liczyć na standardowe poprawki przygotowane przez zespół rozwijający PHP.
Dlaczego to ważne? Starsze wersje PHP nadal bywają niezbędne do działania aplikacji, powstałych wiele lat temu. Niektóre systemy korzystają z rozwiązań niezgodnych z nowszymi wydaniami języka, a ich aktualizacja wymaga zmian w kodzie, wtyczkach lub integracjach. Przejście na nową wersję PHP nie zawsze jest więc możliwe natychmiast.
W cyber_Folks umożliwiamy korzystanie ze starszych środowisk dzięki usłudze Legacy PHP. W przypadku tak poważnych podatności oznacza to jednak dodatkową odpowiedzialność techniczną. Samo utrzymywanie zgodności ze starszym oprogramowaniem nie wystarcza. Trzeba również zadbać o jego zabezpieczenie.
| WERSJA | STATUS |
|---|---|
| 5.x | Bezpieczna |
| 7.x | Bezpieczna |
| 8.1 | Bezpieczna |
Bezpiecznie w cyber_Folks
Na bieżąco śledzimy informacje o nowych zagrożeniach i reagujemy na pojawiające się sytuacje. Dlatego po udostępnieniu poprawek przez twórców PHP, niezwłocznie przystąpiliśmy do ich wdrażania. Zadbaliśmy przy tym o to, by zabezpieczyć Twoje usługi bez zakłócania ich codziennego działania.
Znacznie większym wyzwaniem okazały się starsze wersje języka.
PHP 5.x i 7.x jak i 8.1 nie otrzymały oficjalnych łatek producenta, dlatego nasi administratorzy wykonali dodatkową pracę, wykraczającą poza standardowy proces aktualizacji. Własna reguła blokująca próby ataku została już wprowadzona chwilę po oficjalnym komunikacie o wykryciu podatności. Skutecznie zatrzymując kilkadziesiąt podejrzanych ataków na serwer
Następnie przystąpiliśmy do właściwych działań. Przeanalizowaliśmy zmiany usuwające podatności, dostosowaliśmy poprawki do starszych wersji PHP i sprawdziliśmy ich działania w tych środowiskach. Następnie zabezpieczenia wdrożyliśmy na serwery.
Takie działania są bardziej złożone niż instalacja gotowej aktualizacji. Kod starszych wersji PHP różni się od obecnie rozwijanych wydań, dlatego rozwiązania przygotowane dla PHP 8 nie muszą współpracować z PHP 5 czy PHP 7. Każda zmiana musi uwzględniać te różnice i zostać sprawdzona pod kątem skuteczności oraz zgodności z obsługiwanym środowiskiem.
Zabezpieczenia przed CVE-2026-109618 i CVE-2026-109619 wdrożyliśmy również w starszych środowiskach PHP, mimo braku oficjalnych aktualizacji dla tych wersji. Klienci korzystający z obsługiwanych przez nas środowisk nie zostali pozostawieni bez ochrony przed tymi konkretnymi zagrożeniami.
Czy muszę coś zrobić, jeśli korzystam z hostingu cyber_Folks?
Poprawki dotyczące podatności CVE-2026-109618 i CVE-2026-109619 zostały wdrożone po naszej stronie w objętych działaniami środowiskach hostingowych. Nie musisz samodzielnie instalować tych łatek na zarządzanych przez nas serwerach. Jeśli korzystasz ze starszej wersji, nie objętej oficjalną aktualizacją (5.x, 7.x, 8.1) Twoje usługi są również bezpieczne. Wdrożyliśmy samodzielnie zmiany w kodzie źródłowym, dbając o bezpieczeństwo infrastruktury.
Warto jednak sprawdzić, czy Twoja strona lub sklep korzysta z aktualnej wersji PHP. Starsze wydania, mimo zastosowania zabezpieczeń dotyczących opisanych luk, pozostają poza oficjalnym cyklem wsparcia. Korzystanie z nich może oznaczać większe ryzyko wystąpienia kolejnych podatności w przyszłości.
Jeśli Twoja aplikacja wymaga PHP 5.x lub 7.x, zaplanuj jej aktualizację do nowszego środowiska. Przed zmianą wersji PHP należy sprawdzić zgodność kodu strony, wtyczek, motywu oraz wykorzystywanych integracji. Szczególnie w przypadku rozbudowanych sklepów i starszych aplikacji warto najpierw przeprowadzić testy.
Krytyczne podatności w PHP załatane – FAQ
To identyfikatory dwóch krytycznych podatności bezpieczeństwa w PHP, powiązanych z ryzykiem zdalnego wykonania kodu na podatnym serwerze.
Nie. W przypadku zarządzanych środowisk hostingowych objętych wdrożeniem poprawki zostały zastosowane przez naszych administratorów.
Zabezpieczenia przed CVE-2026-109618 i CVE-2026-109619 wdrożyliśmy również w starszych środowiskach PHP, mimo braku oficjalnych aktualizacji dla tych wersji. Klienci korzystający z obsługiwanych przez nas środowisk nie zostali pozostawieni bez ochrony przed tymi konkretnymi zagrożeniami.
Tak, wersja PHP 8.1 również została przez nas zabezpieczona, mimo że nie otrzymała oficjalnej aktualizacji bezpieczeństwa. Nasz zespół techniczny samodzielnie wprowadził niezbędne poprawki w kodzie źródłowym, aby zapewnić ochronę Twoich usług przed wykrytymi podatnościami.
Jak wdrożyliście jak dalej nic nie ma: php -v PHP 8.2.34-CF0.1 Hardened by cyber_Folks (cli) (built: Oct 6 2026 09:06:40) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.34, Copyright (c) Zend Technologies with the ionCube PHP Loader v15.5.0, Copyright (c) 2002-2026, by ionCube Ltd. with Zend OPcache v8.2.34, Copyright (c), by Zend Technologies
Dzień dobry, na końcu oznaczenie CF oznacza, ze poprawki zostały wdrożone. Wersja PHP 8.2 jest bezpieczna.
Te poprawki robiliście nie poprzez aktualizację wersji, tylko niezależne umieszczenie w aktualnych? Stąd wersja oznaczona „8.5.11-CF0.1” która nie jest wersją 8.5.12, ale zawiera poprawkę? A w przypadku niewspieranych też sami dokonaliście modyfikacji PHP (a nie np. tylko wyłączyliście funkcjonalność podatną). Bo tak trochę nie wybrzmiało…
Dziękujemy za komentarz. Tak, dokładnie. W przypadku wspieranych wersji PHP wdrożyliśmy oficjalne poprawki bez konieczności przechodzenia na kolejne wydania. Stąd oznaczenie 8.5.11-CF0.1 – to nasza wersja zawierająca poprawkę, a nie oficjalne PHP 8.5.12. Więcej pracy wymagały starsze wersje PHP (5.x–7.x), które nie są już oficjalnie wspierane i nie otrzymają aktualizacji bezpieczeństwa. Tutaj w trosce o jego zachowanie, dostosowaliśmy poprawki w ich kodzie. Środowiska korzystające ze starszego PHP (5.x-7.x) są bezpieczne.
Rozumiem, że to samo dotyczy wersji 8.4.26, którą aktualnie posiadam, jest ona zabezpieczona i nie ma konieczności przechodzenia na oficjalną 8.4.27?
Tak, łatki bezpieczeństwa zostały wdrożone, nie ma tutaj potrzeby aktualizacji wersji.
A co z PHP 8.1? W artykule mowa o oficjalnych łatkach do PHP 8.2+ oraz że zadbaliście też o 5.x-7.x, a co z PHP 8.0 i PHP 8.1? Czy też zostały przez Państwa załatane?
Wersja 8.1 również została zabezpieczona poprzez naniesienie poprawek w kodzie źródłowym.
Dostałem taką informację na e-mail – sugeruje ona że na serwerach dedykowanych z PHP 7x też działa zabezpieczenie. Fajnie dzięki za dobrą robotę:) no bo chyba nie ma tu błędu? Zadbaliśmy o bezpieczeństwo Twoich usług Cześć, Na bieżąco monitorujemy zagrożenia i podejmujemy działania, aby chronić Twoje usługi. W związku z ogłoszonymi 21 października br. krytycznymi podatnościami PHP (CVE-2026-109618 i CVE-2026-109619) niezwłocznie rozpoczęliśmy prace nad zabezpieczeniem naszych serwerów.
Tak, pomimo, że ta wersja nie dostała oficjalnych poprawek bezpieczeństwa zespołu rozwijającego PHP, nasz zespół techniczny przygotował i wdrożył zabezpieczenia. Proszę czuć się bezpiecznym.
Nie rozumiem, zmieniliście kod źródłowy starszych wersji PHP z poprawką i zbudowaliście od zera czy pozmienialiście tylko php.ini?
Starsze wersje zostały zabezpieczone poprzez poprawki w kodzie źródłowym.
Czy na zarządzanych przez Was VPSach te poprawki też zostały wdrożone ?
Tak, wdrożyliśmy poprawki dla obu wersji PHP, w których wykryto podatności. Dodatkowo zabezpieczyliśmy również starsze wersje (5.x–7.x, 8.1), które nie otrzymują już oficjalnych aktualizacji bezpieczeństwa. W ich przypadku samodzielnie dostosowaliśmy i wdrożyliśmy poprawki w kodzie źródłowym PHP, zapewniając ochronę także tym środowiskom.
A co z wersją 8.1?
Wersja również jest zabezpieczona poprzez naniesienie poprawek w kodzie źródłowym.
To jak to jest z dedykowanymi bo mail mówi że zabezpieczyliście o wprost jednoznacznie gasi czujność a nie wydaje mi się na podstawie posta. To byłoby jeszcze gorsze
Dzień dobry, proszę o szczegóły wersji jaką Pan ma. Jeśli to jest 5.x – 7.z i 8.1) proszę czuć się bezpiecznie. Choć te wydania nie są już wspierane oficjalną aktualizacja producenta, wykonaliśmy pracę w kodzie źródłowym, zabezpieczającą przed podatnościami.
7.4.36 serwer dedykowany, hostowany w niemczech
Tak, serwer jest bezpieczny, pomimo, że wersja 7.4 nie jest objęta oficjalnym zakresem wsparcia producenta, nasz zespół techniczny niezwłocznie zaczął pracę, aby zabezpieczyć również starsze wersje. Proszę czuć się bezpiecznym.
W jaki sposob sie zalogowal na serwer? w jakims emergency trybie czy jak bo na ssh brak logowan.
Proszę zobaczyć na oznaczenie, na końcu powinien Pan widzieć oznaczenie CF. W przypadku szczegółowych pytań technicznych, chętnie odpowiemy na nie w wiadomości bezpośredniej.
O tyle to ciekawe, ze musieliscie to zrobic bokiem – bo w zakresie sesji ssh nie widac zadnych zmian spoza znanych mi IP na zadnym z kont (od roota do userow)
Poprawki wdrażaliśmy na poziomie infrastruktury serwerowej w ramach wewnętrznych działań administracyjnych. Proszę czuć się bezpiecznym, prace objęły również starsze wersja, jakich producent już nie obejmuje oficjalnym wsparciem.
A na moim WP info że PHP 8.4.26 Is it safe?
Tak, proszę czuć się bezpiecznie.
Dzień dobry, czy możemy rozumieć, że strona na WordPressie postawiona u Państwa jest zabezpieczona? Mam komunikat o przestarzałej wersji PHP w informacjach o stanie witryny.
Dzień dobry, proszę o informację jaką wersję PHP ma Pan obecnie, abyśmy mogli ustalić szczegóły.
Dzień dobry, Czyli potwierdzacie Państwo, że wersja PHP 8.3.35 jest bezpieczna i nie wymaga przejścia na 8.3.36, zgodnie z zaleceniami PHP? Prace wykonane przez Was są tożsame ze zmianami w wersji .36?
Tak, wersja ta jest objęta oficjalną aktualizacją, poprawki bezpieczeństwa zostały wdrożone.
Dzień dobry, czy wersja PHP 8.0.30 także jest bezpieczna i nie trzeba wykonywać żadnych dodatkowych działań? Pozdrawiam
Dzień dobry, tak wersja 8.0.30 jest bezpieczna, nie musi Pan wykonywać żadnych dodatkowych działań. Nasz zespół techniczny wprowadził niezbędne poprawki.
Dzień dobry, czy potwierdzone są poprawki do wersji 8.0 i czy jest ona bezpieczna? Dodatkowo, czy zalecane są jakieś dodatkowe zmiany?
Dzień dobry, poprawki do wersji 8.0 zostały wprowadzone przez nasz zespół techniczny. Wersja 8.0 jest bezpieczna.