Kritické zranitelnosti v PHP (php2shell): jak aktualizovat krok za krokem

Vývojáři PHP 21. října 2026 vydali opravy dvou kritických zranitelností, přes které může útočník bez přihlášení spustit na serveru vlastní kód. Aktualizujte proto PHP na opravenou verzi (8.5.12, 8.4.27, 8.3.36 nebo 8.2.35), případně na opravený balíček od své distribuce. Pak restartujte všechny služby, ve kterých PHP běží. Bez restartu totiž server dál pracuje se starým kódem.

Informace jsou aktuální k 22. říjnu 2026. Článek vychází z veřejně dostupných zdrojů. Situace se mění každý den, proto u důležitých údajů odkazujeme na zdroj.

Co se stalo a proč je to vážné?

Tentokrát nejde o chybu ve WordPressu ani v jiné aplikaci. Chyby jsou přímo v PHP, na kterém web běží. Útočník se nikam přihlašovat nemusí. Stačí mu poslat vhodně připravený požadavek a může na serveru spustit vlastní kód. Kód pak běží se stejnými právy jako samotný web. Útočník tedy může všechno, co může web: třeba číst data z databáze nebo měnit stránky.

Chyby mají označení CVE-2026-109618 a CVE-2026-109619, v médiích se jim říká php2shell. Vývojáři PHP je popisují zhruba takhle:

• První chyba (CVE-2026-109618) souvisí s nedostatkem paměti. PHP se zastaví uprostřed zpracování požadavku a později zachází s rozpracovanými daty, jako by byla v pořádku.
• U druhé (CVE-2026-109619) zůstanou údaje z jednoho požadavku v paměti i po jejím uvolnění. Pak na ně může narazit další požadavek, který obslouží stejný proces.

Nejvíc ohrožené jsou servery s Apachem a modulem mod_php. Právě tam se podle bezpečnostního upozornění PHP podařilo kód spustit už ve výchozím nastavení. Zranitelné je ale PHP v jakékoli podobě, která obsluhuje web, tedy i PHP-FPM, php-cgi, FrankenPHP nebo LiteSpeed.

Obě chyby mají podle bezpečnostního týmu PHP závažnost 9,2 z 10 na stupnici CVSS 4.0. Den předem tým ohlásil, že opravy vyjdou ve středu 21. října v 16:00 našeho času.

Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) 21. října vyzval k okamžité aktualizaci. Upozornil také, že informace o tom, jak chyby zneužít, jsou veřejně dostupné.

Úřad vlády dokonce své weby preventivně odpojil, a to od 21. října v 19:00 do 8:00 druhého dne, jak píše server Lupa.cz.

Zneužívají už útočníci tyhle chyby? K 22. říjnu se zprávy rozcházejí.

Amazon podle Tenable zachytil první pokus už 17. října, tedy čtyři dny před zveřejněním oprav, a tvrdí, že se chyby zneužívají ve velkém. Podle téhož zdroje se ale zatím nepotvrdilo, že veřejně šířený exploit funguje.

Podle Patchstacku nahlásili hostingoví partneři a Cloudflare první útoky už 21. října krátce po půl desáté ráno našeho času, tedy ještě před vydáním oprav. Odpoledne ovšem Patchstack ve vlastních datech viděl jen to, že útočníci zkoušejí, jestli jsou servery zranitelné. Doložený průnik nenašel žádný.

Firma Huntress do večera 21. října u svých partnerů žádné zneužití nezaznamenala. Bezpečnostní firma Rapid7 útoky očekává, potvrzené je ale zatím nemá.

Pro vás z toho plyne jediné: nečekejte, až se zdroje shodnou, a aktualizujte co nejdřív. Samotný WordPress aktualizovat nemusíte, tentokrát by to nepomohlo. Opravit je potřeba PHP na serveru.

Jak zjistit, jestli je vaše PHP zranitelné?

Zranitelné jsou všechny verze starší než opravené. Přehled podle záznamu v databázi NVD:

PHP 8.1 a starším se věnujeme v samostatné části níž. Zdroje se ovšem neshodnou v tom, jak daleko do minulosti chyby sahají. Vývojáři PHP uvádějí jen řady 8.2 až 8.5, podle Google Cloud jsou ale zasažené všechny verze od 5.4. Starší PHP proto berte jako zranitelné.

Verzi PHP zjistíte takhle:

