Pokud váš web nebo e-shop běží na PHP starším než 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, může na něm cizí člověk spustit vlastní kód, a to bez hesla. Tým PHP vydal opravené verze 21. října 2026. Obě chyby, CVE-2026-109618 a CVE-2026-109619, hodnotí jako kritické se skóre 9.2 podle CVSS v4.0. Spolehlivě pomůže jen nová verze PHP.
WordPress, WooCommerce, PrestaShop, Joomla i Drupal běží na PHP. Pokud máte firemní web na některém z nich, týká se vás to. Systémy napsané v jiných jazycích, třeba Odoo v Pythonu nebo programy v Node.js, ne. V médiích se pro dvojici chyb ujal název PHP2Shell.
Koho se zranitelnost PHP2Shell týká
Tým PHP 21. října 2026 napsal, že ohrožené je každé PHP, které obsluhuje webové požadavky: PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP i LiteSpeed. Největší riziko vidí tým PHP u mod_php. Tam existuje ukázkový exploit, kterým útok spustí jediný nepřihlášený požadavek, ještě než se začne vykonávat kód samotného webu. Bezpečnostní pluginy WordPressu tedy nepomohou.
Opravy dostaly všechny podporované řady: 8.5, 8.4, 8.3 a 8.2. PHP 8.1 a starší už od projektu PHP aktualizace nedostávají. Protože jde o kritické chyby, zveřejnil bezpečnostní tým PHP aspoň minimální opravy zdrojového kódu pro 7.4, 8.0 a 8.1, ty si ale musíte sami přeložit. Ubuntu nabízí opravy i pro staré php5, 7.0 a 7.2, jenže jen přes placené Ubuntu Pro.
Pokud web běží na hotové platformě typu Shoptet, Wix nebo Shopify, server nespravujete vy. Aktualizace je na provozovateli. Zeptejte se ho, jestli už ji udělal.
Jak zjistit, jestli máte opravenou verzi
Tady je jedna past. Linuxové distribuce opravy vracejí do svých balíčků a číslo verze nemění. Příkaz php -v vám na Ubuntu 24.04 ukáže 8.3.6, což vypadá jako stará verze, a přitom opravený balíček je 8.3.6-0ubuntu0.24.04.13. Rozhoduje celé číslo balíčku, ne první tři čísla.
- Debian 12: php8.2 ve verzi
8.2.35-1~deb12u1nebo novější (DSA-6574-1). - Debian 13: php8.4 ve verzi
8.4.27-1~deb13u1nebo novější. - Ubuntu 24.04: php8.3 ve verzi
8.3.6-0ubuntu0.24.04.13nebo novější. - Ubuntu 22.04: php8.1 ve verzi
8.1.2-1ubuntu2.28nebo novější. - PHP přeložené ze zdroje nebo z oficiálních buildů: 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35.
Ověřte si to na serveru s Debianem nebo Ubuntu příkazem apt list --installed 'php*'. Po aktualizaci restartujte PHP-FPM nebo Apache. Do restartu běží v paměti dál stará verze.
Na sdíleném hostingu uvidíte v administraci jen řadu PHP, třeba 8.3. Napište hostingu a zeptejte se na konkrétní verzi balíčku a datum, kdy ho nasadil.
Co se stalo a jak chyby fungují
Tým PHP 20. října 2026 oznámil, že 21. října ve 14:00 UTC vydá opravu dvou kritických chyb, a dodal, že ji vydá dřív, pokud se o chybách dozví veřejnost nebo začnou útoky. Záznamy CVE vyšly 21. října ve 13:48 a 13:54 UTC.
CVE-2026-109618 nastane, když PHP během požadavku dojde paměť. PHP přestane požadavek obsluhovat ve chvíli, kdy jsou interní data požadavku nastavená jen napůl, a úklid po požadavku je pak bere jako platná. CVE-2026-109619 je o vnitřním stavu, který přežije uvolnění paměti, na kterou ukazuje. Další požadavek obsloužený stejným procesem ho použije dřív, než se stav znovu nastaví.
Obě chyby mají v záznamu CVE vysokou složitost útoku a podmínky na straně cíle (AC:H, AT:P), a proto skóre 9.2, ne nejvyšších 10.
Co dělat, když nemůžete aktualizovat hned
Tým PHP píše jasně: tyto kroky zmenší riziko u konkrétních cest útoku, ale server bezpečným neudělají.
- Proti CVE-2026-109618: nastavte
memory_limit=-1tak, aby ho web nemohl přepsat, například přesphp_admin_valuev poolu FPM nebo v konfiguraci Apache. Snižtepost_max_sizena 8M, pokud web nepřijímá soubory, jinak na 32M, aupload_max_filesizedržte pod ním. Nepoužívejte RLIMIT_AS ani RLIMIT_DATA, právě ty chybu vyvolají. - Proti CVE-2026-109619: nastavte
session.upload_progress.enabled=0v php.ini nebo v poolu FPM a restartujte všechny procesy. Přesini_set()nebo soubor .user.ini to nefunguje. Na PHP 8.5 přidejtefatal_error_backtraces=0.
Limit paměti -1 má svou cenu: jeden špatný skript pak může sebrat paměť celému serveru. Tým PHP proto doporučuje držet hranici o úroveň výš, limitem kontejneru nebo cgroup, který ukončí jen postižený proces.
Zneužívá se PHP2Shell už?
Oficiální záznamy to zatím nepotvrzují. CISA v záznamu CVE z 21. října 2026 uvádí u zneužití hodnotu „none“. Katalog aktivně zneužívaných zranitelností CISA (verze 2026.10.23 z 23. října) žádnou z obou chyb nevede. Bezpečnostní firma watchTowr přitom ve svém přehledu z 23. října píše, že útoky zachytila ve své síti návnad (honeypotů) od 21. října 2026. Jak rozšířené jsou, se z veřejných zdrojů k 25. říjnu zjistit nedá.
Mimochodem, 23. října vydal tým PHP ještě informativní upozornění na třetí chybu, CVE-2026-115560. Projeví se jen při dost neobvyklé konfiguraci: obsluha session nastavená na php_binary nebo php_serialize a za běhu přepnutá na php přes ini_set() před session_start(). Pomůže totéž nastavení jako u CVE-2026-109619, takže kdo ho už má, nemusí nic dělat. Celý popis slíbil tým PHP s další běžnou opravnou verzí.
Firmy, na které míří NIS2
Pokud vaše firma spadá pod zákon č. 264/2025 Sb., který převádí NIS2, a zjistíte, že útočník chybu na vašem serveru využil, běží vám lhůty, do kdy musíte incident nahlásit: 24 hodin, 72 hodin a 30 dní. Víc píšeme na stránce NIS2.
A ještě jedno datum do kalendáře: PHP 8.2 přestane dostávat bezpečnostní opravy 31. prosince 2026.
Časté otázky
Stačí aktualizovat WordPress a pluginy?
Ne. Chyba je v samotném PHP, ne ve WordPressu. U mod_php se útok spustí dřív, než se kód WordPressu vůbec začne vykonávat. Aktualizovat musíte PHP na serveru.
Ukazuje mi hosting PHP 8.3. Jsem v bezpečí?
To z řady 8.3 nepoznáte. Opravená je upstream verze 8.3.36, na Ubuntu 24.04 balíček 8.3.6-0ubuntu0.24.04.13. Zeptejte se hostingu na přesnou verzi balíčku.
Máme PHP 7.4. Co teď?
Projekt PHP pro 7.4 vydal jen minimální opravu zdrojového kódu, ne hotovou verzi. Buď si ji přeložíte sami, nebo využijete dodavatele s prodlouženou podporou, nebo přejdete na podporovanou řadu. Dlouhodobě dává smysl jen to třetí.
Týká se to i skriptů spouštěných z příkazové řádky?
Tým PHP jmenuje PHP, které obsluhuje webové požadavky. Aktualizujte ale všechny balíčky PHP na serveru najednou, ať nezůstane stará verze ani v jednom z nich.
Jak poznám, že už se na náš server někdo dostal?
Jednoduchý test na to není. Hledejte v logu webového serveru nečekané pády PHP procesů a chyby nedostatku paměti nejméně od 20. října 2026, kdy tým PHP chyby ohlásil, nové soubory PHP ve webovém adresáři a neznámé procesy. Když něco najdete, nechte server prověřit odborníkem a nemažte logy.
Pokud si nejste jistí, co na vašich serverech běží, penetrační test to zjistí za vás.
Zdroje
- PHP: Security advisory: Critical remote code execution vulnerabilities, 21. 10. 2026, a Upcoming Critical PHP Security Release, 20. 10. 2026, https://www.php.net/archive/2026.php
- PHP: Supported Versions, stav k 25. 10. 2026, https://www.php.net/supported-versions.php
- CVE-2026-109618 a CVE-2026-109619, záznamy CVE, 21. 10. 2026, https://www.cve.org/CVERecord?id=CVE-2026-109618
- watchTowr: PHP2Shell FAQ, aktualizováno 23. 10. 2026, https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
- CISA: Known Exploited Vulnerabilities Catalog, verze 2026.10.23, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Debian Security Tracker, CVE-2026-109618, stav k 25. 10. 2026, https://security-tracker.debian.org/tracker/CVE-2026-109618
- Ubuntu Security, CVE-2026-109618, stav k 25. 10. 2026, https://ubuntu.com/security/CVE-2026-109618
