CVE-2026-109618 w PHP (php2shell): czym jest krytyczna luka i jak ją załatać?

PawełInstruktor Cyberium Opublikowano 22 października 2026 Zaktualizowano 3 listopada 2026 13 min czytania Poziom: Średni

Co to jest CVE-2026-109618 (php2shell)?

CVE-2026-109618 to krytyczna podatność w samym PHP — w kodzie interpretera, a nie w żadnej konkretnej aplikacji — która w określonych warunkach pozwala atakującemu bez logowania wykonać własny kod na serwerze. Zespół PHP opublikował ją 21 października 2026 roku w komunikacie bezpieczeństwa razem z drugą, powiązaną luką CVE-2026-109619. Obie dostały wspólną nazwę potoczną php2shell (od „PHP to shell”, czyli od PHP do powłoki systemu) — tak nazywa je m.in. alert CISA i CERT Polska.

Skala jest duża, bo na PHP działa m.in. WordPress, Joomla i WooCommerce. Holenderskie NCSC na 2 listopada 2026 roku śledziło 930 produktów zależnych od PHP, z czego 215 oznaczono jako podatne.

Pojęcia CVE, CVSS i KEV objaśnia przewodnik po CVE i CVSS.

Jak działa luka php2shell — wyjaśnienie prostym językiem

W skrócie: PHP w pewnych momentach obsługi żądania „sprząta po sobie” dane, które są jeszcze niekompletne albo należą już do innego żądania — a atakujący potrafi doprowadzić do takiej sytuacji celowo. To błędy pamięci: użycie niezainicjowanego wskaźnika (CWE-824) i użycie pamięci po jej zwolnieniu (use-after-free, CWE-416) — obie słabości wymieniają advisory obu luk.

Wyobraź sobie kelnera, któremu w połowie zamówienia kończy się kartka: od razu sprząta stolik i realizuje niedokończone zamówienie tak, jakby było kompletne. Kto wie, kiedy kartka się skończy, może „dopisać” coś od siebie.

Tak w uproszczeniu wygląda CVE-2026-109618. Według advisory GHSA-w8hw-w9fx-j79w PHP przy braku pamięci (OOM — przekroczenie memory_limit) natychmiast przerywa operację, a procedura kończąca żądanie traktuje niedokończone dane jak poprawne. Na Apache z mod_php dzieje się to jeszcze przed uruchomieniem kodu aplikacji.

CVE-2026-109619 to podobny błąd rozciągnięty na dwa żądania. Według advisory GHSA-6wmf-4rv5-p3rp proces PHP (worker obsługujący kolejne żądania) po błędzie krytycznym w złym momencie zachowuje globalne informacje, np. o błędach czy sesji, wskazujące na zwolnioną pamięć. Następne żądanie w tym samym procesie może z nich skorzystać, zanim PHP je zresetuje.

Nie potrzeba logowania ani działania użytkownika, a dobrze napisana aplikacja nie chroni przed luką w interpreterze. Zagrożone jest każde PHP obsługujące żądania WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed.

Których wersji PHP dotyczy CVE-2026-109618 i jakie wersje są poprawione?

Podatne są wszystkie wspierane gałęzie PHP poniżej wersji 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a także starsze, niewspierane wydania. Poprawki wyszły 21 października 2026 roku jednocześnie dla czterech gałęzi.

Ocena zależy też od konfiguracji. Według advisory GHSA ryzyko jest najwyższe dla Apache z mod_php: tam pokazano atak bez udziału kodu aplikacji, przy domyślnych limitach PHP. Dla PHP-FPM zdalne wykonanie kodu potwierdzono przez ścieżki zależne od aplikacji (dla CVE-2026-109619 w advisory, dla CVE-2026-109618 według PHP Foundation; advisory GHSA mówi ostrożniej — podatność FPM wynika z analizy kodu). CERT Polska w komunikacie 196/2026 podaje, że podatne są wszystkie wersje PHP od 5.4 w górę.

W urządzeniach i gotowych obrazach (np. Docker) z wbudowanym PHP czekasz na nową wersję od producenta i wdrażasz ją od razu.

Jaka jest ocena CVSS CVE-2026-109618?

CVE-2026-109618 ma ocenę 9,2 w CVSS 4.0 od zespołu PHP i 9,8 w CVSS 3.1 od NIST w bazie NVD — w obu skalach to poziom krytyczny. Różnica wynika z innej wersji standardu i oceny złożoności ataku.