• Ve WordPressu otevřete Nástroje a Stav webu, přejděte na záložku Informace a rozbalte část Server.
• Na hostingu verzi obvykle najdete v administraci.
• Na vlastním serveru zadejte do terminálu php -v.

Pozor na jednu věc. Rozhoduje verze, se kterou běží web. Příkazový řádek totiž může na stejném serveru ukázat jinou, protože web a terminál nemusí používat stejné PHP.

Samotné číslo verze navíc nemusí stačit. Některé distribuce, například Ubuntu nebo RHEL, přenášejí opravy zpětně do svých starších balíčků. PHP tak může být opravené, i když dál hlásí staré číslo verze.

Třeba Ubuntu 24.04 LTS má opravu v balíčku 8.3.6-0ubuntu0.24.04.13, ne ve verzi 8.3.36. Nestačí tedy hledat číslo 8.3.36. Porovnejte celé označení balíčku s bezpečnostním oznámením své distribuce, jak ukazujeme v další části.

Jak PHP aktualizovat podle toho, kde web běží?

Postup záleží na tom, kdo se vám o server stará. Máte web na sdíleném hostingu? Pak vám stačí první část, zbytek je pro správce vlastních serverů. Na konci každé části najdete kontrolu, jestli aktualizace zabrala.

Pokud máte víc prostředí, třeba e-shop na hostingu a k tomu vlastní testovací server, projděte postup pro každé zvlášť.

Sdílený a spravovaný hosting (Plesk, cPanel)

Na sdíleném hostingu aktualizuje PHP poskytovatel, vy sami to neovlivníte. V administraci si můžete vybrat jen z verzí, které hosting na serveru nainstaloval. Dokud opravenou verzi nenainstaluje, v nabídce ji nenajdete.

1. Zjistěte verzi PHP, jak popisujeme výš.
1. Napište hostingu a zeptejte se, jestli už PHP aktualizoval, a pokud ne, kdy to udělá.
1. Odpověď si schovejte. Písemné potvrzení od hostingu doporučuje i česká firma DataStorm.
1. Neinstalujte pluginy ani kousky kódu, které slibují opravu. Patchstack před nimi výslovně varuje.

Hostingu můžete poslat třeba tuhle zprávu:

Dobrý den, potvrďte mi prosím, že PHP u domény vasedomena.cz už obsahuje opravy zranitelností CVE-2026-109618 a CVE-2026-109619 z 21. 10. 2026. Pokud ještě ne, kdy aktualizaci plánujete? Děkuji.

Podle přehledu z 22. října už výrobci panelů cPanel a Plesk vydali opravené balíčky, a to pro řady 8.2 až 8.5 i pro starší 7.4, 8.0 a 8.1. To ale neznamená, že je váš hosting už nainstaloval. Ptejte se proto přímo hostingu.

Kontrola: až hosting aktualizaci potvrdí, podívejte se znovu na verzi ve WordPressu nebo v administraci hostingu.

Debian a Ubuntu

Na Debianu a Ubuntu máte PHP buď z balíčků distribuce, nebo z repozitářů Ondřeje Surého, tedy z PPA ondrej/php nebo z packages.sury.org.

Distribuce dostaly opravy od vývojářů PHP s předstihem. Opravené balíčky ale mají vlastní čísla verzí:

Ubuntu opravy oznámilo 21. října v bezpečnostních oznámeních USN-8948-1 a USN-8948-2.

Debian vydal opravené balíčky v bezpečnostním archivu jako DLA-4848-1 a DSA-6574-1. V běžném archivu se bookworm a trixie 22. října ještě vedly jako zranitelné.

Následující postup vychází z návodu Laravel Forge pro Ubuntu a počítá s PHP 8.4. Pokud máte jinou řadu, číslo 8.4 v příkazech nahraďte svým.

1. Pokud máte PHP z repozitářů Ondřeje Surého, zkontrolujte, že ve složce /etc/apt/sources.list.d/ je jejich soubor.
1. Obnovte seznamy balíčků příkazem sudo apt update. Když se apt zeptá, jestli přijmout změnu u repozitáře, potvrďte ji.
1. Zjistěte, jakou verzi apt nabízí: apt-cache policy php8.4-fpm. Na řádku Candidate musí být opravená verze.
1. Vypište nainstalované balíčky PHP 8.4: dpkg -l | grep php8.4.
1. Aktualizujte je jedním příkazem a vyjmenujte v něm všechny z předchozího výpisu, třeba sudo apt install php8.4-fpm php8.4-cli php8.4-mysql. Balíček, který už máte, se tím jen aktualizuje.
1. Když se apt zeptá, jestli přepsat php.ini nebo konfiguraci PHP-FPM, ponechte stávající soubor. Stačí potvrdit výchozí odpověď N.

