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

> Czy pakiet PHP w Debianie lub Ubuntu jest załatany przeciw PHP2Shell? Poprawione stany pakietów dla wydań, polecenia kontrolne i typowe pułapki dla adminów.

Źródło: https://phpsos.de/pl/blog/debian-ubuntu-paket-gepatcht/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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](https://phpsos.de/pl/php2shell/php-version-pruefen/).

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](https://phpsos.de/pl/blog/php-v-zeigt-alte-nummer/). 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.

```bash
# 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](https://phpsos.de/pl/blog/sury-repository-php/).

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](https://phpsos.de/pl/blog/cve-im-changelog-nachweisen/).

## 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](https://phpsos.de/pl/leistungen/php-patch-service/) 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

- [Ubuntu Security Notice USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Debian Security Tracker: CVE-2026-109618](https://security-tracker.debian.org/tracker/CVE-2026-109618)
- [Debian Security Tracker: CVE-2026-109619](https://security-tracker.debian.org/tracker/CVE-2026-109619)