Vážné chyby v PHP umožňují vzdálené spuštění kódu, aktualizace byly vydány

Vývojáři PHP uvolnili aktualizace řešící dvě velmi závažné bezpečnostní chyby. Verze PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35 opravují dvě kritické chyby zabezpečení, které mohou umožnit neautorizované vzdálené spuštění kódu. Všem uživatelům PHP se důrazně doporučuje provést aktualizaci co nejdříve.

Ohroženy jsou všechny instalace PHP zpracovávající webové požadavky, včetně PHP-FPM, Apache s mod_php, php-cgi,FrankenPHP a LiteSpeed. Za nejrizikovější vývojáři považují mod_php, u kterého byl předveden způsob zneužití, při němž může neautentizovaný požadavek spustit útok ještě před spuštěním jakéhokoli kódu aplikace.

Jedná se o celkem dvě samostatné chyby:

RCE prostřednictvím poškození způsobeného nedostatkem paměti (OOM), CVE-2026–109618 (GHSA-w8hw-w9fx-j79w): při nedostatku paměti může být přerušen běh PHP v okamžiku, kdy jsou interní data požadavku inicializována pouze částečně. Při úklidu požadavku pak mohou být neplatná data považována za platná.

RCE prostřednictvím zastaralého globálního stavu, CVE-2026–109619 (GHSA-6wmf-4rv5-p3rp): interní stav patřící požadavku může přetrvávat i poté, co byla uvolněna paměť, na které byl uložen. Následující požadavek zpracovávaný stejným procesem může tento zastaralý stav použít dříve, než jej normální inicializace resetuje.

Zneužití už bylo předvedeno

Po internetu koluje video, kde někdo předvádí nástroj pro zneužití nazvaný PHP2Shell. Konkrétně bylo ukázání spuštění kódu na webových serverech s těmito aplikacemi: WordPress 7.1.3, MediaWiki 1.46.2, phpBB 3.3.17, Magento 2.4.9, Joomla 6.2.0, Laravel 13.36.0, Laravel 8.83.29, Symphony 8.1.9, Drupal 11.4.10 a WHMCS 9.0.9. Všechny aplikace používají PHP a jsou v aktuálních verzích.

Zasaženy jsou verze 5 až 8

Podle oficiálních informací jsou zasaženy verze PHP 5, 7 a 8. Proveďte proto co nejdříve aktualizaci na verzi PHP 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35. Instalace opravené verze je jediným plnohodnotným řešením situace.

PHP 8.1 a starší verze již nedostávají aktualizace od projektu PHP. Některé distribuce a poskytovatelé verzí LTS nabízejí zpětně přenesené opravy, proto se pro podrobnosti obraťte na svého poskytovatele nebo proveďte aktualizaci na podporovanou verzi.

Vzhledem k závažnosti těchto zranitelností poskytl bezpečnostní tým PHP minimální záplaty zdrojového kódu pro PHP 7.4, PHP 8.0 a PHP 8.1, aby pomohl uživatelům, kteří kompilují ze zdrojového kódu nebo nemají přístup k poskytovateli LTS.

Když nemůžete aktualizovat

Vývojáři zdůrazňují, že jediným správným a plnohodnotným řešením je aktualizace na nejnovější verzi PHP obsahující záplaty. Pokud ale nemůžete aktualizovat, můžete zavést opatření snižují riziko vystavení konkrétním způsobům útoků.

