Aktualna sytuacja: PHP2Shell. Dwie krytyczne luki w PHP (CVSS 9,2) umożliwiają wykonanie złośliwego kodu bez logowania. Poprawki od 21.10.2026.Co należy teraz zrobić →

Debian i Ubuntu: czy mój pakiet PHP jest załatany?

Które pakiety PHP Debian i Ubuntu poprawiły przeciw PHP2Shell, jak dokładnie porównać zainstalowany stan i na czym zawodzi dowód.

Stan 5 min czytaniaHosting i dystrybucje

Krótko: To, czy Państwa pakiet PHP w Debianie lub Ubuntu jest załatany przeciw PHP2Shell, poznają Państwo po dokładnym stanie pakietu, a nie po wersji PHP. Ubuntu opublikowało 21 października 2026 poprawione pakiety dla wszystkich wspieranych wydań, starsze przez Ubuntu Pro. Debian poprawił php8.2 w bookworm i php8.4 w trixie. Zainstalowany stan należy porównać przez dpkg --compare-versions, a potem zrestartować wszystkie usługi PHP.

Pytanie za pytaniem

„Czy mój pakiet PHP jest załatany?” brzmi jak pytanie tak lub nie. W praktyce odpowiedź zależy od trzech rzeczy: z jakiego źródła pochodzi pakiet, jaki stan jest zainstalowany i czy ten stan też działa? Ten artykuł odpowiada na pierwsze dwa punkty dla oficjalnych pakietów Debiana i Ubuntu. Jak ogólnie sprawdzić wersję i działające procesy, opisuje strona Prawidłowe sprawdzanie wersji PHP i stanu poprawek.

Informacje w oficjalnych komunikatach bezpieczeństwa Ubuntu i w Debian Security Tracker pobraliśmy 25 października 2026. Oba CVE, CVE-2026-109618 i CVE-2026-109619, są tam wymienione z tymi samymi poprawionymi stanami.

Poprawione stany pakietów w Ubuntu

Ubuntu opublikowało poprawki w dwóch komunikatach. USN-8948-1 obejmuje aktualne wydania, USN-8948-2 starsze, które otrzymują aktualizacje bezpieczeństwa już tylko przez Ubuntu Pro. Przy 16.04 i 14.04 Ubuntu wymienia dodatkowo ofertę Legacy Support.

Wydanie Ubuntu Pakiet źródłowy Poprawiony stan
26.10 php8.5 8.5.9-0ubuntu2.1
26.04 LTS php8.5 8.5.4-0ubuntu1.5
24.04 LTS php8.3 8.3.6-0ubuntu0.24.04.13
22.04 LTS php8.1 8.1.2-1ubuntu2.28
20.04 LTS (Ubuntu Pro) php7.4 7.4.3-4ubuntu2.29+esm5
18.04 LTS (Ubuntu Pro) php7.2 7.2.24-0ubuntu0.18.04.17+esm14

Uderzające jest to, że wszystkie stany zachowują pierwotną wersję PHP. Ubuntu 24.04 pozostaje przy 8.3.6, choć poprawka została przeniesiona z 8.3.36. Dlaczego tak jest i jak sobie z tym radzić, wyjaśnia artykuł Dlaczego php -v pokazuje ten sam numer. Dotknięte są każdorazowo między innymi pakiety binarne dla FPM, CLI, CGI i modułu Apache, na przykład php8.3-fpm i libapache2-mod-php8.3.

Poprawione stany pakietów w Debianie

Debian idzie tu inną drogą i dostarcza nowe wersje upstream. Według Security Tracker stan wygląda tak:

Wydanie Debiana Pakiet źródłowy Poprzedni stan Poprawiony stan Komunikat
12 bookworm php8.2 8.2.32-1~deb12u1 8.2.35-1~deb12u1 DLA-4848-1
13 trixie php8.4 8.4.24-1~deb13u1 8.4.27-1~deb13u1 DSA-6574-1
forky, sid php8.4 8.4.27-1

Komunikat dla bookworm ukazał się jako DLA, czyli przez Debian LTS. Dla php8.2 w unstable tracker nie podaje przy pobraniu jeszcze poprawionego stanu. Kto prowadzi systemy testowe na unstable, powinien mieć to na oku.

Starsze wydania Debiana nie pojawiają się w obu wpisach CVE przy pobraniu. Jeśli serwer nadal działa na takim wydaniu, na przykład Debianie 11 z PHP 7.4, nie można polegać na aktualizacji bezpieczeństwa z oficjalnego archiwum. Zostają wtedy trzy drogi: podnieść system operacyjny do wspieranego wydania, skorzystać z komercyjnej oferty długoterminowej, której zakres obejmujący PHP2Shell należy kazać sobie potwierdzić na piśmie, albo do czasu migracji zabezpieczyć serwer środkami przejściowymi i ograniczyć jego osiągalność. Na dłuższą metę tylko pierwsza droga jest trwała.

Jak dokładnie porównać zainstalowany stan

