PHP2Shell: nieuwierzytelnione RCE w PHP i jak sprawdzić, czy dotyczy Państwa buildów

PHP2Shell to dwie krytyczne podatności w samym PHP, CVE-2026-109618 i CVE-2026-109619, które mogą pozwolić nieuwierzytelnionemu żądaniu HTTP wykonać kod w każdej instalacji PHP obsługującej żądania webowe: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Obie są wykorzystywane w praktyce i figurują w katalogu KEV CISA. Poprawką jest PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35; PHP 8.1 i starsze nie dostaną wydania upstream. Należy zaktualizować PHP, a następnie przebudować i ponownie wdrożyć każdy obraz kontenera zawierający PHP, w tym stare tagi, które nadal działają, oraz obrazy dostarczone klientom.

Załatanie serwera, o którym się wie, to łatwa część. Ekspozycja, która się utrzymuje, to PHP, o którym zapomniano: środowisko uruchomieniowe wkompilowane w obraz bazowy, tag obrazu z zeszłego roku, który wciąż działa na produkcji, obraz CI albo produkt dostarczony klientom z PHP po końcu wsparcia. Ta strona najpierw pomaga załatać systemy, a potem pokazuje, jak znaleźć resztę.

Co się wydarzyło

Data (2026)	Zdarzenie	Źródło
11 i 21 sierpnia	Calif zgłasza oba błędy projektowi PHP	Calif
17 października	Pierwsza próba wykorzystania zaobserwowana przez Amazon w jego honeypotach, sprzed ujawnienia	Amazon Threat Intelligence
20 października	PHP zapowiada na 21 października, 14:00 UTC, wydanie bezpieczeństwa usuwające dwie podatności z oceną CVSS 4.0 9,2	php.net
21 października	PHP wydaje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 oraz publikuje biuletyn; rekordy CVE stają się publiczne; NCSC-NL otwiera repozytorium php2shell	Biuletyn PHP, NCSC-NL
21 października	Oficjalne obrazy Docker php zostają zaktualizowane do wersji z poprawką	docker-library/php
21 października	watchTowr zgłasza wykorzystywanie obu CVE w praktyce; CISA publikuje alert	watchTowr, CISA
22 października	Searchlight Cyber publikuje php2shell-scanner	GitHub
23 października	PHP zaleca ustawienie session.upload_progress.enabled=0 ze względu na osobny, mało prawdopodobny wektor RCE, CVE-2026-115560	php.net
26 października	CISA dodaje oba CVE do katalogu KEV z terminem 29 października dla amerykańskich agencji federalnych	CISA KEV

Nazwa PHP2Shell pochodzi z opracowania Calif i jest używana w relacjach branżowych; własne biuletyny PHP jej nie używają. Rekordy CVE wymieniają jako zgłaszających Calif, Wiz i OpenAI.

Kogo to dotyczy

Każdego PHP, które obsługuje żądania webowe. Biuletyn PHP wymienia PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed, i określa ryzyko jako najwyższe w przypadku mod_php, „z zademonstrowanym exploitem, w którym nieuwierzytelnione żądanie może uruchomić atak, zanim wykona się jakikolwiek kod aplikacji”. Ponieważ błędy tkwią w samym PHP, aplikacje oparte na Laravel, Symfony lub WordPress są narażone zawsze, gdy narażone jest PHP pod nimi.

Gałąź	Podatne	Poprawione w	Wsparcie upstream
8.5	przed 8.5.12	8.5.12	Aktywne
8.4	przed 8.4.27	8.4.27	Aktywne
8.3	przed 8.3.36	8.3.36	Tylko poprawki bezpieczeństwa, do 31 grudnia 2027 roku
8.2	przed 8.2.35	8.2.35	Tylko poprawki bezpieczeństwa, do 31 grudnia 2026 roku
8.1, 8.0, 7.4	wszystkie wersje, według Calif i watchTowr	brak wydania; minimalne backporty źródeł w php-src	Koniec wsparcia
7.3 i starsze, w tym PHP 5	wszystkie wersje, według Calif i watchTowr	brak poprawki upstream	Koniec wsparcia

