# CVE-2026-109619: RCE přes zastaralý globální stav > CVE-2026-109619 srozumitelně: proč je vnitřní stav mezi požadavky nebezpečný, které verze PHP jsou opravené a jak server správně zabezpečit. Zdroj: https://phpsos.de/cs/php2shell/cve-2026-109619/ Stav: 25.10.2026 Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6 **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](https://phpsos.de/cs/php2shell/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](https://phpsos.de/cs/php2shell/mod-php-risiko/). ## 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: ```bash 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: ```bash 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ů](https://phpsos.de/cs/php2shell/php-fpm-neustart/). > **Tip:** > 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?](https://phpsos.de/cs/php2shell/bin-ich-gehackt-anzeichen/). 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](https://phpsos.de/cs/leistungen/php-patch-service/) 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. ## Zdroje - [php.net: bezpečnostní oznámení](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI: německý Spolkový úřad pro informační bezpečnost](https://www.bsi.bund.de/)