Když řádek Candidate opravenou verzi ještě neukazuje, chvíli počkejte a zkuste to znovu. Do repozitářů Ondřeje Surého se opravy podle Forge obvykle dostanou krátce po vydání. Podle mysites.guru ale v jeho PPA opravené balíčky ještě 21. října chyběly. Apt navíc kvůli změně v popisu repozitáře odmítal seznamy balíčků obnovit.

Kontrola: spusťte znovu apt-cache policy php8.4-fpm. Na řádku Installed musí být stejná verze jako na řádku Candidate a ta musí odpovídat tabulce výš nebo bezpečnostnímu oznámení vaší distribuce.

RHEL, AlmaLinux a Rocky Linux

Repozitář Remi, který spravují dobrovolníci, podle vývojářů PHP v den vydání opravené balíčky ještě neměl. Jeho uživatelům proto doporučili přejít na balíčky distribuce nebo si PHP sestavit ze zdrojového kódu. Jde o stav k 21. říjnu, mezitím se mohl změnit.

Red Hat v bulletinu RHSB-2026-013 píše, že část aktualizací pro RHEL 10, 9 a 8 už vyšla a další se připravují. Standardní instalace RHEL podle Red Hatu používají PHP-FPM, ne mod_php.

Podle přehledu stavu z rána 22. října to vypadalo takhle:

Stav se mění po hodinách, proto ho před aktualizací ověřte u Red Hatu nebo své distribuce.

Opravené balíčky pak nainstalujete běžnou aktualizací, například sudo dnf upgrade php php-cli php-fpm. Na verzích 8 a 9 může být PHP nainstalované jako modul. Kterou verzi modulu máte zapnutou, zjistíte příkazem dnf module list php.

Kontrola: spusťte rpm -q php php-cli php-fpm. Příkaz vypíše celé označení nainstalovaných balíčků. Porovnejte ho s bezpečnostním oznámením distribuce. V seznamu změn balíčku (changelog) by měly být uvedené CVE-2026-109618 i CVE-2026-109619.

Docker: oficiální obrazy php

Kontejner obsahuje PHP z doby, kdy jste obraz sestavili. Opravu dostane, až obraz sestavíte znovu a nasadíte ho.

Oficiální obraz php na Docker Hubu už má opravené tagy pro všechny čtyři řady, třeba 8.4.27-fpm, 8.5.12-apache nebo 8.2.35-fpm-alpine.

1. V Dockerfile změňte základní obraz na opravený tag, třeba FROM php:8.4.27-fpm.
1. Sestavte aplikační obraz znovu.
1. Nasaďte nový obraz místo starého.

Totéž doporučuje Google Cloud pro své služby. Na Google Kubernetes Engine znovu nasaďte pody s novým obrazem. Na Cloud Runu obraz sestavte a nasaďte znovu, pokud nemáte zapnuté automatické aktualizace základního obrazu.

Kontrola: v každém běžícím kontejneru spusťte docker exec NAZEV php -v, kde NAZEV nahradíte názvem kontejneru.

Laravel Forge a další spravované servery

Na Forge se PHP samo neaktualizuje. Automatické bezpečnostní aktualizace ho podle dokumentace Forge vynechávají, protože se instaluje z jiného repozitáře než zbytek systému. Na každém serveru ho proto aktualizujte ručně.

1. V administraci Forge otevřete server a kartu PHP.
1. U verze PHP rozbalte nabídku, zvolte Update PHP 8.4 (podle své verze) a potvrďte.
1. Zopakujte to pro každou nainstalovanou verzi PHP, i pro tu, kterou žádný web nepoužívá.

Aktualizace restartuje PHP-FPM, takže web může na pár vteřin vypadnout.

Podobné to může být i na jiných spravovaných serverech, které instalují PHP z odděleného repozitáře. Běžné aktualizace systému ho můžou vynechat, proto po aktualizaci verzi vždycky zkontrolujte.

Kontrola: ověřte verzi podle další části. Fronty úloh a další trvale běžící procesy totiž Forge sám nerestartuje.

Nechte to udělat AI asistenta

