Kritická chyba v PHP: aktualizujte co nejdřív

Co se stalo

PHP 21. 10. 2026 zveřejnilo dvě chyby v práci s pamětí. První (CVE-2026-109618) se projeví, když požadavku dojde paměť, druhá (CVE-2026-109619) nechává data z jednoho požadavku přežít do dalšího. Obě podle bezpečnostního oznámení PHP vedou ke spuštění cizího kódu pod účtem, pod kterým běží web.

Ohrožené je každé PHP, které obsluhuje webové požadavky: PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP i LiteSpeed. Nejhorší je to u Apache s mod_php. Tam autoři chyby předvedli útok jediným požadavkem, který proběhne dřív, než se spustí kód vašeho webu. Na redakčním systému tedy nezáleží, týká se to WordPressu i čehokoli jiného na PHP.

Jak zareagovaly úřady a velké weby

NÚKIB doporučil provozovatelům webů a služeb s PHP aktualizovat okamžitě. Evropský tým CERT-EU radí totéž a kde to nejde, doporučuje weby do aktualizace odpojit od internetu. Podle něj už kolují první ukázky útoku, takže je pravděpodobné, že se chyby zneužívají. V katalogu skutečně zneužívaných chyb americké agentury CISA (KEV) ale k 21. 10. 2026 nebyly.

Řada institucí proto weby raději na čas vypnula, než stihla PHP aktualizovat:

• Úřad vlády ČR odstavil web vlády 21. 10. 2026 v 19:00. Po 21. hodině byl znovu v provozu (ČTK).
• Drážní úřad měl kvůli aktualizacím weby několik desítek minut mimo provoz (ČTK).
• Český hydrometeorologický ústav dočasně vypnul některé své weby, například hydro.chmi.cz (Deník N).
• V zahraničí podle přehledu agentury Reuters vypnulo weby německé vládní IT centrum ITZBund, francouzské ministerstvo vnitra (weby prefektur), belgické ministerstvo zahraničí a finské státní IT centrum Valtori (veřejné služby vlády). V Nizozemsku šly podle příkladu tamního centra kybernetické bezpečnosti mimo provoz třeba Overheid.nl, přístav Rotterdam, fotbalový svaz KNVB a weby nemocnic. Část systémů vypnula i nadace Wikimedia.

Pro majitele menších webů z toho plyne hlavně jedno: kdo má vlastní server, neměl by s aktualizací čekat.

Koho se to týká

Co hlásí české hostingy

U hostingů, které srovnáváme, jsme prošli weby a stavové stránky. Stav k večeru 21. 10. 2026:

VPS a vlastní server

Linuxové distribuce dostaly opravy předem. Stačí aktualizovat balíčky a restartovat všechno, co PHP spouští:

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # podle vaší verze, případně apache2

Příkaz php -v ukazuje PHP pro příkazovou řádku, web může běžet na jiné verzi. Verzi, kterou používá web, zjistíte třeba příkazem php-fpm8.3 -v (podle vaší verze) nebo stránkou s phpinfo(), kterou po kontrole smažte. U balíčků z distribuce navíc číslo verze zůstává původní a opravu v něm nepoznáte. Verzi balíčku zjistíte příkazem dpkg -l | grep php a porovnáte s tabulkou:

Podle bezpečnostních stránek Debianu a Ubuntu k 21. 10. 2026. Pokud máte PHP z jiného repozitáře (třeba balíčky Ondřeje Surého), potřebujete verzi 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35 a novější.

Jistější je seznam změn v balíčku. Když v něm najdete číslo chyby, oprava je nainstalovaná:

apt changelog php8.3-fpm | grep CVE-2026-109618   # Debian a Ubuntu
rpm -q --changelog php | grep CVE-2026-109618      # Red Hat, AlmaLinux, Rocky

PHP 8.1 a starší už PHP samo neopravuje. Pro 7.4, 8.0 a 8.1 vydalo jen minimální opravy zdrojového kódu pro ty, kdo si PHP kompilují sami. Rozumnější je přejít na podporovanou verzi. Pozor i na PHP 8.2: opravy zabezpečení pro něj končí 31. 12. 2026, takže když už verzi měníte, zvolte rovnou 8.3 nebo novější.

Docker

Oficiální obrazy php na Docker Hubu jsou s opravenými verzemi přestavěné od 21. 10. 2026 (například php:8.4-fpm obsahuje 8.4.27). Kontejner se ale sám neaktualizuje. Obraz musíte stáhnout znovu, vlastní obrazy na něm postavené přestavět a kontejnery spustit znovu:

docker compose pull
docker compose build --pull
docker compose up -d

Pozor na obrazy připnuté na konkrétní verzi nebo otisk (třeba php:8.4.26-fpm nebo @sha256:…), ty zůstanou zranitelné, dokud verzi nezměníte. Totéž platí pro obrazy třetích stran, které PHP obsahují uvnitř (WordPress, Nextcloud a podobně). Zkontrolujte, jestli autor vydal nový obraz.