Wektor NIST dla CVE-2026-109618 opisuje atak przez sieć, o niskiej złożoności, bez uprawnień i bez udziału ofiary, z pełnym wpływem na poufność, integralność i dostępność; zespół PHP w CVSS 4.0 zaznaczył natomiast wysoką złożoność (AC:H) i dodatkowe warunki ataku (AT:P), np. konkretną konfigurację. Bez tych dwóch warunków (AC:L, AT:N) ten sam wektor dałby 9,3. Błędne 10,0, które krążyło w sieci przed premierą, nie wynikało z żadnej oficjalnej oceny — znaczenie każdej metryki wyjaśniamy w przewodniku po CVE i CVSS.

Czy jest exploit i czy php2shell jest w katalogu CISA KEV?

Tak: obie luki są w katalogu CISA KEV od 26 października 2026 roku, co oznacza potwierdzone wykorzystywanie w atakach. Katalog KEV (Known Exploited Vulnerabilities, wersja 2026.10.30) to lista luk, o których amerykańska agencja CISA wie, że są używane w atakach; agencje federalne USA miały wdrożyć poprawki do 29 października 2026 roku.

Co wiadomo o exploitach (stan na 3.11.2026):

• Działający exploit istnieje — badacze potwierdzili zdalne wykonanie kodu na Apache z mod_php (advisory GHSA).
• Wyciek przed premierą. Według PHP Foundation 20 października ok. 15:00 UTC numery CVE (z błędną oceną 10,0) wyciekły do sieci, więc wydanie przesunięto z 22 na 21 października, 14:00 UTC. Po ogłoszeniu nowego terminu jedna z firm badawczych przez pomyłkę opublikowała wideo z działającym atakiem (później usunięte). W chwili publikacji poprawek zespół PHP nie znalazł działających publicznych exploitów, ale TU Delft zarejestrował w swoim teleskopie sieciowym pierwsze żądanie przypominające atak php2shell już 21.10 o 08:37 UTC, a przed wydaniem poprawek 49 żądań z 2 adresów IP.
• Ataki widać w danych. Delft Threat Intelligence Lab (statystyki) z Politechniki w Delft zarejestrował do 3 listopada 2026 roku (12:12 UTC) 84 213 żądań próbujących wykorzystać php2shell, z 795 adresów IP w 74 krajach; szczyt przypadł na 26 października, 14:00 UTC (8 179 żądań w ciągu godziny).

CISA w katalogu KEV wskazuje też, że lukę w jądrze Linuksa CVE-2026-46300 (w KEV od 28.10.2026) można połączyć z php2shell, żeby wgrać webshell PHP i wykonywać polecenia jako root — CVE-2026-46300 to lokalna eskalacja uprawnień (NVD: CVSS 3.1 7,8, AV:L). Inną, krytyczną lukę jądra z października opisujemy w artykule CVE-2026-98432 w jądrze Linuksa.

Jeśli serwer z PHP był dostępny z internetu bez poprawki, załataj go i przejrzyj logi co najmniej od 17 października 2026 (Amazon zarejestrował w swoich honeypotach pierwszą próbę ataku 4 dni przed ujawnieniem luki). CISA zaleca szukanie procesów PHP, które uruchamiają powłokę systemu albo pobierają narzędzia; AWS radzi też szukać żądań POST z polem PHP_SESSION_UPLOAD_PROGRESS oraz nieoczekiwanych procesów i zmian plików.

Czy luka w PHP dotyczy polskich serwisów? Co zaleca CERT Polska

Tak — CERT Polska wydał w tej sprawie dwa komunikaty, a Pełnomocnik Rządu ds. Cyberbezpieczeństwa formalną rekomendację dla podmiotów krajowego systemu cyberbezpieczeństwa.

• 21 października 2026, CERT Polska (komunikat 195/2026): zalecił inwentaryzację usług z PHP i — jeśli nie zakłóci to działalności — czasowe wyłączenie usług PHP dostępnych z internetu.
• 21 października 2026, CERT Polska (komunikat 196/2026): podatne są także systemy na WordPressie, Joomli czy WooCommerce; w pełni zabezpiecza jedynie aktualizacja PHP.
• 22 października 2026, Pełnomocnik Rządu ds. Cyberbezpieczeństwa (rekomendacja): natychmiastowe wdrożenie poprawek, a do tego czasu memory_limit na -1 (albo 128M lub więcej, jeśli zasoby nie pozwalają), post_max_size na 8M lub mniej, max_input_vars na 1000 lub mniej i session.upload_progress.enabled na Off (te same wartości podaje CERT Polska w komunikacie 196/2026).
• 22 października 2026, Ministerstwo Cyfryzacji (komunikat): Centralny Ośrodek Informatyki czasowo wyłączył strony Biuletynu Informacji Publicznej działające w Systemie Scentralizowanego Dostępu do Informacji Publicznej (SSDIP).

Ślady wykorzystania podatności w Polsce zgłasza się do CERT Polska przez formularz na stronie incydent.cert.pl.

Jak sprawdzić wersję PHP na serwerze? (php -v i pakiety)