Biuletyny PHP wymieniają tylko wspierane gałęzie. W przypadku starszych Calif podaje, że „najwcześniejsza podatna ścieżka, jaką znaleźliśmy, pochodzi z PHP 5.4.0”, a watchTowr wymienia PHP 7 i PHP 5 jako podatne i bez poprawki. PHP podaje, że gałęzie 8.1 i starsze „nie otrzymują już aktualizacji od projektu PHP”, ale opublikował minimalne backporty źródeł dla 7.4, 8.0 i 8.1 dla osób, które budują ze źródeł. Niektóre dystrybucje i komercyjni dostawcy wsparcia długoterminowego dostarczają backportowane poprawki dla gałęzi po końcu wsparcia; warto zapytać swojego. Jeśli testują Państwo kolejną wersję główną, PHP 8.6.0 RC4, wydane tego samego dnia, również zawiera poprawki.

Jak to działa

Oba CVE to błędy bezpieczeństwa pamięci w sposobie, w jaki PHP przygotowuje i kończy obsługę żądania, poniżej jakiegokolwiek kodu aplikacji. Rekordy CVE klasyfikują oba jako use after free (CWE-416), a także jako nieprawidłową obsługę sytuacji wyjątkowych, dostęp do niezainicjalizowanego wskaźnika, niekontrolowaną alokację pamięci i nieprawidłową inicjalizację (CWE-755, CWE-824, CWE-1325, CWE-1419). Słowami PHP:

• CVE-2026-109618, RCE przez uszkodzenie przy braku pamięci (OOM): „obsługa braku pamięci może przerwać PHP, gdy wewnętrzne dane żądania są zainicjalizowane tylko częściowo. Czyszczenie po żądaniu może wtedy potraktować nieprawidłowe dane jako prawidłowe”. Treść żądania spreparowana tak, by wyczerpać pamięć podczas parsowania przez PHP, może wywołać takie przerwanie. Apache z mod_php wykonuje czyszczenie nawet wtedy, gdy uruchomienie żądania się nie powiodło, i dlatego atak działa tam, zanim uruchomi się jakikolwiek kod aplikacji. W przypadku PHP-FPM biuletyn PHP stwierdza, że analiza kodu źródłowego wskazuje na podatność, choć nie zademonstrowano pełnego exploita dla FPM.
• CVE-2026-109619, RCE przez nieaktualny stan globalny: „wewnętrzny stan należący do żądania może przetrwać po zwolnieniu pamięci, na której się opiera. Późniejsze żądanie obsługiwane przez ten sam worker może użyć tego nieaktualnego stanu, zanim normalna inicjalizacja go zresetuje”. Potrzebne są dwa żądania trafiające do tego samego workera: jedno, które pozostawia ten stan, na przykład przez błąd krytyczny, i drugie, które go używa. Biuletyn PHP potwierdza ścieżkę przez session upload progress wobec mod_php i FPM oraz ścieżkę przez backtrace'y błędów krytycznych w PHP 8.5 wobec mod_php.

Dlatego tymczasowe ustawienia PHP dotyczą limitów pamięci, rozmiaru treści żądania, session upload progress i backtrace'ów błędów krytycznych: każde z nich zamyka jedną ścieżkę do błędów, a nie same błędy. PHP jako CNA ocenia oba na 9,2 w CVSS 4.0. Własne oceny NVD w CVSS 3.1 to 9,8 dla CVE-2026-109618 i 8,1 dla CVE-2026-109619.

Jak sprawdzić, czy to Państwa dotyczy

Najpierw hosty, o których Państwo wiedzą, potem poszukiwanie PHP we wszystkim, co Państwo budują i dostarczają.

Na hoście lub maszynie wirtualnej należy sprawdzić wersję zgłaszaną przez PHP. Trzeba też sprawdzić webowe SAPI, ponieważ php-fpm lub moduł Apache mogą pochodzić z innego pakietu niż wiersz poleceń:

php -v
php-fpm -v

Pakiety dystrybucji (Debian, Ubuntu, Alpine, RHEL) często dostają poprawkę jako backport bez nowej wersji upstream: Ubuntu 24.04 na przykład dostarcza poprawkę jako 8.3.6-0ubuntu0.24.04.13. Samo sprawdzenie wersji wprowadza tu w błąd. Należy wylistować zainstalowany pakiet i porównać go z wersją pakietu z poprawką w trackerze bezpieczeństwa dystrybucji:

dpkg -l 'php*' | grep '^ii'    # Debian, Ubuntu
apk info -v | grep '^php'      # Alpine
rpm -qa 'php*'                 # RHEL, Fedora, Rocky, Alma

W obrazach kontenerów. Oficjalne obrazy php: kompilują PHP ze źródeł, więc wersja znajduje się w samym obrazie, a nie na liście pakietów dystrybucji. Trzeba zapytać obraz bezpośrednio:

docker run --rm --entrypoint php php:8.3-fpm -v

Aby sprawdzić każdy obraz, który faktycznie działa, należy je wylistować i zapytać każdy z nich. Dla Kubernetes:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u \
  | while read -r image; do
      version=$(docker run --rm --entrypoint php "$image" -r 'echo PHP_VERSION;' 2>/dev/null)
      printf '%s\t%s\n' "${version:-no php}" "$image"
    done

Obrazy budowane FROM debian lub FROM alpine z PHP zainstalowanym przez menedżer pakietów wymagają opisanego wyżej sprawdzenia pakietów, uruchomionego wewnątrz obrazu.

W repozytoriach należy wyszukać każde miejsce, w którym wybierane jest PHP:

git grep -nE '^FROM[[:space:]]+(.*/)?php:' -- '*Dockerfile*' '*.dockerfile'
git grep -nE 'php-version|image:.*php' -- .github/workflows '*.yml' '*.yaml'

Przypięte tagi, takie jak php:8.3.30-fpm, pozostają podatne, dopóki ktoś ich nie zmieni. Ruchome tagi, takie jak php:8.3-fpm, zostały od 21 października przebudowane z wersjami z poprawką, ale obraz zbudowany wcześniej zachowuje stare PHP, dopóki nie zostanie przebudowany. Ograniczenie php w composer.json mówi, które wersje akceptuje Państwa kod, a nie która faktycznie działa.

W CI. Zadania buildu i testów często używają własnego PHP: kontenera usługi php:, akcji konfiguracyjnej z parametrem php-version albo obrazu runnera. Nie obsługują ruchu produkcyjnego, ale pokazują, jakie obrazy i wersje produkuje Państwa pipeline.

Hosty wystawione na zewnątrz. php2shell-scanner firmy Searchlight Cyber sonduje URL dużymi żądaniami multipart, około 29 MiB na ścieżkę. Należy go uruchamiać tylko na hostach, do których testowania mają Państwo uprawnienia. Jego README ostrzega przed fałszywymi alarmami na załatanym PHP z niskim memory_limit, a gdy PHP nie ujawnia swojej wersji, skaner nie odróżni serwera załatanego od podatnego. Należy traktować go jako wskazówkę, a nie dowód. Repozytorium NCSC-NL zbiera reguły wykrywania i listę produktów zawierających PHP wraz z ich statusem.

Czego dzisiejszy skan nie powie. Skanowanie obrazów w rejestrze obejmuje to, co wdrożyliby Państwo dzisiaj. Nie obejmuje wcześniejszego wydania dostarczonego klientowi, starego tagu, który klient nadal uruchamia, ani tego, które z Państwa buildów wyprodukowały obrazy z podatnym PHP. Do tego potrzebny jest zapis tego, co każdy build zawierał, dla każdego wydania. Więcej w artykule czy to nas dotyczy? Jak ocenić nowy CVE we wszystkich buildach.

Jak to naprawić i co zrobić, jeśli nie można jeszcze załatać

1. Zaktualizować do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo do pakietu dystrybucji z poprawką. Na 8.1 lub starszym należy przejść na wspieraną gałąź; backporty PHP i buildy dostawców to rozwiązania tymczasowe.
2. Przebudować każdy obraz z poprawionej bazy (ponownie pobrać obraz bazowy lub zbudować bez cache) i ponownie go wdrożyć. Już działające obrazy zachowują stare PHP, dopóki nie zostaną zastąpione, więc trzeba też zrestartować obciążenia.
3. Zweryfikować według poniższej listy kontrolnej, na działających kontenerach, a nie tylko na nowym obrazie.