Coolify

Samotné Coolify běží na PHP, takže je potřeba aktualizovat i jeho. Opravu s PHP 8.4.27 obsahuje verze 4.4.7 a pro starší řady verze 4.3.24, 4.2.1, 4.1.3 a 4.0.1. Autoři doporučují aktualizovat hned, na serveru tímto skriptem:

curl -fsSL https://cdn.coollabs.io/coolify/patch.sh | sudo bash

Aktualizace Coolify neopraví aplikace, které v něm provozujete. Každou aplikaci na PHP (Laravel, WordPress a další) přestavte znovu, aby si stáhla nový obraz PHP. Na jakých VPS Coolify poběží a co dalšího hlídat, popisuje stránka Coolify hosting.

Ochrana přes Cloudflare

Pokud web běží přes Cloudflare (s oranžovým mráčkem v nastavení DNS), Cloudflare od 21. 10. 2026 blokuje známé pokusy o útok na tyto chyby pravidly ve firewallu (WAF). Na tarifu Free jsou pravidla zapnutá automaticky. Na placených tarifech Pro, Business a Enterprise zkontrolujte, že je Cloudflare Managed Ruleset nastavený na blokování. Zachycené požadavky uvidíte v Security › Security Analytics › Events.

Je to jen další vrstva ochrany. Cloudflare sám píše, že aktualizaci PHP nenahradí, a provoz, který jde na server mimo Cloudflare (třeba přímo na IP adresu nebo na administraci Coolify), nechrání vůbec.

Když nemůžete aktualizovat hned

PHP uvádí několik nastavení, která omezí známé způsoby útoku. Server ale nezabezpečí, jen dají čas do aktualizace:

• memory_limit=-1 nastavte tak, aby ho aplikace nemohla přepsat (například php_admin_value v poolu FPM nebo v konfiguraci Apache).
• post_max_size snižte na 8M, nebo 32M, pokud web přijímá nahrávané soubory.
• session.upload_progress.enabled=0 nastavte v php.ini nebo v poolu FPM, ne přes ini_set() nebo .user.ini.
• Na PHP 8.5 navíc nastavte fatal_error_backtraces=0.
• Po každé změně restartujte všechny procesy PHP.

Pokud web raději na čas vypnete, jak to udělaly úřady, nevracejte chybu 404 ani 500. John Mueller z Googlu doporučuje odpovídat stavovým kódem 503, nejlépe mimo PHP, třeba na úrovni webového serveru nebo CDN. Vyhledávač pak ví, že jde o dočasnou odstávku.

Nepoužívejte omezení RLIMIT_AS ani RLIMIT_DATA, podle PHP chybu naopak spouští.

Nechcete server hlídat sami?

U takové chyby je rozdíl vidět nejlíp: na webhostingu a na serveru se správou ji vyřeší hosting a vy nemusíte nic dělat. Pokud vlastní VPS potřebujete jen kvůli jednomu webu, zvažte běžný webhosting. Porovnání cen najdete ve srovnání webhostingů, VPS ve srovnání nejlevnějších VPS. Webglobe nabízí i server se správou, o jehož aktualizace se stará sám.

Zdroje

• Bezpečnostní oznámení na php.net
• CVE-2026-109618: RCE via OOM corruption
• CVE-2026-109619: RCE via stale global state
• Debian security tracker a Ubuntu
• Coolify v4.4.7
• Cloudflare: ochrana WAF proti chybám v PHP

Časté dotazy

Musím na webhostingu něco dělat?

Instalovat nic nemusíte, PHP na sdíleném webhostingu aktualizuje hosting. Jen v administraci zkontrolujte, že web běží na PHP 8.2 nebo novějším. Starší verze už PHP neopravuje a podpora PHP 8.2 končí 31. 12. 2026, takže rovnou zvolte 8.3 nebo novější.

Týká se to WordPressu?

Ano, pokud běží na neopravené verzi PHP. Chyba je v PHP, ne ve WordPressu, takže aktualizace WordPressu ani pluginů ji neopraví.

Jak poznám, že mám opravenou verzi?

U PHP z oficiálních zdrojů podle čísla verze: 8.5.12, 8.4.27, 8.3.36, 8.2.35 a novější. U balíčků z Debianu a Ubuntu podle verze balíčku v tabulce výše, protože php -v tam ukazuje původní číslo.

Stačí restartovat server?

Ne. Restart jen znovu spustí starou verzi. Nejdřív aktualizujte balíčky nebo obraz, pak restartujte.

Co je PHP2Shell?

Přezdívka, pod kterou se o obou chybách píše. Oficiálně jde o CVE-2026-109618 a CVE-2026-109619.