Najprostszy sposób to polecenie php -v w terminalu serwera — porównaj wynik z wersjami 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Są jednak dwie pułapki: wersja z wiersza poleceń nie zawsze jest tą, którą używa serwer WWW, a niektóre dystrybucje łatają PHP bez zmiany numeru wersji.

Krok 1: wersja PHP w wierszu poleceń

php -v

Pierwsza linia pokazuje wersję, np. PHP 8.4.27 (cli). Numer niższy od poprawionego przy PHP z php.net lub własnej kompilacji oznacza podatność.

Krok 2: wersja używana przez serwer WWW

Strona może działać na innej wersji PHP niż php w terminalu. Na Debianie i Ubuntu:

# wersja PHP-FPM (dopasuj numer do swojej gałęzi, np. 8.3)
sudo php-fpm8.3 -v

# zainstalowane pakiety PHP i mod_php z wersjami
dpkg -l | grep -E '^ii +(php|libapache2-mod-php)'

Na RHEL i pochodnych: rpm -qa 'php*', a poprawione pakiety wskazuje errata dystrybucji (dla RHEL — strona CVE-2026-109618 w Red Hat z listą RHSA; AlmaLinux i Rocky publikują własne errata). Na hostingu współdzielonym zapytaj firmę hostingową, czy poprawki php2shell są już wdrożone.

Krok 3: numer pakietu z dystrybucji

Ubuntu przenosi poprawki do starszego numeru PHP (backport), więc tam decyduje pełny numer pakietu, nie wynik php -v. Debian tym razem wydał nowe wersje upstream (8.2.35, 8.4.27) — php -v pokaże numer poprawiony.

Wersję pakietu odczytasz z wyniku dpkg -l z kroku 2. Przykład: na Ubuntu 24.04 php -v pokaże 8.3.6, ale pakiet 8.3.6-0ubuntu0.24.04.13 ma już poprawkę. Szybki test, czy poprawka jest w pakiecie:

zgrep -c CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz   # numer gałęzi dopasuj (Debian 12: php8.2, 13: php8.4); >0 = poprawka jest
# alternatywa (pobiera changelog z repozytorium)
apt changelog php8.3-cli | grep -c CVE-2026-109618

Jeśli PHP pochodzi z popularnego repozytorium PPA ondrej/php, php -v pokazuje numer upstream (np. 8.3.36) — porównujesz go wprost z tabelą wersji wyżej.

Jak załatać CVE-2026-109618 krok po kroku?

Jedyną pełną ochroną jest aktualizacja PHP do wersji z poprawką i restart wszystkich procesów PHP. Ustawienia tymczasowe tylko zmniejszają ryzyko — tak piszą zarówno zespół PHP, jak i CERT Polska.

Aktualizacja na Debianie i Ubuntu

sudo apt update
sudo apt upgrade
# restart usługi PHP — wybierz tę, której używasz
sudo systemctl restart php8.3-fpm   # nginx + PHP-FPM
sudo systemctl restart apache2      # Apache z mod_php

Restart jest ważny: procesy uruchomione przed aktualizacją mają w pamięci stary, podatny kod — advisory każe restartować wszystkie workery. Sprawdź to:

systemctl status php8.3-fpm   # lub: systemctl status apache2
# „Active: active (running) since …” musi być późniejsze niż aktualizacja
sudo needrestart -r l         # Ubuntu: lista usług, które wciąż używają starych bibliotek

W kontenerach podbij tag obrazu bazowego do wersji z poprawką (np. php:8.4.27-fpm), przebuduj obraz i wdroż go ponownie, a potem sprawdź wynik poleceniem docker exec <kontener> php -v.

Co zrobić, jeśli nie możesz zaktualizować od razu?

Ustawienia, które zmniejszają ryzyko na czas przejściowy (godziny, nie miesiące):

• memory_limit=-1 ustawione tak, żeby aplikacja nie mogła go nadpisać (np. php_admin_value w puli FPM lub konfiguracji Apache) — usuwa limit wykorzystywany w potwierdzonym ataku na CVE-2026-109618 (polska rekomendacja: -1 albo 128M lub więcej). Granicą dostępności niech wtedy będzie, jak radzi zespół PHP, limit kontenera lub cgroup, najlepiej zabijający tylko jeden proces.
• Niski post_max_size — według php.net 8M dla aplikacji bez wysyłania plików, 32M, jeśli wysyłanie plików jest potrzebne; polska rekomendacja: 8M lub mniej.
• session.upload_progress.enabled=0 — blokuje potwierdzoną ścieżkę dla CVE-2026-109619. Ustaw w php.ini, puli FPM albo konfiguracji serwera. Komunikat php.net odradza wprost ini_set() i .user.ini: ini_set() nie zmieni ustawienia typu INI_PERDIR, a .user.ini w PHP-FPM działa dopiero po inicjalizacji żądania — za późno. Zespół PHP sugeruje (komunikat z 23.10.2026) zostawić je wyłączone także po aktualizacji, do następnego wydania (CVE-2026-115560 — rzadka konfiguracja).
• fatal_error_backtraces=0 (tylko PHP 8.5) i max_input_vars ≤ 1000 (polska rekomendacja).