Jeśli nie mogą Państwo jeszcze zaktualizować, biuletyn PHP wymienia środki, które „ograniczają ekspozycję na konkretne ścieżki ataku, ale nie czynią instalacji bezpieczną”. Dla CVE-2026-109618:

• „Ustawić memory_limit=-1, najlepiej w sposób, którego aplikacje nie mogą nadpisać, na przykład przez php_admin_value w puli FPM lub konfiguracji Apache, i sprawdzić, czy żadne ustawienie puli, katalogu ani aplikacji nie przywraca skończonego limitu”.
• „W aplikacjach, które nie wymagają przesyłania plików, ustawić post_max_size = 8M. Jeśli przesyłanie plików jest konieczne, ustawić post_max_size = 32M. Utrzymywać upload_max_filesize poniżej post_max_size”.
• Jako granicę dostępności stosować limit pamięci kontenera lub cgroup i nie zastępować go przez RLIMIT_AS ani RLIMIT_DATA, „ponieważ mogą one wywołać podatny błąd alokacji”.

Dla CVE-2026-109619:

• „Ustawić session.upload_progress.enabled=0 i zrestartować każdy worker. Użyć php.ini, puli FPM lub konfiguracji serwera, która obowiązuje przed parsowaniem żądania. Nie polegać na ini_set() ani na FPM .user.ini”.
• „Na PHP 8.5 ustawić fatal_error_backtraces=0 i zrestartować każdy worker”.

Warto sprawdzić, z jakimi ustawieniami faktycznie działa każdy worker:

php-fpm -i | grep -E 'memory_limit|post_max_size|session.upload_progress.enabled'

Alert CISA idzie dalej: organizacje, które nie mogą natychmiast zaktualizować lub nadal używają PHP 8.1 lub starszego, „powinny odłączyć systemy oparte na PHP, dopóki nie zostaną załatane lub zaktualizowane”. Zaleca też obserwowanie procesów workerów PHP, które uruchamiają powłoki lub pobierają narzędzia.

Weryfikacja poprawki

1. Zapytać działające PHP, a nie obraz, który miał zostać wdrożony. Uruchomić php-fpm -v (lub php -v) w każdym działającym kontenerze i na każdym hoście i potwierdzić wersję 8.5.12, 8.4.27, 8.3.36, 8.2.35 lub nowszą.
2. Nie polegać na samym numerze wersji w pakietach dystrybucji. Debian, Ubuntu, RHEL i inne dystrybucje backportują poprawkę do wersji, którą już dostarczają, więc załatane PHP może nadal zgłaszać 8.3.6: poprawka w Ubuntu 24.04 to 8.3.6-0ubuntu0.24.04.13. Należy porównać pełną wersję pakietu z trackerem bezpieczeństwa dystrybucji lub poszukać CVE w changelogu pakietu, który zwykle go wymienia. Pułapka działa też w drugą stronę: skaner porównujący tylko numery wersji upstream może oznaczyć backportowany pakiet jako podatny.
3. Sprawdzić, czy każde obciążenie działa na przebudowanym obrazie. Tag, który teraz wskazuje na poprawiony obraz, nie zmienia poda, który pobrał stary. Należy porównać digest obrazu uruchomionego w każdym kontenerze z digestem zbudowanego obrazu:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.image}{"\t"}{.imageID}{"\n"}{end}{end}'

4. Sprawdzić, czy każdy worker został zrestartowany. PHP-FPM i Apache trzymają stary kod w pamięci do restartu; sprawdzenie procesów w sekcji „Jak sprawdzić, czy doszło do włamania” pokazuje te, które nadal go wykonują.
5. Jeśli nadal korzystają Państwo z tymczasowych ustawień, sprawdzić każdą pulę poleceniem php-fpm -i podanym wyżej i utrzymać je, dopóki aktualizacja nie zostanie wszędzie zakończona.
6. Ponownie wykonać inwentaryzację z sekcji o sprawdzaniu w rejestrze, obrazach CI i wydaniach używanych przez klientów, a nie tylko w produkcji.

Jak sprawdzić, czy doszło do włamania