Pokud už používáte AI asistenta pro programování, který umí spouštět příkazy na serveru, třeba Claude Code nebo Codex, můžete mu celý postup svěřit. Stačí do něj vložit prompt níže. Asistent podle něj zjistí, jak na serveru PHP běží, porovná ho s opravenými verzemi a před každým příkazem, který něco mění, se vás zeptá. Dvě pravidla ale platí i tak: nejdřív si udělejte zálohu nebo snapshot serveru a každý příkaz si před schválením přečtěte. Všechno, co asistent spustí, totiž běží na vašem skutečném serveru.

Pomáháš mi opravit PHP na tomto serveru kvůli zranitelnostem CVE-2026-109618 a CVE-2026-109619 („php2shell“). Opravené verze vyšly 21. října 2026: PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35.
Postupuj krok za krokem a před každým příkazem, který na systému něco mění, se mě zeptej.

1. Zjisti, jak tu PHP běží: operační systém a jeho verzi, všechny nainstalované verze PHP (pro příkazovou řádku i pro web) a jestli PHP běží jako PHP-FPM, modul mod_php v Apachi, CGI, FrankenPHP, LiteSpeed, nebo v Dockeru. Ukaž mi verzi, kterou opravdu používá web, ne jen výstup php -v.
2. U každé nainstalované verze ověř, jestli je opravená. U balíčků z Debianu, Ubuntu nebo distribucí odvozených od RHEL porovnej celé označení balíčku s bezpečnostním oznámením distribuce. Distribuce totiž opravy přenášejí do starších verzí a číslo verze PHP přitom nemění.
3. Pokud něco opravené není, navrhni přesné příkazy pro aktualizaci na tomto serveru (balíčky distribuce, repozitář ondrej/php nebo packages.sury.org, Remi, případně nový tag obrazu Dockeru) a počkej, až je schválím.
4. Po aktualizaci restartuj všechny služby, ve kterých PHP běží: PHP-FPM, Apache, fronty úloh a další dlouho běžící procesy PHP.
5. Ověř výsledek: ukaž mi verzi PHP, kterou web hlásí po restartu, a potvrď, že jde o opravenou verzi nebo opravený balíček distribuce.
6. Pokud dnes aktualizovat nejde, řekni mi, která dočasná nastavení riziko sníží (například session.upload_progress.enabled = 0 v php.ini) a co naopak nepokrývají.

Nesahej na kód aplikace, nic nemaž, a když se ti cokoli nebude zdát, zastav se a zeptej se.

Jak služby restartovat a ověřit, že oprava zabrala?

Aktualizace vymění soubory na disku. Procesy, které už běží, ale dál používají starý kód z paměti, dokud je nerestartujete. U aplikací v Node.js to platí stejně, jak ukazujeme v návodu k aktualizaci Node.js kvůli chybě v Brotli.

Na Forge restartuje PHP-FPM samotná aktualizace balíčků. Fronty úloh, Horizon, Octane, Reverb a další procesy PHP spuštěné z příkazového řádku ale jedou se starou verzí dál.

Aktualizace samotné aplikace přitom PHP nezmění, jak připomíná Rescana. Restartujte proto Apache nebo PHP-FPM a k tomu všechny procesy PHP, které běží trvale. Každý pracovní proces PHP radí po instalaci restartovat i watchTowr.

Na Debianu a Ubuntu to pro PHP 8.4 udělá třeba sudo systemctl restart php8.4-fpm, pro Apache sudo systemctl restart apache2.

Teprve potom má smysl kontrolovat verzi:

• Spusťte znovu php8.4 -v a php-fpm8.4 -v s číslem své řady. Druhý příkaz ověří, že s opravenou verzí běží i samotné PHP-FPM.
• Na Debianu, Ubuntu a systémech z rodiny Red Hat porovnejte celé označení balíčku, ne číslo z php -v.
• Podívejte se na verzi, kterou hlásí web, například ve WordPressu. Může se lišit od příkazového řádku.
• Zkontrolujte i kontejnery a záložní servery. Aktualizaci je potřeba ověřit ve všech prostředích, kde PHP běží, jak radí CSIRT.CZ.

Dočasná opatření z další části podle CSIRT-MU chyby neodstraní a aktualizaci nenahradí.

Co dělat, když dnes aktualizovat nemůžete?

Dočasné řešení, které by chyby úplně zablokovalo, neexistuje. Podle vývojářů PHP je jedinou bezpečnou volbou aktualizace.

Nastavení popsaná níž zablokují jen některé způsoby útoku. Riziko sníží, aktualizaci ale nenahradí, takže je berte jako provizorium do doby, než aktualizujete.

