Krótko: Jeśli php -v pokazuje po aktualizacji tę samą wersję, przyczyną jest zwykle backport: dystrybucja przenosi tylko poprawkę bezpieczeństwa do swojej istniejącej wersji PHP, numer pozostaje ten sam. Ubuntu 24.04 zgłasza tak nadal 8.3.6, choć pakiet jest poprawiony przeciw PHP2Shell. Pytanie proszę wyjaśnić przez stan pakietu i changelog, a dodatkowo sprawdzić, czy strona rzeczywiście działa z nowym kodem.
Typowy moment po PHP2Shell
Admin zainstalował aktualizację, wszystko bez błędów. Dla kontroli wpisuje php -v i widzi tę samą wersję co wcześniej. Czy aktualizacja nie zadziałała? Czy serwer nadal jest otwarty? To pytanie należy do najczęstszych od 21 października 2026.
Dobra wiadomość: w większości przypadków wszystko jest w porządku. Zła: zdarzają się też przypadki, w których ten sam numer rzeczywiście wskazuje na problem. Ten artykuł pomaga odróżnić jedno od drugiego.
Dlaczego dystrybucje nie zmieniają numeru
Dystrybucje korporacyjne i LTS obiecują stabilność. W obrębie wydania zachowanie i interfejsy mają się możliwie nie zmieniać. Skok z PHP 8.3.6 na 8.3.36 przyniósłby jednak liczne poprawki błędów i drobne zmiany zachowania, które mogłyby zakłócić aplikacje.
Dlatego wielu opiekunów pakietów przenosi do swojej istniejącej wersji tylko konkretną poprawkę bezpieczeństwa. Ten proces nazywa się backportem. Wersja upstream, którą samo PHP zgłasza przez php -v, pozostaje ta sama. Zmienia się stan pakietu, który nadaje dystrybucja.
Na przykładzie Ubuntu 24.04 wygląda to tak: PHP zgłasza 8.3.6. Poprawiony stan pakietu brzmi jednak według USN-8948-1 8.3.6-0ubuntu0.24.04.13. Liczy się ta tylna część. Debian zdecydował przy PHP2Shell inaczej i dostarczył dla bookworm i trixie nowe wersje upstream 8.2.35 i 8.4.27. Zestawienie dla poszczególnych wydań znajduje się w artykule Debian i Ubuntu: czy mój pakiet PHP jest załatany?.
Warto raz rozłożyć taką wersję pakietu na części. Na przykładzie 8.3.6-0ubuntu0.24.04.13: część przed myślnikiem to wersja upstream, czyli to, co zgłasza samo PHP. Dalej następuje rewizja dystrybucji. ubuntu0.24.04 odsyła do wydania, ostatnia liczba zlicza poprawki. Każda poprawka bezpieczeństwa zwiększa tę liczbę. W Ubuntu Pro pojawia się dodatkowo przyrostek taki jak +esm5, w aktualizacjach bezpieczeństwa Debiana taki jak ~deb12u1. Kto potrafi czytać te części, rozpozna od razu, czy pakiet został zmieniony po komunikacie bezpieczeństwa.
Gdzie wszędzie pojawia się stary numer
Niezmieniony numer pojawia się nie tylko w php -v. Widnieje też w miejscach widocznych z zewnątrz lub analizowanych przez narzędzia:
| Miejsce | Co tam stoi | Skutek |
|---|---|---|
php -v i php -i |
wersja upstream, data kompilacji | admini wątpią w aktualizację |
| strona phpinfo | wersja upstream | ten sam efekt w przeglądarce |
nagłówek X-Powered-By |
wersja upstream, jeśli expose_php jest włączone |
zewnętrzne skanery zgłaszają lukę |
| panele hostingowe, takie jak Plesk | wersja upstream | wyświetlane na przykład 8.2.34 mimo poprawki |
| skanery podatności | porównanie według numeru | fałszywy alarm przy backportach |
Zewnętrzne skanery to osobny przypadek. Kto ich używa, może po PHP2Shell otrzymać wykrycia dla serwerów, które dawno są poprawione. Nie należy ignorować tych wykryć hurtowo, lecz udokumentować dla każdego serwera stan pakietu i odnotować wykrycie jako sprawdzone. Kolejny powód, by ukrywać informacje o wersji na zewnątrz, podaje artykuł expose_php i nagłówki serwera.
Kiedy ten sam numer jest sygnałem ostrzegawczym
Są trzy sytuacje, w których niezmieniony numer rzeczywiście wskazuje na problem:
- Źródło pakietów dostarcza wersję upstream. Jeśli PHP pochodzi ze źródła, które zwykle dostarcza aktualną wersję upstream, na przykład Debian przy PHP2Shell lub źródła zewnętrzne takie jak Remi i sury.org, po aktualizacji powinno pojawić się 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. Jeśli nadal widnieje stary numer, pakiet nie został zaktualizowany.
- Sprawdzają Państwo niewłaściwą instalację.
php -vpokazuje wiersz poleceń. Jeśli strona działa na innej wersji, na przykład z panelu hostingowego lub Software Collection, wynik nic nie mówi o stronie. - Stan pakietu się nie zmienił. Jeśli stan pakietu jest taki sam jak przed aktualizacją, aktualizacja dla tego pakietu nie dotarła, na przykład dlatego, że został wstrzymany lub brakuje źródła.
Dla nietechników można to podsumować tak: numer wersji opisuje model, a stan pakietu stan konserwacji. Dwa serwery z tą samą wersją PHP mogą się wyraźnie różnić pod względem bezpieczeństwa. Dlatego proszę pytać swój dział IT lub usługodawcę nie o wersję, lecz o dowód poprawki.
Jak wyjaśnić pytanie w pięć minut
Poniższe polecenia są wyłącznie odczytowe. Przykłady zakładają Ubuntu lub Debiana i PHP 8.3; na systemach RHEL proszę używać rpm -q zamiast dpkg-query.
# 1. Co zgłasza samo PHP, łącznie z datą kompilacji?
php -v
# 2. Jaki stan pakietu jest zainstalowany, z jakiego źródła?
apt policy php8.3-fpm
# 3. Czy changelog zawiera numery CVE?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Od kiedy działają procesy PHP strony?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Data kompilacji w wyniku php -v jest wskazówką, ale nie dowodem. Wiarygodny dowód dostarcza wpis w changelogu. Jak go znaleźć i zapisać, gdy jest sformułowany inaczej lub go brakuje, opisuje artykuł Dowód numerów CVE w changelogu pakietu.
Po każdym sprawdzeniu proszę zanotować oba numery: wersję upstream z php -v i stan pakietu. Kto później zapyta, dlaczego serwer „ma nadal 8.3.6”, otrzyma w ten sposób jasną odpowiedź.
Ogólne sprawdzenie przez wersję, pakiet i procesy podsumowuje strona Prawidłowe sprawdzanie wersji PHP i stanu poprawek.
Jak konkretnie pomaga PHP SOS?
- Wyjaśniamy dla każdego serwera, czy niezmieniony numer wersji to backport, czy brakująca aktualizacja.
- Oceniamy wykrycia ze skanerów podatności i dokumentujemy fałszywe alarmy stanem pakietu i changelogiem.
- Sprawdzamy, której instalacji PHP strona faktycznie używa i czy jej procesy zostały zrestartowane.
- W ramach usługi łatania PHP dokumentujemy wersję upstream i stan pakietu obok siebie.
Częste pytania
Czy mój serwer jest niezałatany, jeśli php -v pokazuje stary numer?
Niekoniecznie. Wiele dystrybucji przenosi poprawki jako backport do istniejącej wersji. Ubuntu 24.04 pokazuje na przykład nadal 8.3.6, choć pakiet jest według USN-8948-1 poprawiony. Decydujące są stan pakietu i changelog.
Dlaczego mój skaner bezpieczeństwa zgłasza lukę mimo aktualizacji?
Wiele skanerów odczytuje tylko numer wersji, na przykład z nagłówka X-Powered-By. Przy backportach prowadzi to do fałszywych alarmów. Proszę sprawdzić stan pakietu i udokumentować wynik, zamiast po prostu ignorować wykrycie.
Czy może być tak, że php -v pokazuje nowy numer, a strona nie?
Tak. php -v pokazuje wiersz poleceń. Strona może działać przez inną instalację lub przez procesy uruchomione przed aktualizacją. Proszę więc sprawdzić także usługę FPM lub Apache i czas ich startu.
Czy pomaga data kompilacji w wyniku php -v?
To wskazówka, ale nie dowód. Data kompilacji po 21 października 2026 pasuje do poprawionego pakietu, ale nie dowodzi, że poprawka jest zawarta. Lepszym dowodem jest wpis w changelogu.