PHP2Shell jest wykorzystywany w praktyce, a Amazon zaobserwował pierwszą próbę 17 października 2026 roku, cztery dni przed poprawką. Jeśli PHP dostępne z internetu działało w podatnej wersji bez tymczasowych ustawień w dowolnym momencie od tego dnia, należy je sprawdzić.

Skala ekspozycji. Liczby banerów z Shodana opublikowane przez Mallory 20 października, przytoczone przez CybelAngel, wskazały 2,24 mln hostów dostępnych z internetu, które ujawniają PHP; spośród około 1,5 mln pokazujących wersję 883 717 (59%) działa na gałęzi bez oficjalnej poprawki. To liczby hostów, a nie potwierdzonych podatnych systemów: backportowane pakiety mogą wyglądać na stare, a być załatane, a około 740 000 hostów ukrywa swoją wersję.

Urządzenia i produkty zawierające PHP. PHP działa też wewnątrz urządzeń typu appliance, urządzeń sieciowych, interfejsów zarządzania i produktów dostawców, w których być może nie da się go samodzielnie zaktualizować. Inwentarz NCSC-NL obejmował 9 listopada 2026 roku 968 takich produktów: 205 z poprawką, 215 podatnych, 93 w trakcie analizy, 240 zależnych od środowiska uruchomieniowego i 214 niepodatnych. Należy sprawdzić te produkty osobno i instalować aktualizacje dostawców, gdy tylko będą dostępne.

Upewnić się, że poprawka naprawdę działa. Na hostach i maszynach wirtualnych proces PHP-FPM, php-cgi lub Apache uruchomiony przed aktualizacją nadal wykonuje stary kod. Jego mapa pamięci pokazuje wtedy zastąpiony plik binarny lub libphp jako usunięty. Warto też porównać czasy uruchomienia procesów z czasem aktualizacji:

for pid in $(pgrep -f 'php-fpm|php-cgi|apache2|httpd|frankenphp'); do
  grep -qE '(php|libphp)[^/]*\(deleted\)' "/proc/$pid/maps" 2>/dev/null \
    && echo "PID $pid still runs a replaced PHP"
done
ps -o pid,lstart,args -p "$(pgrep -d, -f 'php-fpm|php-cgi|apache2|httpd|frankenphp')"

Wskaźniki ze źródeł pierwotnych:

• Żądania: żądania POST z przesyłaniem formularzy zawierające ciąg PHP_SESSION_UPLOAD_PROGRESS, który Amazon Threat Intelligence zaobserwował w próbach wykorzystania. Amazon podaje też adresy źródłowe (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37), ale zaznacza, że należą do współdzielonej infrastruktury anonimizującej: dopasowanie należy zbadać, a nie traktować jako dowód.
• Procesy i pliki: procesy workerów PHP uruchamiające powłoki lub pobierające narzędzia (CISA, która 23 października dodała regułę wykrywania Sigma), oraz nieoczekiwane uruchomienia procesów lub zmiany plików na serwerach webowych (Amazon).
• Logi: w logach Apache, PHP-FPM, reverse proxy i usług powtarzające się ostrzeżenia lub błędy rdzenia przed uruchomieniem skryptów, błędy krytyczne i błędy parsowania oraz Maximum execution time exceeded. Biuletyn PHP dodaje, że „brak błędu w logach nie jest dowodem bezpieczeństwa”.

Kiedy założyć włamanie. Jeśli znajdą Państwo którykolwiek z tych wskaźników lub jeśli wystawiony serwer działał na podatnym PHP bez środków zaradczych, a logi nie pozwalają wykluczyć wykorzystania, należy uznać go za przejęty. PHP opisuje skutek jako zdalne wykonanie kodu z uprawnieniami konta workera webowego, a to konto zwykle może odczytać konfigurację i sekrety aplikacji.

Zrotować wszystko, co mógł odczytać worker. Hasła do baz danych, klucze API i tokeny w zmiennych środowiskowych i plikach konfiguracyjnych, klucze podpisujące sesje lub ciasteczka (oraz podpisane nimi sesje) i wszelkie poświadczenia chmurowe dostępne na hoście. Rotację należy przeprowadzić po odbudowie hosta, aby nowe sekrety nigdy nie trafiły na przejętą maszynę.

