Stručně: Kdo si chce nechat nasadit aktualizaci PHP, potřebuje víc než nové balíčky: rozhodující je správný stav balíčku, restart všech procesů PHP a doklad o tom. Právě to dodává naše služba záplatování PHP. Obdržíte písemný doklad pro každý server, který můžete předložit interně nebo třetím stranám.
Proč samotná aktualizace PHP často nestačí
Od 21. 10. 2026 existují záplaty pro zranitelnosti PHP2Shell CVE-2026-109618 a CVE-2026-109619. BSI (německý Spolkový úřad pro informační bezpečnost) doporučuje okamžitou aktualizaci. V praxi vidíme tři typické překážky.
Zaprvé číslo verze nemusí vždy ukazovat skutečný stav. Distribuce a poskytovatelé hostingu někdy nasazují backporty; Plesk pak například dál hlásí 8.2.34, přestože je balíček záplatovaný. Zadruhé po nasazení často dál běží staré procesy PHP. Nové soubory na disku nechrání, dokud staří workeři pracují v paměti. Zatřetí na serveru často běží paralelně několik verzí PHP a jedna z nich se zapomene.
Aktualizace PHP na klíč: opravené verze
| Větev | Opraveno od | Předchozí stav | Poznámka |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | navíc zkontrolovat fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | podpora končí 31. 12. 2026 |
| PHP 8.1 a starší | žádné oficiální aktualizace | – | jen minimální zdrojové backporty pro 7.4, 8.0, 8.1 |
U balíčků z distribucí nebo od poskytovatelů hostingu nerozhoduje číslo za slovem „PHP“, ale stav balíčku, který poskytovatel potvrdí jako záplatovaný. Jak to ověřit sami, najdete na stránce Jak správně ověřit verzi PHP a stav záplaty.
Jak konkrétně pomáhá PHP SOS?
- Inventura: Zjistíme všechny instalace PHP na serveru, provozní režim (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) a to, který web používá kterou verzi.
- Nasazení aktualizace: Nainstalujeme opravené verze ze zdroje balíčků vaší distribuce, vašeho panelu nebo oficiálního projektu. U kontejnerů s vámi sestavíme nové image.
- Restart všech procesů: PHP-FPM, Apache, LiteSpeed nebo příslušné workery úplně restartujeme a ověříme, že žádný proces není starší než aktualizace. Souvislosti najdete na stránce Restart PHP-FPM a všech workerů.
- Kontrola funkčnosti: Otevřeme nejdůležitější stránky a funkce, například úvodní stránku, přihlášení, formuláře a pokladnu, a zkontrolujeme chybové protokoly.
- Doklad: Obdržíte pro každý server protokol s verzí, stavem balíčku, časem restartu a otevřenými body.
Typický kontrolní krok po restartu vypadá takto:
# Verze PHP CLI a binárky FPM (cesta podle systému)
php -v
php-fpm8.3 -v
# Doba spuštění procesů FPM: musí být po aktualizaci
ps -o pid,lstart,cmd -C php-fpm8.3
Zvláštní případy: panely, kontejnery a více verzí PHP
Na serverech s Pleskem nebo cPanelem pocházejí verze PHP často ze zdrojů balíčků panelu, ne z distribuce. Tam kontrolujeme každou nainstalovanou verzi zvlášť, i ty, které právě nejsou přiřazeny žádnému webu. Nepoužívané, zastaralé verze po dohodě odstraníme, aby se omylem znovu neaktivovaly.
V prostředích Dockeru a Kubernetes nestačí aktualizace na hostiteli. PHP je v image a zranitelnost uzavře až nově sestavený image se záplatovaným základem, nasazený na všechny běžící kontejnery. Zároveň kontrolujeme, zda se v registrech nebo nasazeních stále nepoužívají starší image. Podrobnosti najdete na stránce Záplatování PHP v kontejnerech Dockeru.
U mod_php běží PHP přímo v procesu Apache. Tým PHP tam hodnotí riziko jako nejvyšší. Po aktualizaci proto musí být Apache úplně restartován; pouhé znovunačtení konfigurace nemusí vždy stačit.
Co od nás získáte
- protokol záplat pro každý server: nainstalované balíčky, verze, zdroj, čas
- doklad, že všechny procesy PHP byly restartovány
- seznam zkontrolovaných webů a funkcí
- upozornění na systémy, které nebylo možné záplatovat, s odůvodněním
- doporučení dalšího postupu, například u PHP 8.2 kvůli blížícímu se konci podpory
Co potřebujeme od vás
- Přístup: SSH s administrátorskými právy nebo přístup do panelu (Plesk, cPanel apod.)
- Servisní okno: kdy smí proběhnout krátký restart
- Kontaktní osoba: pro dotazy a pro schválení po kontrole funkčnosti
- Zálohy: potvrzení, že existuje aktuální záloha, nebo zadání, aby se předtím vytvořila
- Upozornění na vlastní vývoj: zvláštní rozšíření PHP nebo konfigurace, které je nutné zohlednit
U sdíleného hostingu bez vlastního přístupu k serveru sami záplatovat nemůžeme. Pomůžeme vám pak položit poskytovateli hostingu správné otázky a vyhodnotit odpověď.
Co neslibujeme
Služba záplatování uzavírá známou zranitelnost. Neodpovídá na otázku, zda byl server kompromitován už před aktualizací, a neodstraňuje vložený škodlivý software. Pokud to chcete vědět, je vhodnou zakázkou okamžitá pomoc při PHP2Shell s hledáním stop.
Pro PHP 8.1 a starší už oficiální aktualizace neexistují. Zde nasadíme přechodná opatření a doporučíme migraci na podporovanou verzi. Slib kompatibility s vaším CMS nedáváme z paměti, ale ověřujeme ho podle systémových požadavků výrobce.
Časté dotazy
Proč můj server po aktualizaci stále ukazuje starou verzi PHP?
Mohou za to dva důvody. Buď distribuce nasadila backport, pak číslo verze zůstane stejné, přestože je balíček záplatovaný. Nebo ještě běží staré procesy PHP v paměti a je nutné je restartovat.
Které verze PHP uzavírají PHP2Shell?
Zranitelnost je opravena v PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35, vydaných 21. 10. 2026. U balíčků distribucí rozhoduje stav balíčku, který poskytovatel potvrdí jako záplatovaný.
Může aktualizace můj web vyřadit z provozu?
Aktualizace v rámci stejné hlavní verze, například z 8.3.35 na 8.3.36, je zpravidla nekritická. Krátký restart procesů PHP je ale nutný. Časové okno s vámi dohodneme a poté stránky zkontrolujeme.
Je záplatou všechno vyřešeno?
Pokud jde o samotnou zranitelnost, ano, jakmile jsou všechny procesy restartovány. Zda se někdo dostal dovnitř už před záplatou, záplata neukáže. K tomu je třeba samostatná kontrola.