Samo spojrzenie na numer wersji nie wystarcza, ponieważ wersje Debiana są sortowane według własnych reguł. dpkg --compare-versions porównuje poprawnie. Poniższe polecenia są wyłącznie odczytowe; nazwy pakietów i stan docelowy proszę dostosować do swojego wydania.

# Zainstalowany stan i pochodzenie pakietu
apt policy php8.3-fpm

# Wszystkie zainstalowane pakiety PHP z wersją
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null

# Dokładne porównanie z poprawionym stanem (przykład Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"

W wyniku apt policy proszę zwrócić uwagę na wiersz ze źródłem pakietu. Jeśli nie widnieje tam archiwum bezpieczeństwa Państwa dystrybucji, lecz na przykład packages.sury.org lub PPA, powyższe tabele nie obowiązują. Wtedy liczy się stan tego zewnętrznego źródła, który omawiamy w artykule Repozytorium sury.org.

Dodatkowo warto zajrzeć do dołączonego changelogu. Jak znaleźć tam numery CVE i zapisać je jako dowód, opisuje artykuł Dowód numerów CVE w changelogu pakietu.

Typowe pułapki przy sprawdzaniu

Sprawdzony tylko jeden pakiet: PHP składa się z wielu pakietów binarnych. Jeśli php8.3-cli jest aktualny, a php8.3-fpm nie, strona pozostaje otwarta. Proszę sprawdzić wszystkie pakiety danej gałęzi, zwłaszcza FPM, CGI i moduł Apache.

Pakiet wstrzymany: Pakiety zatrzymane przez apt-mark hold pozostają przy aktualizacji bez zmian. apt-mark showhold je pokazuje.

Ubuntu Pro nieaktywne: Na 20.04 i starszych poprawki przychodzą tylko wtedy, gdy skonfigurowano Ubuntu Pro. Bez Pro system pozostaje mimo aktualizacji podatny.

Przestarzałe lustro: Jeśli serwer pobiera pakiety przez wewnętrzne lustro lub proxy, widzi nowe aktualizacje bezpieczeństwa dopiero po jego aktualizacji. W razie wątpliwości proszę sprawdzić, czy apt update rzeczywiście sięga do źródła bezpieczeństwa.

Zapomniany restart: Nowe pakiety działają dopiero po restarcie wszystkich usług, które załadowały PHP. needrestart, jeśli jest zainstalowany, pokazuje usługi ze starym kodem.

Ważne

Poprawiony stan pakietu dowodzi tylko, że luka od teraz jest zamknięta. Czy serwer był wcześniej atakowany, nie odpowiada. Proszę zabezpieczyć logi od 20 października.

Jak konkretnie pomaga PHP SOS?

  • Ustalamy dla każdego serwera pochodzenie wszystkich pakietów PHP i porównujemy stan z oficjalnymi komunikatami.
  • Instalujemy aktualizacje, także przez Ubuntu Pro, i restartujemy wszystkie dotknięte usługi.
  • Dzięki usłudze łatania PHP otrzymują Państwo dla każdego serwera dowód ze stanem pakietu, trafieniem w changelogu i czasem restartu.
  • Na systemach ze źródłami zewnętrznymi lub starymi wersjami wyjaśniamy, która droga prowadzi do udokumentowanie poprawionego stanu.

Częste pytania

Która wersja Ubuntu zawiera poprawkę PHP2Shell?

Według USN-8948-1 Ubuntu 22.04, 24.04, 26.04 i 26.10 są zaopatrzone w regularne aktualizacje. Dla 14.04, 16.04, 18.04 i 20.04 Ubuntu dostarcza poprawki według USN-8948-2 przez Ubuntu Pro.

Dlaczego Ubuntu 24.04 nadal pokazuje PHP 8.3.6?

Ubuntu przenosi poprawki bezpieczeństwa jako backport do istniejącej wersji. Numer upstream pozostaje 8.3.6, zmienia się tylko stan pakietu. Według USN-8948-1 poprawiony stan to 8.3.6-0ubuntu0.24.04.13.

Czy Debian 12 bookworm jest nadal wspierany?

Tak. Według Debian Security Tracker dla php8.2 w bookworm istnieje poprawiony stan 8.2.35-1~deb12u1, ogłoszony jako DLA-4848-1 w ramach Debian LTS.

Czy dotyczy to także PHP z repozytorium sury?

Nie. Pakiety ze źródeł zewnętrznych, takich jak sury.org, mają własne stany wersji i własne changelogi. Informacje Debiana i Ubuntu dotyczą wyłącznie ich oficjalnych pakietów.

Czy wystarczy apt upgrade?

Instaluje nowe pakiety, ale działające procesy PHP-FPM lub Apache zachowują stary kod w pamięci. Dopiero restart wszystkich usług, które ładują PHP, sprawia, że poprawka zaczyna działać.

Źródła

Kontakt natychmiast

Liczy się każda godzina. Proszę napisać do nas teraz.

Proszę krótko opisać system, wersję PHP i obserwacje. Skontaktujemy się z Państwem, ustalimy sytuację i będziemy pracować zdalnie, aż incydent zostanie zamknięty i udokumentowany.

Natychmiastowa pomoc