1. [Strona główna](/) 2. / 3. [Baza Wiedzy](/baza-wiedzy/) 4. / 5. Krytyczne podatności w PHP: co zrobić, by strona była bezpieczna aktualnosci # Krytyczne podatności w PHP: co zrobić, by strona była bezpieczna Opublikowano: 2 listopada 2026 Dwie krytyczne luki CVE-2026-109618 i CVE-2026-109619 w PHP. Sprawdź, czy Twój hosting jest zabezpieczony i jak chronić stronę przed RCE. TL;DR - przeczytaj w 30 sekund - Dwie krytyczne podatności CVE-2026-109618 i CVE-2026-109619 umożliwiały zdalne wykonanie kodu (RCE) - CyberFolks wdrożył poprawki dla wszystkich wersji PHP, w tym nieobsługiwanych 5.x, 7.x, 8.0 i 8.1 - Klienci hostingu zarządzanego nie muszą nic robić - łatki zastosowano po stronie serwera - Warto zaplanować migrację ze starszych wersji PHP, by uniknąć ryzyka w przyszłości Krótka odpowiedź Tak, Twoje usługi hostingowe w CyberFolks są zabezpieczone przed obiema krytycznymi podatnościami CVE-2026-109618 i CVE-2026-109619. Zespół techniczny wdrożył poprawki dla wszystkich wersji PHP - zarówno oficjalnie wspieranych (8.2-8.5), jak i starszych (5.x, 7.x, 8.0, 8.1), które nie otrzymały łatek od producenta. Jeśli korzystasz z hostingu zarządzanego, nie musisz podejmować żadnych działań. Mimo to zaleca się planowanie aktualizacji aplikacji do nowszych wersji PHP, by uniknąć podobnych zagrożeń w przyszłości. **Źródło:** opracowanie własne HostGrade na podstawie materiału opublikowanego przez CyberFolks ([via CyberFolks](https://cyberfolks.pl/blog/krytyczne-podatnosci-w-php-zalatane/)). Analiza i komentarz hostingowy - HostGrade.pl. ## Co się stało i dlaczego to grozi Twojej stronie W październiku 2026 roku ujawniono informacje o dwóch poważnych podatnościach w interpreterze 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, co klasyfikuje je jako krytyczne. Obie luki był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ń, które nie otrzymują już oficjalnych aktualizacji bezpieczeństwa. ## Jak CyberFolks zabezpieczył środowiska - także te bez wsparcia producenta 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. CyberFolks umożliwia 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. Zespół administratorów niezwłocznie przystąpił do wdrażania poprawek. Własna reguła blokująca próby ataku została wprowadzona chwilę po oficjalnym komunikacie o wykryciu podatności, skutecznie zatrzymując kilkadziesiąt podejrzanych ataków na serwer. Następnie przeanalizowano zmiany usuwające podatności, dostosowano poprawki do starszych wersji PHP i sprawdzono ich działanie w tych środowiskach. 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 musiała 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żono również w starszych środowiskach PHP, mimo braku oficjalnych aktualizacji dla tych wersji. W przypadku wspieranych wersji PHP wdrożono oficjalne poprawki bez konieczności przechodzenia na kolejne wydania. Stąd oznaczenie np. 8.5.11-CF0.1 - to wersja CyberFolks zawierająca poprawkę, a nie oficjalne PHP 8.5.12. Podobnie PHP 8.2.34-CF0.1 Hardened by cyber\_Folks potwierdza, że łatki zostały nałożone. Wersja 8.1 zabezpieczono poprzez naniesienie poprawek w kodzie źródłowym, a wersje 5.x, 7.x oraz 8.0 otrzymały analogiczne zabezpieczenia przygotowane samodzielnie przez zespół techniczny. ## Co musisz zrobić (i czego nie musisz) jako klient hostingu Poprawki dotyczące podatności CVE-2026-109618 i CVE-2026-109619 zostały wdrożone po stronie CyberFolks w objętych działaniami środowiskach hostingowych. Nie musisz samodzielnie instalować tych łatek na zarządzanych przez nich 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żono samodzielnie zmiany w kodzie źródłowym, dbając o bezpieczeństwo infrastruktury. Dotyczy to również serwerów dedykowanych i zarządzanych VPS - poprawki wdrażano na poziomie infrastruktury serwerowej w ramach wewnętrznych działań administracyjnych. 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 na środowisku stagingowym. Z perspektywy HostGrade.pl to doskonały przykład na to, dlaczego wybór hostingu z aktywnym monitorowaniem zagrożeń i gotowością do backportowania łatek do starszych wersji ma kluczowe znaczenie. Nie każdy dostawca podejmie wysiłek dostosowania poprawek bezpieczeństwa do PHP 5.6 czy 7.4, gdy producent przestał je wspierać. Dobre praktyki hostingowe to nie tylko szybka reakcja na CVE, ale też transparentna komunikacja z klientami - informacja, które wersje są zabezpieczone, jak wygląda ciąg wersji (np. sufiks CF), i czy klient musi coś robić. Jeśli szukasz hostingu, który dbie o bezpieczeństwo na poziomie infrastruktury i nie zostawia klientów samych sobie z problemami starszego oprogramowania, \[LINK\] daje to bez dodatkowych kosztów. ## Dobre praktyki: jak spać spokojnie, gdy kolejne CVE uderzy w PHP Opisana sytuacja pokazuje, że bezpieczeństwo to proces, a nie jednorazowa akcja. Nawet jeśli Twój hosting zareagował exemplarycznie, warto zbudować własną odporność na przyszłe incydenty. Kluczowe zasady to: regularne sprawdzanie wersji PHP używanej przez aplikację (w panelu hostingu lub przez phpinfo), planowanie migracji ze wersji EOL (End of Life) z wyprzedzeniem - nie w momencie kryzysu, posiadanie aktualnych kopii zapasowych przed każdą zmianą wersji PHP lub aktualizacją CMS, testowanie zmian na środowisku stagingowym lub deweloperskim przed wdrożeniem na produkcję, monitorowanie komunikatów dostawcy hostingu o zdarzeniach bezpieczeństwa. Warto też pamiętać, że bezpieczeństwo interpretera to tylko jedna warstwa. Równoważnie ważne są: aktualne CMS, wtyczki i motywy, silne hasła i uwierzytelnianie dwuskładnikowe do paneli administracyjnych, ograniczenie uprawnień plików i katalogów do niezbędnego minimum, WAF (Web Application Firewall) na poziomie serwera lub CDN, certyfikat SSL/TLS i wymuszone HTTPS. Hosting, który samodzielnie hartuje starsze wersje PHP, to silny fundament, ale odpowiedzialność za kod aplikacji leży po stronie właściciela strony. Jeśli szukasz hostingu, który proaktywnie hartuje infrastrukturę i backportuje łatki do starszych wersji PHP, [CyberFolks](/out/cyberfolks/#reklama) daje to bez dodatkowych kosztów. Jeśli chcesz zgłębić temat, zajrzyj też do naszych powiązanych poradników: [Bezpieczeństwo WordPress na hostingu](/baza-wiedzy/bezpieczenstwo-wordpress-hosting/), [Dlaczego backup to podstawa bezpieczeństwa](/baza-wiedzy/backup-hosting-dlaczego-wazny/), [Hosting dla sklepu internetowego](/baza-wiedzy/hosting-dla-sklepu-internetowego/), [Co to jest VPS i kiedy warto wybrać](/baza-wiedzy/co-to-jest-vps/). Bezpieczeństwo LH.pl Hosting z WAF, ImunifyAV i CloudLinux - ochrona aplikacji w standardzie [Sprawdź ofertę](/out/lh-pl/#reklama) Backup + skan dhosting.pl Hosting z automatycznym backupem i skanerem złośliwego oprogramowania [Sprawdź ofertę](/out/dhosting/#reklama) Bezpieczeństwo CyberFolks Hosting z własną infrastrukturą i zaawansowaną ochroną serwerów [Sprawdź ofertę](/out/cyberfolks/#reklama) ## Najczęstsze pytania Czy muszę samodzielnie aktualizować PHP na moim hostingu po ujawnieniu CVE-2026-109618 i CVE-2026-109619? Nie. W przypadku hostingu zarządzanego w CyberFolks poprawki zostały wdrożone po stronie serwera przez administratorów. Dotyczy to wszystkich obsługiwanych wersji PHP, w tym starszych (5.x, 7.x, 8.0, 8.1), które nie otrzymały oficjalnych łatek od producenta. Twoje usługi są zabezpieczone bez Twojego udziału. Co oznacza sufiks CF w numerze wersji PHP (np. 8.2.34-CF0.1)? Oznaczenie CF informuje, że poprawki bezpieczeństwa zostały nałożone przez zespół CyberFolks. Wersja z tym sufiksem zawiera łatki krytycznych podatności, nawet jeśli numer wersji bazowej nie uległ zmianie na ten, który wydawał oficjalnie producent PHP. Czy mogę zostać na PHP 7.4 lub 5.6 bezpiecznie? Obecnie Twoje środowisko jest zabezpieczone przed omówionymi lukami, ponieważ CyberFolks backportował poprawki do kodu źródłowego tych wersji. Mimo to PHP 5.x i 7.x osiągnęły koniec cyklu życia i nie otrzymają oficjalnych aktualizacji w przyszłości. Zaleca się planowanie migracji do wspieranej wersji (8.2 lub nowszej), by uniknąć ryzyka nowych podatności. Co zrobić, jeśli moja strona nie działa po zmianie wersji PHP na nowszą? Przed zmianą wersji PHP zawsze warto przetestować aplikację na środowisku stagingowym. Sprawdź zgodność kodu, wtyczek, motywu i integracji. W przypadku problemów skonsultuj się z deweloperem lub wsparciem hostingu - często drobne zmiany w kodzie pozwalają uruchomić stronę na nowszym, bezpieczniejszym PHP. [← Baza Wiedzy](/baza-wiedzy/) [Porównaj hosting →](/porownanie/) ## Powiązane strony - [PHP 8.5 - co nowego i jak bezpiecznie zaktualizować stronę Nowości PHP 8.5: operator pipe, lepsza diagnostyka, kontrola pamięci. Jak przełączyć wersję w panelu hostingu i co… ](/baza-wiedzy/php-8-5-co-nowego-aktualizacja/) - [Krytyczna luka w PHP: dhosting.pl wdrożył wszystkie łatki w rekordowym czasie dhosting.pl zakończył wdrażanie poprawek CVE-2026-109618 i CVE-2026-109619 na wszystkich serwerach PHP 5.3-8.5. Co to… ](/baza-wiedzy/dhosting-pl-wdrozyl-wszystkie-latki-bezpieczenstwa-w-zwiazku-z-ogromna-luka-w-ph/) - [Monarx w SEOHOST: jak czytać blokady i wykrycia malware i co zrobić Monarx w SEOHOST: co znaczą statusy BLOCKED, MALICIOUS i COMPROMISED, jak zgłosić fałszywy alarm 403 i co zrobić po… ](/baza-wiedzy/monarx-seohost-blokady-wykrycia-co-zrobic/) - [Zmiana hasła użytkownika WordPress i weryfikacja kont – jak to zrobić Jak zweryfikować użytkowników WordPress i bezpiecznie zmienić hasło w panelu administracyjnym – praktyczny poradnik… ](/baza-wiedzy/zmiana-hasla-uzytkownika-wordpress-oraz-weryfikacja-utworzonych-uzytkownikow/) - [Szkice w WordPressie - kiedy i jak z nich korzystać? Poradnik Dowiedz się, jak skutecznie używać szkiców w WordPressie, jak różnią się od autozapisu i statusów „Oczekuje na… ](/baza-wiedzy/szkice-w-wordpressie-kiedy-warto-z-nich-korzystac/) - [Jak usunąć wirusy ze strony na WordPress - praktyczny przewodnik krok po kroku Kompletny przewodnik po rozpoznawaniu, usuwaniu malware i zabezpieczaniu WordPressa po ataku. Sprawdź objawy, procedurę… ](/baza-wiedzy/odwirusowanie-stron-na-wordpress/) - [WordPress 7.1.1 - ważna aktualizacja bezpieczeństwa (hosting) Dowiedz się, co zawiera WordPress 7.1.1, jakie luki bezpieczeństwa zostały naprawione i jak bezpiecznie zaktualizować… ](/baza-wiedzy/wordpress-7-1-1-wazna-aktualizacja-bezpieczenstwa/) - [Co oznacza komunikat „Witryna napotkała błąd krytyczny” w WordPressie? Wyjaśniamy, co oznacza komunikat o błędzie krytycznym w WordPressie, jak działa tryb odzyskiwania i jak krok po kroku… ](/baza-wiedzy/co-oznacza-komunikat-witryna-napotkala-blad-krytyczny-w-wordpressie/)