Stručně: CVE-2026-109619 je druhá zranitelnost za PHP2Shell. Vnitřní stav, který patří k požadavku, může po uvolnění paměti přetrvat; pozdější požadavek ve stejném workeru ho může využít dřív, než se resetuje. Důsledkem je spuštění kódu bez přihlášení. Náprava: aktualizace na PHP 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35 a restart všech workerů.
Co je CVE-2026-109619?
CVE-2026-109619 (označení GitHub GHSA-6wmf-4rv5-p3rp) je hodnocena CVSS v4.0 9.2. Spolu s CVE-2026-109618 tvoří PHP2Shell. Obě zranitelnosti jsou přímo v PHP, ne v aplikaci.
Dopad je stejný jako u sesterské zranitelnosti: útočník může na dálku, bez hesla a bez uživatelského účtu spouštět kód na serveru. Příčina je ale jiná.
Proč je zastaralý stav ve workeru nebezpečný
Webový server PHP nespouští pro každý požadavek nový proces. U PHP-FPM, Apache s mod_php, LiteSpeed nebo FrankenPHP zpracovává jeden worker po sobě mnoho požadavků. Mezi dvěma požadavky PHP resetuje svůj vnitřní stav, aby se nic z požadavku A nedostalo do požadavku B.
U CVE-2026-109619 se tento reset nezdaří úplně. Podle php.net může vnitřní stav patřící k požadavku po uvolnění paměti přetrvat. Pozdější požadavek ve stejném workeru může tento zastaralý stav využít dřív, než se resetuje. Zjednodušeně: něco se dál používá, co už vlastně není platné.
Z pohledu provozu je to pozoruhodné. Opakované využití workerů je záměrné, protože webový server zrychluje: worker se nemusí pro každý požadavek znovu spouštět, načítat rozšíření a alokovat paměť. Zranitelnost tedy zasahuje vlastnost, kterou má prakticky každá produkční instalace PHP. php.net neuvádí žádnou konfiguraci, která by problém úplně odstranila; proto vede cesta přes aktualizaci.
Podrobnosti ke zneužití nezveřejňujeme. Pro provozovatele platí: každý provozní režim, ve kterém worker obslouží více požadavků, je třeba mít na očích, a právě tyto režimy jsou ty obvyklé.
Obě zranitelnosti PHP2Shell ve srovnání
| Vlastnost | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Označení GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Hodnocení | CVSS v4.0 9.2 | CVSS v4.0 9.2 |
| Spouštěč | Out of memory při inicializaci dat požadavku | Vnitřní stav přetrvá po uvolnění |
| Dopad | Spuštění kódu bez přihlášení | Spuštění kódu bez přihlášení |
| Opraveno v | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Postiženy jsou PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Nejvyšší riziko vidí tým PHP u mod_php; proč, vysvětlujeme na stránce Proč nese mod_php nejvyšší riziko.
Uzavření CVE-2026-109619: aktualizace, poté restart všech workerů
Právě u této zranitelnosti je restart rozhodující. Dokud staří workeři běží v paměti, server dál pracuje s chybným kódem, i když nové soubory už dávno leží na disku.
Zkontrolujte verzi a stav balíčku. Názvy balíčků se liší podle distribuce a rozhraní poskytovatele hostingu:
php -v
php-fpm8.3 -v # binárka FPM může mít jinou verzi než CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # rodina RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Poté restartujte všechny dotčené služby:
sudo systemctl restart php8.3-fpm # podle nainstalované verze PHP
sudo systemctl restart apache2 # u mod_php; v RHEL se služba jmenuje httpd
Pokud vaše distribuce nebo poskytovatel hostingu nasazuje backport, zobrazené číslo verze může zůstat stejné. Pak rozhodují changelog balíčku a písemné potvrzení poskytovatele. Kontrolu krok za krokem najdete na stránce Restart PHP-FPM a všech workerů.
Poznamenejte si datum a čas restartu. Pro pozdější posouzení, zda útok proběhl před záplatou, nebo po ní, je tento okamžik nejdůležitějším referenčním bodem.
Co zbývá udělat po záplatě
Záplata nedokazuje, že se předtím nic nestalo. Podle zpráv médií byl první pokus o útok pozorován 17. října, čtyři dny před záplatami. Uchovejte logy serveru od 20. října, jak radí odborný tisk, a zkontrolujte server na nesrovnalosti. Pokyny najdete na stránce Jsem už napaden?.
Myslete přitom na dosah: při úspěšném spuštění kódu má útočník oprávnění procesu PHP. Může číst, co smí číst aplikace, například konfigurační soubory s přístupy k databázi nebo klíči API. Pokud se incident potvrdí, patří tyto přístupové údaje po vyčištění obnovit.
Jak konkrétně pomáhá PHP SOS?
Prostřednictvím služby záplatování PHP provedeme opravu dohledatelně:
- Zjistit: Jaké verze PHP a provozní režimy běží na kterém serveru a jaký zdroj balíčků je dodává?
- Záplatovat: aktualizace ze správného zdroje nebo přechodná opatření podle php.net, kde aktualizace ještě nejde.
- Zkontrolovat restart: proces po procesu ověříme, že běží jen opravená verze.
- Zdokumentovat: verze, stavy balíčků a časy restartů, abyste mohli stav doložit.
Časté dotazy
Čím se CVE-2026-109619 liší od CVE-2026-109618?
CVE-2026-109618 vzniká, když stav out of memory přeruší požadavek uprostřed inicializace. CVE-2026-109619 se týká stavu, který po skončení požadavku zůstane ve workeru. Obě vedou ke spuštění kódu bez přihlášení a jsou opraveny ve stejných verzích PHP.
Pomůže restartovat workery PHP-FPM častěji?
Jako náhrada aktualizace se to nehodí. php.net častější restarty workerů jako přechodné opatření neuvádí. Workery je ale nutné restartovat po aktualizaci, aby vůbec běžela opravená verze.
Chrání mě aktualizace CMS před CVE-2026-109619?
Ne. Zranitelnost je v PHP, ne ve WordPressu, Shopwaru, TYPO3 ani jiném systému. Uzavře ji jen aktualizace PHP nebo potvrzený backport od poskytovatele.
Existují známé stopy útoku přes CVE-2026-109619?
Potvrzené indikátory kompromitace (IOC) zatím nebyly zveřejněny. Detekce se opírá o analýzu chování, například nové soubory PHP, neobvyklá odchozí spojení nebo neznámé cron úlohy.