Stan informacji: 22 października 2026 r.
Dwie krytyczne luki w PHP wymagają pilnej uwagi właścicieli stron internetowych i sklepów online. Podatności oznaczone jako CVE-2026-109618 oraz CVE-2026-109619 mogą umożliwić zdalne wykonanie kodu na podatnym serwerze bez logowania. Zespół PHP opublikował już aktualizacje usuwające problem, a CERT Polska i europejskie instytucje odpowiedzialne za cyberbezpieczeństwo zalecają szybkie wdrożenie poprawek.
Jeżeli prowadzisz stronę firmową lub e-commerce, warto sprawdzić, na jakiej wersji PHP działa Twój serwis i czy dostawca hostingu zastosował odpowiednie aktualizacje. W Vilaro monitorujemy sytuację, weryfikujemy środowiska klientów i przekazujemy informacje o potrzebnych działaniach.
Co się stało i dlaczego ten komunikat jest ważny?
21 października 2026 r. udostępniono poprawki do dwóch poważnych błędów w PHP. Obie podatności otrzymały ocenę 9,2 na 10 w skali CVSS v4.0, co oznacza krytyczny poziom zagrożenia. Dotyczą zarządzania pamięcią i obsługi wewnętrznego stanu PHP podczas przetwarzania żądań.
Najważniejszy z perspektywy właściciela serwisu jest możliwy skutek: atakujący może uruchomić własny kod z uprawnieniami procesu obsługującego stronę. Nie musi wcześniej znać hasła do panelu administracyjnego. Sposób wykorzystania luk i poziom narażenia zależą jednak od konfiguracji serwera oraz aplikacji.
W praktyce taki dostęp może posłużyć do nieuprawnionej zmiany plików, odczytania danych dostępnych aplikacji lub zakłócenia jej działania. Dla firmy oznacza to ryzyko przestoju, utraty zamówień i naruszenia zaufania klientów.
Kogo dotyczą luki w PHP?
PHP jest technologią wykorzystywaną po stronie serwera przez wiele stron, systemów zarządzania treścią i platform sprzedażowych. CERT Polska wymienia w swoim ostrzeżeniu m.in. WordPress, Joomla i WooCommerce. Weryfikacji wymagają również inne aplikacje korzystające z tego środowiska.
Nie należy ograniczać przeglądu wyłącznie do głównej domeny. W firmowej infrastrukturze mogą działać także starsze sklepy, subdomeny, panele, integracje i środowiska testowe. Europejskie instytucje zalecają identyfikację aplikacji opartych na PHP oraz nadanie pierwszeństwa systemom dostępnym z internetu.
Podatność nie oznacza, że doszło już do włamania. Oznacza natomiast konieczność pilnego sprawdzenia środowiska i wdrożenia właściwych poprawek.
Które wersje PHP są podatne, a które zawierają poprawki?
Poniższa tabela przedstawia wersje w poszczególnych liniach PHP oraz pierwsze oficjalne wydania usuwające obie opisane podatności. Zakresy dotyczą standardowych wydań projektu PHP, bez dodatkowych poprawek dostawców. [3][4]
| Linia PHP | Wersje podatne bez dodatkowych poprawek | Pierwsza oficjalna wersja z poprawkami |
|---|---|---|
| PHP 8.5 | 8.5.0–8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.0–8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.0–8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.0–8.2.34 | 8.2.35 |
| PHP 8.1 i 8.0 | Wydania bez poprawek dla tych luk | Brak nowego standardowego wydania projektu PHP; konieczna weryfikacja poprawki dostawcy lub migracja do wspieranej linii |
| PHP 7.x oraz 5.4–5.6 | Wydania bez poprawek dla tych luk | Brak nowego standardowego wydania projektu PHP; zalecana migracja do wspieranej linii |
CERT Polska wskazuje, że problem obejmuje wersje PHP od 5.4. Starsze linie wymagają szczególnej uwagi, ponieważ PHP 8.1 i wcześniejsze nie otrzymują już regularnych aktualizacji od zespołu projektu. Udostępniono wyjątkowe, minimalne poprawki kodu źródłowego dla PHP 7.4, 8.0 i 8.1, ale nie przywraca to tym liniom standardowego wsparcia.
Istotny jest też sposób dystrybucji PHP. Dostawca systemu lub hostingu może zastosować backport, czyli przenieść poprawkę do starszego pakietu bez zmiany podstawowego numeru wersji na jeden z wymienionych w tabeli. W takim przypadku należy uzyskać potwierdzenie, że zainstalowany pakiet usuwa obie podatności: CVE-2026-109618 i CVE-2026-109619.
Numery z tabeli wskazują wydania usuwające te konkretne luki. Przy późniejszej aktualizacji należy sprawdzić najnowsze dostępne wydanie bezpieczeństwa w wybranej, wspieranej linii.
Czy aktualizacja WordPressa i wtyczek wystarczy?
Usunięcie tych podatności wymaga poprawki w samym PHP. Aktualizacja systemu CMS, motywu lub wtyczek pozostaje potrzebnym elementem utrzymania strony, ale nie zastępuje aktualizacji środowiska serwerowego. Oficjalny komunikat obejmuje różne sposoby uruchamiania PHP, m.in. PHP-FPM, Apache z mod_php i LiteSpeed.
Dlatego nawet przy aktualnym panelu WordPressa warto osobno potwierdzić stan PHP na hostingu. To dwie odrębne warstwy oprogramowania, którymi mogą zajmować się różne osoby lub firmy.
Co powinien zrobić właściciel strony lub sklepu?
Najlepiej rozpocząć od kontaktu z administratorem lub dostawcą hostingu. Potrzebne są konkretne informacje: jaka wersja PHP obsługuje daną stronę, czy zastosowano poprawki dla obu luk i czy zaktualizowane środowisko jest już aktywne. Współpracę z hostingiem i dostawcami usług zalecają również europejskie instytucje odpowiedzialne za cyberbezpieczeństwo.
Praktyczna lista działań powinna obejmować:
- Sprawdzenie środowiska każdej aplikacji. Uwzględnij sklep, stronę firmową, subdomeny i dodatkowe instalacje.
- Potwierdzenie dostępności aktualizacji. Poproś o pełny numer pakietu lub potwierdzenie zastosowania poprawek dla obu identyfikatorów CVE.
- Przygotowanie aktualnej kopii zapasowej. Powinna obejmować pliki oraz bazę danych; warto także potwierdzić możliwość jej odtworzenia.
- Pilne wdrożenie poprawki z odpowiednią weryfikacją zgodności. Przy zmianie linii PHP szczególnej uwagi wymagają starsze moduły i integracje.
- Testy po aktualizacji. Sprawdź logowanie, formularze, koszyk, płatności, wiadomości transakcyjne i integracje istotne dla Twojego biznesu.
- Zapisanie potwierdzenia wykonanych prac. Ustal, które środowiska zaktualizowano i kto odpowiada za dalszy monitoring.
W sklepie internetowym test nie powinien kończyć się na otwarciu strony głównej. Warto przejść całą ścieżkę zakupową, ponieważ problem z płatnością lub finalizacją zamówienia może ujawnić się dopiero na jej ostatnim etapie.
Co zrobić, jeśli hosting nie udostępnił jeszcze aktualizacji?
Należy uzyskać od dostawcy informację o terminie udostępnienia poprawki i uzgodnić działania ograniczające ryzyko do czasu jej wdrożenia. Autorzy PHP podkreślają, że zmiany konfiguracji ograniczają jedynie wybrane możliwości ataku. Nie zastępują instalacji poprawek.
Dobór ustawień powinien należeć do administratora znającego dane środowisko. W przypadku szczególnie narażonych usług, których nie można szybko zaktualizować, europejskie instytucje wskazują również możliwość czasowego odizolowania aplikacji od sieci publicznej.
Jeśli pojawią się oznaki włamania, potrzebna jest dodatkowo analiza incydentu. Sama aktualizacja nie usuwa zmian, które napastnik mógł już wprowadzić. CERT Polska zaleca zgłaszanie wykrytych śladów wykorzystania podatności przez formularz na stronie incydent.cert.pl.
Dlaczego ten temat jest ważny także dla sprzedaży i marketingu?
Z perspektywy biznesowej niedostępna strona lub niesprawny sklep może zatrzymać efekty prowadzonych działań marketingowych. Reklama nadal sprowadza użytkowników, ale problem techniczny utrudnia wysłanie formularza lub zakup. Do kosztów obsługi incydentu może więc dojść utrata sprzedaży i niewykorzystany budżet kampanii.
Dlatego po pracach technicznych warto zweryfikować także formularze kontaktowe, przekierowania, działanie analityki i rejestrowanie konwersji. Właściciel firmy powinien otrzymać jasną informację zarówno o wdrożeniu poprawki, jak i o sprawdzeniu kluczowych funkcji serwisu.
Klienci Vilaro – monitorujemy sytuację i koordynujemy działania
Jeżeli jesteś klientem Vilaro, temat jest pod naszą bieżącą obserwacją. Analizujemy komunikaty dotyczące podatności, weryfikujemy środowiska klientów i kontaktujemy się w sprawie zalecanych działań. Przekazujemy informacje o zagrożeniu oraz wskazujemy, co należy sprawdzić z administratorem lub dostawcą hostingu.
Tam, gdzie potrzebna jest interwencja techniczna, pomagamy ustalić zakres prac i koordynować kolejne kroki z osobami odpowiedzialnymi za utrzymanie serwisu. Zakres weryfikacji dopasowujemy do środowiska i dostępnych uprawnień. Monitorujemy kolejne komunikaty, aby uwzględniać nowe zalecenia w przekazywanych rekomendacjach.
Chcesz potwierdzić status swojej strony lub sklepu? Skontaktuj się z opiekunem projektu w Vilaro. Pomożemy ustalić, co zostało zweryfikowane i jakie działania są jeszcze potrzebne.
Jeżeli jeszcze z nami nie współpracujesz, a potrzebujesz wsparcia w ocenie sytuacji i zaplanowaniu dalszych kroków, skontaktuj się z Vilaro.
FAQ – najczęstsze pytania o krytyczne luki w PHP
Czy działająca strona może nadal być podatna?
Tak. Poprawne wyświetlanie strony i możliwość składania zamówień nie potwierdzają obecności poprawek. Status należy ustalić na podstawie faktycznie używanego pakietu PHP oraz informacji administratora lub dostawcy.
Czy trzeba od razu przejść na PHP 8.5?
Poprawki opublikowano dla czterech linii: 8.2, 8.3, 8.4 i 8.5. Można więc zaktualizować używaną, wspieraną linię do odpowiedniego wydania z tabeli. Migrację ze starszych, niewspieranych wersji należy zaplanować z uwzględnieniem zgodności aplikacji.
Czy certyfikat SSL chroni przed tymi lukami?
Certyfikat SSL/TLS służy zabezpieczeniu połączenia z serwisem. Nie usuwa błędów w PHP, dlatego strona dostępna przez HTTPS również wymaga weryfikacji środowiska i instalacji poprawek.
Czy po aktualizacji trzeba jeszcze coś sprawdzić?
Tak. Warto potwierdzić, że strona rzeczywiście korzysta już ze zaktualizowanego środowiska, przetestować jej najważniejsze funkcje i przeanalizować ewentualne oznaki incydentu. Przygotowana lista kontroli ułatwia przekazanie właścicielowi serwisu jednoznacznego statusu wykonanych prac.
Źródła:
- CERT Polska – krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu
- ENISA – wspólne oświadczenie w sprawie krytycznych podatności PHP
- Zespół PHP – CVE-2026-109618, RCE via OOM corruption
- Zespół PHP – CVE-2026-109619, RCE via stale global state
- PHP.net – oficjalny komunikat bezpieczeństwa z 21 października 2026 r.
