21. října 2026 | PHP | IT bezpečnost
Dne 21. října 2026 vydal bezpečnostní tým PHP aktualizace pro všechny stále podporované verze PHP. Uzavírají dvě kritické zranitelnosti, které se staly známými jako PHP2Shell. BSI k tomu vydal varování a požaduje, aby dotčené systémy byly neprodleně záplatovány. Kdo provozuje webový server s PHP, měl by jednat ještě dnes. Platí to i pro všechny, kdo provozují „jen“ WordPress, Nextcloud nebo Joomla, protože tyto aplikace běží na PHP.
Tento článek shrnuje, co se stalo, které verze PHP jsou dotčeny, jakou verzi nyní potřebujete a jak během několika minut ověříte, zda je váš server zabezpečen.
Obsah tohoto článku
Co se stalo? Časový průběh
Bezpečnostní tým PHP vydání oprav předem oznámil, aby hostingové firmy a správci měli čas se připravit. Samotné vydání proběhlo 21. října 2026. BSI vydal své varování (verze 1.1) téhož dne.
- 20. října 2026: Předběžné varování bezpečnostního týmu PHP, že následující den vyjdou bezpečnostní aktualizace.
- 21. října 2026, 14:00 UTC (16:00 SELČ): Jsou vydány záplaty pro PHP 8.5, 8.4, 8.3 a 8.2.
- 21. října 2026: BSI varuje před „kritickými zranitelnostmi, které ohrožují webové aplikace po celém světě“, a doporučuje neprodleně záplatovat. Podle údajů BSI velcí poskytovatelé hostingu částečně preventivně odpojili servery.
Obě zranitelnosti PHP v přehledu
Jde o dvě samostatné chyby v jádru PHP: CVE-2026-109618 a CVE-2026-109619. Obě mohou podle údajů bezpečnostního týmu PHP vést k tomu, že útočník může na serveru spustit programový kód, aniž by se přihlásil (unauthenticated Remote Code Execution). Zranitelnosti jsou hodnoceny CVSS v4.0: 9,2 (kritické).
| Vlastnost | Význam |
|---|---|
| Označení | CVE-2026-109618 a CVE-2026-109619 |
| Hodnocení | CVSS v4.0: 9,2 — kritické |
| Dopad | Spuštění kódu na serveru (Remote Code Execution), bez přihlášení |
| Příčina 1 | Poškozená paměť, když PHP během zpracování nedostane další operační paměť (Out-of-Memory) |
| Příčina 2 | Zastaralý globální stav, který zůstává v paměti mezi požadavky |
| Zvlášť ohroženo | Apache s mod_php |
Podle odhadu BSI nebyly v době zveřejnění žádné potvrzené útoky, existovaly však nepotvrzené náznaky pokusů o zneužití. U kritických zranitelností v tak rozšířeném softwaru je podle zkušenosti třeba počítat s tím, že útočníci opravy analyzují a připraví automatizované útoky. Časové okno pro záplatování je proto krátké.
Koho se to týká?
Dotčen je v zásadě každý server, na němž běží PHP, bez ohledu na to, jak je PHP napojeno: PHP-FPM, mod_php v Apache, php-cgi, FrankenPHP nebo LiteSpeed. Nejvyšší riziko je podle bezpečnostního týmu PHP u Apache s mod_php.
BSI výslovně jmenuje aplikace, které na PHP stojí, a proto mohou být také dotčeny:
- Systémy pro správu obsahu: WordPress, Drupal, TYPO3, Joomla
- Obchodní systémy: Magento
- Cloud a úložiště souborů: Nextcloud
- Rozhraní firewallů: pfSense, OPNsense
Aplikace samotná přitom nemusí být chybná. Zranitelnost je v PHP, proto samotná aktualizace WordPressu, Nextcloudu & spol. nepomůže. Je třeba aktualizovat verzi PHP na serveru. U firewallů jako pfSense a OPNsense přichází opravená verze PHP přes příslušnou aktualizaci firmwaru od výrobce.
Tyto verze PHP jsou bezpečné
Zranitelnosti jsou opraveny v následujících verzích. Vše pod nimi se považuje za zranitelné.
| Větev PHP | Minimálně požadováno | Poznámka |
|---|---|---|
| PHP 8.5 | 8.5.12 | aktuální větev |
| PHP 8.4 | 8.4.27 | |
| PHP 8.3 | 8.3.36 | |
| PHP 8.2 | 8.2.35 | Podpora končí 31. prosince 2026 |
| PHP 8.1 a starší | žádná oficiální aktualizace, viz dole | |
Jak zkontrolovat a aktualizovat svůj server
1. Zjistit nainstalovanou verzi PHP
Na příkazové řádce serveru zobrazí php -v verzi PHP pro příkazovou řádku. Webový server může používat jinou verzi PHP. Zkontrolujte proto také verzi PHP-FPM, resp. modulu Apache, například pomocí php-fpm8.3 -v nebo přes stránku, která vypisuje phpinfo() (tu poté ihned odstraňte).
2. Nainstalovat aktualizaci přes správu balíčků
U Debianu, Ubuntu, RHEL a příbuzných přichází opravená verze přes běžnou správu balíčků, například apt update && apt upgrade nebo dnf upgrade. U cizích zdrojů, jako je Sury PPA nebo repozitář Remi, se nové balíčky obvykle objeví brzy.
apt changelog php8.3-fpm nebo rpm -q --changelog php | grep CVE-2026-1096).
3. Restartovat službu PHP
Samotná aktualizace balíčku nestačí: běžící procesy PHP si ponechávají starý kód v paměti. Restartujte PHP-FPM (systemctl restart php8.3-fpm), resp. Apache (systemctl restart apache2), a poté zkontrolujte, zda byly procesy spuštěny po aktualizaci.
4. Hostované weby
U sdíleného hostingu obvykle aktualizuje poskytovatel. V zákaznické nabídce lze většinou nastavit verzi PHP pro každý web. Zvolte tam jednu z výše uvedených bezpečných verzí nebo se zeptejte poskytovatele na stav záplat. Podle údajů BSI někteří poskytovatelé preventivně odpojili servery od sítě. Pokud je váš web krátce nedostupný, může to být příčina.
PHP 8.1 a starší: žádná oficiální aktualizace
Pro PHP 8.1 a starší už neexistují oficiální bezpečnostní aktualizace. Provozovatelé takových systémů mají dvě možnosti:
- Přejít na podporovanou verzi (doporučeno). Čím starší verze, tím větší je pracnost úprav aplikace a rozšíření, proto by se přechod měl předem otestovat.
- Opravy zpětně přenést. Bezpečnostní tým PHP zpřístupnil opravy ve vývojových větvích na GitHubu. Kdo PHP kompiluje sám, může tyto změny převzít do starších verzí. Je to přechodné řešení a vyžaduje odborné znalosti.
I PHP 8.2 je podporováno jen do 31. prosince 2026. Naplánujte proto přechod na PHP 8.4 nebo 8.5 už nyní a neodkládejte jej na přelom roku.
Přechodná opatření a otázka „Vypnout server?“
Bezpečnostní tým PHP s oznámením popsal také předběžná ochranná opatření. Ta snižují riziko, ale zranitelnosti zcela neuzavírají. Aktualizaci nenahrazují a jsou určena jen k překlenutí doby do aktualizace.
Zda by měl být server do aktualizace odpojen od sítě, závisí na jeho významu a dostupnosti. BSI uvádí, že velcí poskytovatelé tento krok učinili. Jako praktické pravidlo platí:
- Veřejně dostupný server, aktualizace je nyní možná: okamžitě záplatovat, vypínání není nutné.
- Veřejně dostupný server, aktualizace není krátkodobě možná: omezit přístup (například firewallem jen pro známé adresy) nebo službu dočasně vypnout, zejména u
mod_php. - Server dostupný jen interně: záplatovat brzy, naléhavost je nižší.
Časté dotazy
Musím aktualizovat WordPress, Joomla nebo Nextcloud?
Kvůli této zranitelnosti ne. Nachází se v PHP, nikoli v aplikaci. Aktualizujte verzi PHP na serveru. Aktualizace aplikace je nezávisle na tom přesto smysluplná.
Jak poznám, zda někdo zranitelnost již zneužil?
Jistý závěr je obtížný. Nápadné jsou neznámé soubory PHP ve webovém adresáři, neobvyklé procesy pod uživatelem webového serveru, nové uživatelské účty nebo úlohy cron a neobvyklý odchozí datový provoz. Při konkrétním podezření by měl být systém forenzně prověřen a v případě pochybností nově nainstalován.
Stačí webový aplikační firewall (Web Application Firewall)?
Firewall dokáže zachytit známé vzorce útoků, ale není náhradou za aktualizaci. Více o souhře několika ochranných vrstev se dočtete v našem článku Zabezpečení Odoo 19: firewall, 2FA & Web RBL. Zásady platí pro každou webovou aplikaci.
Týká se to Odoo?
Ne. Odoo je napsáno v Pythonu a neběží na PHP. Dotčeny by byly pouze aplikace v PHP, které běží na stejném serveru.
Kde najdu oficiální informace?
Oznámení bezpečnostního týmu PHP najdete v archivu novinek na php.net (záznam z 20. října 2026), verze na php.net/downloads. Varování úřadu BSI nese číslo 2026-297981-1032 a je zveřejněno na bsi.bund.de .
Podpora od Biricon IT Services
Pokud si nejste jisti, jaká verze PHP na vašem serveru běží, nebo potřebujete pomoc s opravou, rádi vám pomůžeme: při inventuře všech systémů s PHP, při instalaci aktualizací, při přechodu na podporovanou verzi PHP a při kontrole kompromitace. Jako IT dodavatel spravujeme servery, firewally a webové aplikace pro malé a střední podniky.
Stav k 21. říjnu 2026. Situace se může rychle změnit; rozhodující jsou zveřejněná sdělení bezpečnostního týmu PHP a úřadu BSI.