Na sdíleném hostingu tato nastavení většinou sami nezměníte. Požádejte hosting, ať je nastaví za vás. Neoficiální „opravy“ v podobě pluginů nebo kousků kódu neinstalujte, varuje před nimi i Patchstack.

Proti CVE-2026-109619 radí vývojáři PHP tohle:

• Nastavte session.upload_progress.enabled=0 v php.ini, v poolu PHP-FPM nebo v konfiguraci serveru, která se uplatní ještě před zpracováním požadavku.
• Nespoléhejte na ini_set() ani na soubor .user.ini v PHP-FPM. Takové nastavení nestačí.
• Restartujte všechny pracovní procesy PHP.
• Na PHP 8.5 nastavte navíc fatal_error_backtraces=0 a znovu restartujte. Tím zablokujete další potvrzený způsob útoku.

Obě nastavení zablokují jen potvrzené způsoby útoku, jiné varianty zůstávají otevřené. Nastavení, které by tuhle chybu zablokovalo úplně, podle bezpečnostního upozornění PHP neexistuje. Na CVE-2026-109618 navíc tato nastavení nemají vůbec žádný vliv.

Proti CVE-2026-109618 radí vývojáři PHP tohle:

• Zrušte limit paměti nastavením memory_limit=-1. Hodnotu nastavte tak, aby ji aplikace nemohly přepsat, tedy přes php_admin_value v poolu PHP-FPM nebo v konfiguraci Apache.
• Nastavte nízkou hodnotu post_max_size.
• Paměť hlídejte limitem kontejneru nebo cgroup, aby server zůstal dostupný.
• Nepoužívejte RLIMIT_AS ani RLIMIT_DATA. Právě ty totiž můžou vyvolat selhání, které chyba zneužívá.

Žádné z těchto nastavení server samo neochrání. Bezpečnostní firma watchTowr jde ještě dál a změny v souborech .ini za účinnou ochranu nepovažuje.

Co s PHP 8.1 a starším?

PHP 8.1 a starší už od vývojářů PHP oficiální aktualizace nedostávají. Pro řady 7.4, 8.0 a 8.1 vydali jen minimální záplaty zdrojového kódu. Hodí se tomu, kdo si PHP sestavuje sám a nemá dodavatele s dlouhodobou podporou (LTS).

Některé distribuce a dodavatelé LTS ale vydávají vlastní, zpětně přenesené opravy. Zeptejte se proto nejdřív svého dodavatele. Panely cPanel a Plesk je podle přehledu z 22. října mají i pro řady 7.4, 8.0 a 8.1.

Verze 5.4 až 7.3 už od vývojářů PHP žádnou opravu nedostanou, upozorňuje Tenable.

Pozor i na řadu 8.2. Opravu sice dostala, jenže 31. prosince 2026 jí končí podpora a potom už bezpečnostní opravy nepřijdou. Přechod na novější řadu proto plánujte i u ní.

Pokud na PHP, které nejde opravit, běží něco důležitého, postupujte takhle:

1. Server izolujte od zbytku sítě nebo k němu omezte přístup firewallem, jak radí Huntress. Nastavte také session.upload_progress.enabled na Off. Pokryje to ovšem jen jednu z chyb, a to ještě jen zčásti.
1. Zvažte, jestli web do opravy dočasně neodstavit. Podle Codeable to doporučují WordPress.org i britský úřad NCSC.
1. Naplánujte přechod na podporovanou verzi PHP. Nejdřív ho vyzkoušejte na testovací kopii webu a před přepnutím udělejte úplnou zálohu.

Když hosting staré PHP neopraví, zbývá jediné: přejít na podporovanou verzi, jak píše i česká firma DataStorm.

Na serveru, na kterém roky běží starý software, je ovšem často potřeba vyměnit víc než jen PHP. Popisujeme to v článku o tom, jak poznat, že firma přerostla svůj tech stack.

Nevíte si rady? Napište nám

V mnoha případech zvládnete aktualizaci sami. Složitější je to, když nevíte, jak je hosting nastavený, když web běží na starém PHP nebo když máte serverů víc.

Po opravě se vyplatí server i otestovat. Součástí penetračního testování je kontrola po opravách, která ověří, že jsou nalezené chyby opravdu vyřešené. Můžeme vám také pomoct s opravami nebo posoudit řešení, které navrhl váš tým. Co takový test obnáší, vysvětluje článek o white-box a black-box testování.