Odbudować zamiast czyścić. Przejęty host lub kontener należy zastąpić z zaufanego obrazu i nie przenosić plików, które worker mógł zapisywać, takich jak katalogi uploadów, cache czy generowany kod. Nie używać ponownie obrazów, cache buildów ani artefaktów wytworzonych na przejętym hoście.

Co powiedzieć klientom

Jeśli dostarczają Państwo oprogramowanie działające na PHP, klienci zapytają. Proszę odpowiadać wersjami i działaniami, nawet zanim znane będą wszystkie odpowiedzi. Odpowiedź do dostosowania:

PHP2Shell (CVE-2026-109618, CVE-2026-109619) dotyczy wersji PHP wcześniejszych niż 8.5.12, 8.4.27, 8.3.36 i 8.2.35 oraz wszystkich starszych gałęzi PHP. [Produkt] w wersjach [od x do y] zawiera PHP [wersja] i jest podatny; wersja [z], wydana [data], zawiera PHP [wersja z poprawką]. Prosimy o aktualizację do [z]. Jeśli nie mogą Państwo od razu zaktualizować, prosimy zastosować ustawienia PHP z naszego biuletynu [link] i ograniczyć dostęp sieciowy do aplikacji. [Produkt] w wersjach [od a do b] nie jest podatny. Zaktualizujemy ten komunikat do [data].

Jeśli sprawdzanie wciąż trwa, proszę to powiedzieć i podać, kiedy przyjdzie odpowiedź. Pierwsze oświadczenie i szablony na każdy wynik znajdą Państwo w tekście jak odpowiadać klientom po ataku na łańcuch dostaw.

Jak pomaga CRACI

CRACI uruchamia Państwa zadania GitHub Actions i podczas buildu rejestruje, co każde zadanie pobiera, w tym obrazy kontenerów, pakiety apt i apk oraz pakiety Composer, a także przechowuje każdy wcześniejszy build wraz z jego SBOM. Gdy zostaje opublikowany CVE, ciągła ponowna ocena oznacza wcześniejsze buildy, które zawierały dotknięty pakiet, dzięki czemu widać, które wydania były narażone i jak długo, a nie tylko to, co znajduje dzisiejszy skan. Bramki polityk mogą blokować buildy zawierające konkretny CVE.

Jedno ograniczenie w przypadku tego incydentu: PHP wkompilowane w oficjalny obraz php: trafia do buildu wewnątrz obrazu, a nie jako pobrany pakiet. CRACI rejestruje referencję obrazu pobranego przez każdy build, dlatego należy przeszukać buildy pod kątem tagów php:, a także pakietów PHP.

Znajdź każdy build, który dostarczył podatne PHP

Więcej o zapisach buildów: SBOM-y z czasu buildu, SBOM-y obrazów Docker, czego nie wykrywa skanowanie kontenerów, katalog CISA KEV i trendy publikacji CVE. Inne incydenty: wszystkie podatności.

Więcej o bezpieczeństwie PHP poza tym incydentem znajdziesz w naszym przewodniku po bezpieczeństwie PHP.

Źródła i aktualizacje

Źródła pierwotne:

• PHP: biuletyn bezpieczeństwa z 21 października 2026 roku, biuletyn informacyjny z 23 października 2026 roku, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, wspierane wersje
• Rekordy CVE: CVE-2026-109618, CVE-2026-109619
• CISA: alert z 21 października 2026 roku, katalog KEV
• NCSC-NL: repozytorium php2shell
• NVD: CVE-2026-109618, CVE-2026-109619
• FIRST: oceny EPSS

Badania i analizy:

• Calif: PHP2Shell, opowieść o dwóch zdalnych podatnościach PHP
• Amazon Threat Intelligence
• watchTowr
• Akamai
• CybelAngel
• php2shell-scanner firmy Searchlight Cyber

Aktualizacje:

• 2026-11-11: Dodano do ramki oceny NVD, EPSS, klasy CWE, podziękowania, najnowsze bezpieczne wersje i daty końca wsparcia, a także PHP 8.6.0 RC4 i sekcje o tym, jak działają błędy, jak zweryfikować poprawkę i jak sprawdzić, czy doszło do włamania.
• 2026-11-11: Pierwsza publikacja.