Stručně: Pokud php -v po aktualizaci ukazuje stejnou verzi, jde většinou o backport: Distribuce přebírá jen bezpečnostní opravu do své stávající verze PHP, číslo zůstává stejné. Ubuntu 24.04 tak dál hlásí 8.3.6, přestože je balíček proti PHP2Shell opraven. Otázku vyjasněte přes stav balíčku a changelog a navíc ověřte, zda web skutečně běží s novým kódem.
Typický okamžik po PHP2Shell
Správce nasadil aktualizaci, vše bez chyb. Pro kontrolu zadá php -v a vidí stejnou verzi jako předtím. Aktualizace nezabrala? Je server stále otevřený? Tato otázka patří od 21. října 2026 k nejčastějším.
Dobrá zpráva: Ve většině případů je všechno v pořádku. Špatná: Existují i případy, kdy stejné číslo skutečně ukazuje na problém. Tento článek pomáhá obojí rozlišit.
Proč distribuce číslo nemění
Podnikové distribuce a distribuce LTS slibují stabilitu. V rámci jednoho vydání se mají chování a rozhraní pokud možno neměnit. Skok z PHP 8.3.6 na 8.3.36 by ale přinesl řadu oprav chyb a drobných změn chování, které by mohly aplikace rušit.
Proto mnoho správců balíčků přebírá jen konkrétní bezpečnostní opravu do své stávající verze. Tento postup se nazývá backport. Verze upstreamu, kterou PHP samo hlásí přes php -v, zůstává stejná. Mění se stav balíčku, který přiděluje distribuce.
Na příkladu Ubuntu 24.04 to vypadá takto: PHP hlásí 8.3.6. Opravený stav balíčku zní podle USN-8948-1 ale 8.3.6-0ubuntu0.24.04.13. Počítá se zadní část. Debian se u PHP2Shell rozhodl jinak a pro bookworm a trixie dodal nové verze upstreamu 8.2.35 a 8.4.27. Přehled pro každé vydání stojí v článku Debian a Ubuntu: je můj balíček PHP záplatován?.
Vyplatí se takovou verzi balíčku jednou rozebrat. Na příkladu 8.3.6-0ubuntu0.24.04.13: Část před pomlčkou je verze upstreamu, tedy to, co hlásí samo PHP. Za ní následuje revize distribuce. ubuntu0.24.04 odkazuje na vydání, poslední číslo počítá úpravy. Každá bezpečnostní oprava toto číslo zvyšuje. U Ubuntu Pro se navíc objevuje dodatek jako +esm5, u bezpečnostních aktualizací Debianu dodatek jako ~deb12u1. Kdo tyto části umí číst, pozná na první pohled, zda byl balíček po bezpečnostním oznámení změněn.
Kde všude se objevuje staré číslo
Nezměněné číslo se neobjevuje jen v php -v. Stojí i na místech, která jsou viditelná zvenčí nebo je vyhodnocují nástroje:
| Místo | Co tam stojí | Důsledek |
|---|---|---|
php -v a php -i |
verze upstreamu, datum buildu | správci pochybují o aktualizaci |
| stránka phpinfo | verze upstreamu | stejný efekt v prohlížeči |
Hlavička X-Powered-By |
verze upstreamu, pokud je expose_php zapnuto |
externí skenery hlásí zranitelnost |
| Hostingové panely jako Plesk | verze upstreamu | zobrazení například 8.2.34 navzdory záplatě |
| Skenery zranitelností | porovnání podle čísla | planý poplach u backportů |
Externí skenery jsou zvláštní případ. Kdo je používá, může po PHP2Shell dostat nálezy pro servery, které byly dávno opraveny. Neignorujte tyto nálezy paušálně, ale doložte pro každý server stav balíčku a nález označte jako zkontrolovaný. Další důvod, proč údaje o verzi navenek skrývat, stojí v článku expose_php a hlavičky serveru.
Kdy je stejné číslo varovným signálem
Existují tři situace, kdy nezměněné číslo skutečně ukazuje na problém:
- Zdroj balíčků dodává verzi upstreamu. Pokud PHP pochází ze zdroje, který normálně dodává aktuální verzi upstreamu, například Debian u PHP2Shell nebo cizí zdroje jako Remi a sury.org, mělo by se po aktualizaci objevit 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35. Pokud tam stále stojí staré číslo, balíček nebyl aktualizován.
- Kontrolujete špatnou instalaci.
php -vukazuje příkazovou řádku. Pokud web běží přes jinou verzi, například z hostingového panelu nebo Software Collection, výstup o webu nic neříká. - Stav balíčku se nezměnil. Pokud je stejný i stav balíčku jako před aktualizací, aktualizace se k tomuto balíčku nedostala, například proto, že byl podržen nebo chybí zdroj.
Pro netechniky to lze shrnout takto: Číslo verze popisuje model, stav balíčku stav údržby. Dva servery se stejnou verzí PHP se mohou v bezpečnosti výrazně lišit. Neptejte se proto svého IT nebo dodavatele na verzi, ale na doklad o záplatě.
Jak to vyjasnit za pět minut
Následující příkazy jen čtou. Příklady vycházejí z Ubuntu nebo Debianu a PHP 8.3; na systémech RHEL použijte rpm -q místo dpkg-query.
# 1. Co hlásí samo PHP, včetně data buildu?
php -v
# 2. Jaký stav balíčku je nainstalován, z jakého zdroje?
apt policy php8.3-fpm
# 3. Obsahuje changelog čísla CVE?
apt changelog php8.3-fpm 2>/dev/null | grep -E "CVE-2026-10961[89]"
# 4. Od kdy běží procesy PHP webu?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Datum buildu ve výstupu php -v je náznak, ne důkaz. Spolehlivý doklad poskytuje záznam v changelogu. Jak ho najít a zaznamenat, pokud je formulován jinak nebo chybí, popisuje článek Doložení čísel CVE v changelogu balíčku.
Po každé kontrole si poznamenejte obě čísla: verzi upstreamu z php -v a stav balíčku. Kdo se později zeptá, proč má server „stále 8.3.6“, dostane jasnou odpověď.
Obecnou kontrolu přes verzi, balíček a procesy shrnuje stránka Správná kontrola verze PHP a stavu záplat.
Jak konkrétně pomáhá PHP SOS?
- U každého serveru vyjasňujeme, zda je nezměněné číslo verze backportem, nebo chybějící aktualizací.
- Vyhodnocujeme nálezy ze skenerů zranitelností a plané poplachy dokládáme stavem balíčku a changelogem.
- Kontrolujeme, kterou instalaci PHP web skutečně používá a zda byly její procesy restartovány.
- Ve službě záplatování PHP dokumentujeme verzi upstreamu a stav balíčku vedle sebe.
Časté dotazy
Je můj server nezáplatován, když php -v ukazuje staré číslo?
Ne nutně. Mnoho distribucí přebírá opravy jako backport do stávající verze. Ubuntu 24.04 například dál ukazuje 8.3.6, přestože je balíček podle USN-8948-1 opraven. Rozhodující jsou stav balíčku a changelog.
Proč můj bezpečnostní skener hlásí zranitelnost i po aktualizaci?
Mnoho skenerů čte jen číslo verze, například z hlavičky X-Powered-By. U backportů to vede k planým poplachům. Zkontrolujte stav balíčku a výsledek zdokumentujte, místo abyste nález prostě ignorovali.
Může php -v ukazovat nové číslo, zatímco web ne?
Ano. php -v ukazuje příkazovou řádku. Web může běžet přes jinou instalaci nebo přes procesy spuštěné před aktualizací. Zkontrolujte proto také službu FPM nebo Apache a jejich čas spuštění.
Pomůže datum buildu ve výstupu php -v?
Je to náznak, ne důkaz. Datum buildu po 21. říjnu 2026 odpovídá opravenému balíčku, ale nedokládá, že je oprava obsažena. Lepším dokladem je záznam v changelogu.