Krótko: Aby sprawdzić CVE w changelogu, proszę przeszukać dziennik zmian zainstalowanego pakietu PHP pod kątem CVE-2026-109618 i CVE-2026-109619: w Debianie i Ubuntu w /usr/share/doc/<paket>/changelog.Debian.gz, w systemach RPM poleceniem rpm -q --changelog. Trafienie wraz ze stanem pakietu, porównaniem z oficjalnym komunikatem bezpieczeństwa i czasem restartu daje rzetelny dowód. Brak trafienia nie jest jeszcze dowodem otwartej luki.
Dlaczego dowód to coś więcej niż „załatane”
Po PHP2Shell wielu chce wiedzieć, czy ich serwery są bezpieczne: zarząd, inspektor ochrony danych, klienci z umową powierzenia przetwarzania, czasem ubezpieczyciel cybernetyczny. Samo „załataliśmy” to na to za mało. Potrzebny jest dowód, który osoba trzecia może zweryfikować.
Numer wersji często się do tego nie nadaje, ponieważ dystrybucje wprowadzają poprawki jako backport, a numer pozostaje taki sam. Lepszą podstawą jest changelog pakietu. Pisze go opiekun pakietu i przy aktualizacjach bezpieczeństwa zwykle wymienia usunięte numery CVE.
Gdzie leżą changelogi
Każdy format pakietów ma własne miejsce. Poniższe zestawienie pomaga szybko trafić we właściwe.
| System | Miejsce changelogu | Polecenie do przeszukania |
|---|---|---|
| Debian, Ubuntu | /usr/share/doc/<paket>/changelog.Debian.gz |
zgrep |
| Debian, Ubuntu (online) | archiwum pakietów dystrybucji | apt changelog <paket> |
| RHEL, AlmaLinux, Rocky, Fedora | baza pakietów RPM | rpm -q --changelog <paket> |
| Obrazy kontenerów | w obrazie, tak jak w systemie bazowym | wykonać polecenie w kontenerze |
W Debianie i Ubuntu katalog dokumentacji niektórych pakietów binarnych wskazuje dowiązaniem symbolicznym na wspólny pakiet, na przykład php8.3-common. Jeśli zgrep nie znajduje pliku, proszę obejrzeć katalog poleceniem ls -l /usr/share/doc/ | grep php.
Sprawdzanie CVE w changelogu: jak postępować
Poniższe polecenia tylko odczytują dane. Nazwy pakietów proszę dostosować do swojej instalacji.
# Debian/Ubuntu: lokalnie, bez sieci
zgrep -n -E "CVE-2026-10961[89]|CVE-2026-115560" /usr/share/doc/php8.3-common/changelog.Debian.gz
# Debian/Ubuntu: nagłówek najnowszego wpisu ze stanem pakietu i datą
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | head -20
# Rodzina RHEL: wpis wraz z datą i stanem pakietu
rpm -q --changelog php-common | grep -n -B3 -E "CVE-2026-10961[89]"
W Debianie i Ubuntu stan pakietu stoi w wierszu nagłówkowym każdego wpisu, data w wierszu końcowym. W RPM jedno i drugie stoi w wierszu nad wpisami. Dzięki temu widać nie tylko, czy CVE jest wspomniana, ale także przy jakim stanie pakietu. Ten stan proszę porównać z zainstalowanym, na przykład przez dpkg-query -W lub rpm -q. Jeśli oba się zgadzają, poprawka jest zawarta w działającym pakiecie.
Pakiety paneli i kontenery
Panele hostingowe, takie jak Plesk czy cPanel, mają własne pakiety PHP. One również są zwykłymi pakietami DEB lub RPM, a ich changelog można czytać tymi samymi narzędziami. To, czy dostawcy podają w nim numery CVE, czy tylko nową wersję PHP, bywa różne. Jeśli pakiet podaje wersję upstream 8.5.12, 8.4.27, 8.3.36 lub 8.2.35, wystarcza to jako dowód; przy backportach ze starym numerem potrzebna jest informacja od dostawcy.
W kontenerach dowód należy do obrazu, a nie do hosta. Proszę sprawdzić pakiety w obrazie, z którego uruchomiono działający kontener, i dodatkowo zapisać digest obrazu. Dzięki temu później da się prześledzić, jaki stan faktycznie działał, nawet jeśli obraz pod tym samym tagiem został w międzyczasie zbudowany na nowo.
Gdy CVE brakuje w changelogu
Brakujący wpis może mieć kilka przyczyn. Proszę je przejść w tej kolejności:
- Przeszukano zły pakiet: Przy kilku gałęziach PHP lub źródłach na jednym serwerze odpowiedź często leży w changelogu innego pakietu.
- Wersja upstream zamiast CVE: Jeśli źródło dostarcza nową wersję upstream, na przykład 8.4.27, w changelogu może stać tylko „New upstream version”. Wtedy dowodem jest sam numer wersji, ponieważ php.net podaje wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35 jako poprawione.
- Inne sformułowanie: Niektórzy opiekunowie podają numery błędów lub identyfikatory advisory, takie jak GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp, zamiast CVE.
- Porównanie z komunikatem bezpieczeństwa: Jeśli oficjalny komunikat Państwa dystrybucji, na przykład USN lub Debian Security Tracker, podaje poprawiony stan pakietu, a zainstalowany jest ten lub nowszy, to również jest dowód. Stany dla Debiana i Ubuntu znajdą Państwo w artykule Czy mój pakiet PHP jest załatany?, dla rodziny RHEL w RHEL, AlmaLinux i Rocky Linux.
- Zapytać dostawcę: W przypadku pakietów paneli, buildów dostawców hostingu lub źródeł zewnętrznych pomaga tylko pisemna informacja. Wzór oferuje poradnik Zapytanie dostawcy hostingu o status poprawek.
Jeśli po tych krokach nie ma żadnego dowodu, proszę traktować serwer jako niezałatany i zastosować środki przejściowe, aż sprawa zostanie wyjaśniona.
Od trafienia do dowodu
Trafienie w changelogu dowodzi, że pakiet zawiera poprawkę. Nie dowodzi, że korzystają z niej działające procesy. Pełny dowód zawiera dlatego pięć informacji dla każdego serwera i instalacji PHP:
- serwer, gałąź PHP i tryb pracy, na przykład PHP-FPM lub mod_php
- zainstalowany stan pakietu i źródło pakietu
- miejsce w changelogu lub odnośnik do oficjalnego komunikatu bezpieczeństwa
- moment aktualizacji i czas startu działających procesów PHP
- imię i nazwisko osoby sprawdzającej oraz data kontroli
Proszę zapisać surowe wyniki poleceń jako plik tekstowy obok dowodu. Później łatwiej je zweryfikować niż streszczenie z pamięci.
Dowód odpowiada tylko na pytanie, czy luka była zamknięta od określonego momentu. Dla okresu wcześniejszego potrzebne są logi od 20 października 2026 i w razie potrzeby poszukiwanie śladów. Ogólny przebieg sprawdzania wersji opisuje strona Prawidłowe sprawdzanie wersji PHP i stanu poprawek.
Jak konkretnie pomaga PHP SOS?
- Przeszukujemy changelogi wszystkich pakietów PHP na Państwa serwerach i porównujemy je z oficjalnymi komunikatami bezpieczeństwa.
- Tam, gdzie changelogi milczą, wyjaśniamy stan z dystrybucją, dostawcą panelu lub dostawcą hostingu.
- Kontrolujemy, czy działające procesy zostały po aktualizacji zrestartowane.
- W ramach usługi PHP-Patch-Service otrzymują Państwo dowód dla każdego serwera w formie, którą można przekazać osobom trzecim.
Częste pytania
Dlaczego wersja PHP nie wystarcza jako dowód?
Wiele dystrybucji przejmuje poprawki bezpieczeństwa jako backport, nie zmieniając wersji PHP. Numer wersji nic wtedy nie mówi o poprawce. Changelog zainstalowanego pakietu wymienia natomiast usunięte numery CVE.
Co oznacza brak CVE w changelogu?
Może to znaczyć, że poprawki brakuje. Może jednak być i tak, że opiekun pakietu sformułował wpis inaczej, na przykład podając numer błędu lub wersję upstream. Wtedy porównują Państwo stan pakietu z oficjalnym komunikatem bezpieczeństwa albo pytają dostawcę.
Jak długo powinienem przechowywać dowód?
Tak długo, jak może być istotny dla kontroli wewnętrznych, ubezpieczycieli lub ewentualnych pytań z zakresu ochrony danych. Proszę go archiwizować razem z logami od 20 października 2026. Konkretne terminy należy ustalić z inspektorem ochrony danych lub doradcą prawnym.
Czy mogę sprawdzić changelog także bez dostępu do internetu?
Tak. Debian i Ubuntu przechowują changelog każdego pakietu lokalnie w /usr/share/doc, systemy RPM zapisują go w bazie pakietów. Oba źródła można odczytać bez sieci.