• Nastavte memory_limit=-1, nejlépe tak, aby to aplikace nemohly přepsat, například pomocí php_admin_value v konfiguraci FPM poolu nebo Apache, a zkontrolujte, zda žádné nastavení poolu, adresáře nebo aplikace znovu nezavádí konečný limit. Tím se odstraní chyba související s nastavitelným limitem paměti PHP, ale chyba při alokaci paměti na nižší úrovni může stále vést ke zranitelnosti.
• Nastavte nízkou hodnotu post_max_size. U aplikací, které nevyžadují nahrávání souborů, nastavte post_max_size = 8M. Pokud je nahrávání souborů nezbytné, nastavte post_max_size = 32M. Udržujte hodnotu upload_max_filesize nižší než post_max_size. Zvažte vynucení limitů na úrovni webového serveru nebo proxy pro velikost dekódovaných požadavků, počet vstupních polí, počet částí multipart, počet hlaviček a hloubku vnoření. Tyto limity musejí zahrnovat i požadavky bez použitelného  Content-Length.
• Použijte limit kontejneru nebo cgroup jako limit, nejlépe s politikou, která ukončí pouze postižený pracovní proces. Nepoužívejte RLIMIT_AS ani RLIMIT_DATA, protože tyto parametry mohou způsobit zranitelnou chybu při alokaci paměti.
• Nastavte session.upload_progress.enabled=0 a restartujte všechny pracovní procesy. Použijte php.ini, pool FPM nebo konfiguraci serveru, která se aplikuje před analýzou požadavku. Nespoléhejte se na ini_set() ani na .user.ini v FPM. Tím se zablokují potvrzené cesty, nikoli však jiné varianty.
• V PHP 8.5 nastavte fatal_error_backtraces=0 a restartujte všechny pracovní procesy. Tím se zablokuje pouze potvrzená fatální cesta.
• Odstraňte neplatná nebo zastaralá nastavení aplikovaná na jednotlivé požadavky, která generují diagnostické zprávy před inicializací. Skrytí diagnostiky pomocí error_reporting,display_errors nebo @ nepomůže.
• Opravte fatální chyby a časové limity provádění, ke kterým má útočník přístup, včetně selhání v callbackách, zpracování nahrávání nebo importu a úklidu.

Cloudflare už vidí pokusy o zneužívání chyb

Společnost Cloudflare uvádí, že zaznamenává první pokusy o zneužití těchto chyb, a pro weby využívající její služby zavedla nová filtrační pravidla, která označuje za dočasné řešení do doby, než bude vydána oprava.

Dosud nebyl potvrzen žádný útok, veřejně šířený kód exploitu se neukázal jako funkční a žádná z těchto chyb není uvedena v katalogu známých zneužitých chyb agentury CISA. PHP zatím neupřesnilo, které verze jsou postiženy, která část PHP je zapojena ani zda nějaké nastavení riziko mění.

PHP je všude

PHP pohání velké množství webů a služeb. Kromě webů postavených na systémech WordPress, Drupal, Joomla nebo Magento může být součástí také hostingových platforem, ovládacích panelů či dodávaného softwaru. Organizace proto nemusí mít přehled o všech instalacích, které spravují nebo které jsou dostupné z internetu.

Zatím nebyla zveřejněna technická příčina chyb ani úplný seznam zasažených verzí. Ve veřejných zprávách se objevily odhady, že mohou být dotčeny verze PHP 5 až 8, ale podle dostupných informací to dosud nebylo oficiálně potvrzeno. Není tedy jasné ani to, zda bude oprava dostupná pro starší, již nepodporované verze.

Bezpečnostní výzkumníci potvrdili, že zranitelnosti jsou reálné. Společnost Huntress uvedla, že zatím ve sledovaných prostředích nezaznamenala aktivní zneužívání zmíněných chyb. Veřejně dostupný technický popis ani potvrzený exploit zatím nejsou k dispozici.

Co by měli správci udělat

Správci systémů by měli zmapovat všechna místa, kde PHP běží — nejen webové servery, ale také dodávané aplikace, zařízení, ovládací panely a systémy třetích stran. Po vydání oprav je důležité ověřit konkrétní zasažené verze a aktualizovat především systémy přístupné z internetu. Správci by měli zkontrolovat také balíčky od poskytovatele hostingu nebo distribuce Linuxu, které mohou obsahovat vlastní opravy přenesené do starších verzí.

U nepodporovaných instalací je vhodné naplánovat co nejdřívější aktualizaci. Pokud to není možné okamžitě, doporučuje se omezit jejich dostupnost z internetu nebo je dočasně umístit za další ochrannou vrstvu, například VPN či firewall pro webové aplikace.

Dočasným varovným signálem může být neobvyklá aktivita procesů PHP. Správci by měli věnovat pozornost případům, kdy procesy webového serveru spouštějí shell, nebo další nástroje pro stahování souborů. Při podezření na kompromitaci je namístě server izolovat, uchovat systémové a webové logy a prověřit, zda se neobjevily neznámé soubory, naplánované úlohy či nové účty.