Poprawka bezpieczeństwa nie chroni serwera, dopóki jego administrator nie może jej zainstalować. Podczas reakcji na luki PHP2Shell wolontariusz Ondřej Surý pomógł wypełnić tę lukę: przygotował pakiety PHP dla Debiana i Ubuntu, także dla starszych wydań.
17
28 Jego praca pokazuje, że bezpieczeństwo otwartego oprogramowania zależy nie tylko od wykrywania i naprawiania błędów, lecz także od ludzi utrzymujących kanały, którymi aktualizacje trafiają do użytkowników.
PHP2Shell: czego dotyczyły luki i jakie poprawki wydano
PHP2Shell to nazwa dwóch podatności: CVE-2026-109618 i CVE-2026-109619. W zapowiedzi zespołu bezpieczeństwa PHP obie otrzymały ocenę 9,2 w skali CVSS v4.0.
6
7 Ich wykorzystanie mogło pozwolić nieuwierzytelnionemu napastnikowi na zdalne wykonanie kodu w podatnej instalacji PHP obsługującej żądania internetowe.
3
8
21 października 2026 r. PHP opublikowało poprawione wersje: 8.2.35, 8.3.36, 8.4.27 i 8.5.12.
3 Była to aktualizacja projektu źródłowego. Żeby administratorzy mogli łatwo wdrożyć ją na swoich serwerach, potrzebne były jeszcze pakiety przygotowane dla konkretnych systemów.
Dlaczego gotowe pakiety miały znaczenie
Wielu administratorów korzysta z gotowych pakietów, zamiast samodzielnie pobierać i kompilować PHP z kodu źródłowego. Przygotowanie takich pakietów to osobny etap — inny niż opracowanie lub włączenie poprawki do projektu. Surý od ponad 20 lat wolontariacko utrzymuje pakiety PHP dla Debiana i Ubuntu, głównie w wolnym czasie.
17
32
Według doniesień repozytorium Surý’ego udostępniło w dniu premiery poprawione pakiety dla wersji PHP od 5.6 do 8.5.
28 Było to istotne dla starszych instalacji: PHP 8.1 i wcześniejsze wersje nie otrzymywały już zwykłych aktualizacji od projektu PHP. Projekt opublikował jednak poprawki źródłowe dla wersji 7.4, 8.0 i 8.1, a własne poprawki udostępniały również inne firmy.
2
33
Różnica jest praktyczna. Z poprawki w kodzie źródłowym skorzystają przede wszystkim osoby, które potrafią ją zastosować i samodzielnie zbudować oprogramowanie. Gotowy pakiet daje administratorowi prostszą drogę do wdrożenia aktualizacji. Praca Surý’ego pomogła zapewnić taką możliwość użytkownikom Debiana i Ubuntu, również tym korzystającym ze starszych wersji PHP.
24
28 Dostępne doniesienia potwierdzają przygotowanie pakietów, ale nie mówią, ile serwerów je zainstalowało ani jak szybko to nastąpiło.
Napięty harmonogram i spór o termin publikacji
Zespół bezpieczeństwa PHP zaplanował wydanie poprawek na 21 października i zastrzegł, że może opublikować je wcześniej, jeśli szczegóły luk przedostaną się do opinii publicznej lub pojawią się oznaki aktywnego wykorzystania.
7 Sam proces publikacji stał się przedmiotem sporu. PHP Foundation oświadczyła, że Chainguard opublikował obrazy kontenerów z poprawkami ponad sześć godzin przed uzgodnionym terminem i uznała to za złamanie embarga.
34 W osobnej relacji podano, że prezes Chainguard uzasadniał tę decyzję pojawieniem się exploitów.
36 Są to konkurencyjne stanowiska — dostępne doniesienia same nie rozstrzygają sporu.
Bezpieczeństwo zależy także od utrzymania oprogramowania
Reakcja na PHP2Shell wymagała współpracy kilku grup: badaczy podatności, twórców PHP, opiekunów pakietów i administratorów instalujących aktualizacje. Wieloletnia, wolontariacka praca Surý’ego uwidoczniła rolę pakowania oprogramowania, ale szerszy wniosek dotyczy infrastruktury otwartego oprogramowania: poprawka musi przejść przez ręce opiekunów i dystrybutorów, zanim będzie mogła chronić działające systemy.
17
24
Utrzymywanie aktualnych pakietów jest więc samo w sobie częścią bezpieczeństwa. Dostarczanie poprawek zależy od ludzi i projektów, które potrafią je przygotowywać — także wtedy, gdy rozwój pierwotnego oprogramowania nie obejmuje już starszych wersji.
28
33