Po każdej zmianie zrestartuj procesy PHP. WAF według CISA daje najwyżej częściową ochronę. Nie stosuj RLIMIT_AS ani RLIMIT_DATA — według advisory wywołują podatną ścieżkę.

Czego uczy php2shell o bezpieczeństwie aplikacji webowych?

php2shell pokazuje, że bezpieczeństwo aplikacji webowej zależy nie tylko od jej kodu, ale też od środowiska, w którym działa.

1. Sytuacje wyjątkowe to osobna klasa ryzyka. Oba CVE mają w klasyfikacji CWE-755 (błędna obsługa sytuacji wyjątkowych) — słabość z nowej kategorii A10:2025 Mishandling of Exceptional Conditions. Więcej: OWASP Top 10 2025 po polsku.
2. Łatanie to część bezpieczeństwa aplikacji. Aplikacja bez ani jednej podatności typu SQL injection nadal może zostać przejęta, jeśli działa na niezałatanym interpreterze.
3. AI zwiększa liczbę wykrywanych luk. Według PHP Foundation badania wspierane przez AI dają zespołowi PHP znacznie więcej zgłoszeń — od 1 lipca 2026 roku zespół opublikował 15 CVE, a ponad 100 zgłoszeń odrzucił jako błędne, zdublowane lub niemożliwe do odtworzenia — ale decyzję o poprawce podejmuje człowiek, który zna kod — więcej w artykule czy warto uczyć się cyberbezpieczeństwa w czasach AI.

Gdzie nauczyć się rozumieć podatności w aplikacjach webowych?

Podatności takie jak php2shell najlepiej zrozumieć, przechodząc cały cykl w laboratorium: od wpisu CVE i oceny CVSS, przez wykorzystanie luki, po raport z zaleceniami naprawczymi.

Jak wygląda nauka podatności w Cyberium?

W Cyberium — polskim kursie cyberbezpieczeństwa online — praca z podatnościami przewija się przez kilka szkoleń:

• Szkolenie 3 „Fundamenty cyberbezpieczeństwa i metodyka pentestów” — moduł „Podatności, zagrożenia i ryzyko”, w tym podatności i system oceny CVSS.
• Szkolenie 4 „Rekonesans, skanowanie i eksploitacja systemów” (35 lekcji, 13 laboratoriów praktycznych) — skanery Nessus i OpenVAS/GVM, weryfikacja false positives (fałszywych alarmów), wyszukiwanie exploitów, eksploitacja aplikacji WordPress i usług takich jak Apache.
• Szkolenie 6 „Post-eksploitacja i raportowanie” — dokumentowanie podatności z CVSS i zalecenia naprawcze w raporcie.
• Szkolenie 8 „Atakowanie aplikacji webowych — techniki zaawansowane” (22 lekcje, 11 laboratoriów praktycznych) — m.in. LFI i RFI z obejściem filtrów przy użyciu wrapperów PHP, a w module „Treningowe CVE” realna, aktualna podatność React2Shell (CVE-2025-55182): praca z nowym CVE od opisu do wykorzystania.

Podstawy aplikacji webowych (Burp Suite, SQL injection) poznajesz w szkoleniu 7 — pełny program kursu cyberbezpieczeństwa.

Do tego: podział 80/20 między praktyką a teorią, 57 laboratoriów i 5 misji do portfolio, CyberBox (Kali Linux w przeglądarce, bez instalacji), wsparcie eksperta, dostęp od razu, a na końcu praktyczny egzamin C:CCE z raportem — po zaliczeniu certyfikat.

Przed zakupem obejrzyj dwie bezpłatne lekcje DEMO. Zaczynasz od zera? Najpierw podstawy cyberbezpieczeństwa w 30 dni i plan nauki w 8 krokach.

Najczęstsze pytania (FAQ)

Podsumowanie

CVE-2026-109618 i CVE-2026-109619, czyli php2shell, to krytyczne luki w PHP: zdalne wykonanie kodu bez logowania, CVSS 4.0 9,2 (NVD: 9,8 i 8,1), wpis w CISA KEV. Sprawdź wersję (php -v i pakiety), zaktualizuj do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, zrestartuj procesy PHP i przejrzyj logi.

Chcesz rozumieć takie podatności od środka — od wektora CVSS po raport z zaleceniami? Zacznij od kursu cyberbezpieczeństwa Cyberium.