Dne 21. října 2026 zveřejnil projekt PHP opravy dvou kritických zranitelností, které mohou umožnit vzdálené spuštění kódu bez přihlášení. Opravené verze jsou PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Oficiální doporučení je jednoznačné: uživatelé PHP mají prostředí ihned aktualizovat.
Pokud vaše firma používá starší aplikaci v PHP, neznamená to automaticky, že je nutné ji okamžitě přepsat. Nejprve je potřeba opravit běhové prostředí. Následný test kompatibility ukáže, zda aplikace může dál fungovat beze změn, potřebuje aktualizaci závislostí, etapovou modernizaci nebo řízenou přestavbu.
Přepsání kódu aplikace neopraví zranitelnost interpretu PHP. Samotná aktualizace PHP zase nezaručuje kompatibilitu staré aplikace s novým prostředím. Jde o dva samostatné problémy a dvě samostatná rozhodnutí.
Zdroje naposledy ověřeny: 23. 10. 2026. Před změnou zkontrolujte aktuální oznámení projektu PHP a informace dodavatele operačního systému, hostingu nebo kontejnerového obrazu.
Co přesně oznámil projekt PHP?
Oznámení z 21. října se týká CVE-2026-109618 a CVE-2026-109619. Projekt PHP uvádí, že riziko se týká instalací obsluhujících webové požadavky, včetně PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Nejvyšší riziko bylo popsáno u mod_php, kde bylo prokázáno, že neověřený požadavek může útok spustit ještě před kódem aplikace.
Opravy obsahují verze:
- PHP 8.5.12;
- PHP 8.4.27;
- PHP 8.3.36;
- PHP 8.2.35.
Tyto čtyři verze nejsou volně zaměnitelné cíle. Aktualizujte v rámci větve používané vaším prostředím nebo postupujte podle cesty podporované dodavatelem operačního systému, hostingu či kontejnerového obrazu. Pokud dodavatel poskytuje vlastní balíček se zpětně přenesenou opravou, ověřte tento stav v jeho bezpečnostním oznámení. Samotné číslo verze nemusí stačit.
PHP 8.1 a starší větve již nedostávají aktualizace od projektu PHP. PHP 8.2 je nyní podporováno pouze opravami kritických bezpečnostních problémů, a to do 31. prosince 2026. Přechod na novější větev proto může být samostatným projektem kompatibility i po instalaci naléhavé opravy.
Dodatečná informace z 23. října 2026
Dne 23. října projekt PHP popsal málo pravděpodobný způsob vzdáleného spuštění kódu související s session.upload_progress. Do dalšího pravidelného vydání s opravami doporučil nastavit session.upload_progress.enabled=0. Problém vyžaduje neobvyklou kombinaci konfigurace a chování aplikace. Aplikace, které za běhu nikdy nemění způsob serializace relace, mohou podle oznámení nechat tuto funkci zapnutou.
Jde o dočasné doporučení závislé na konfiguraci. Nenahrazuje aktualizaci PHP a změna bez kontroly může ovlivnit funkce používající průběh nahrávání souborů. Nejprve ověřte, zda je nastavení relevantní, a otestujte dopad změny.
První krok: ověřte prostředí, které obsluhuje web
Výstup php -v v terminálu může popisovat příkazovou řádku, nikoli PHP obsluhující webové požadavky. Jeden server může používat jinou verzi nebo konfiguraci pro web, plánované úlohy a fronty.
Před určením rozsahu práce zjistěte:
- která verze PHP skutečně obsluhuje veřejnou aplikaci;
- jaké SAPI nebo napojení na server se používá, například FPM, mod_php nebo CGI;
- odkud pochází konfigurace a kdo odpovídá za její změnu;
- zda balíček operačního systému nebo kontejnerový obraz obsahuje zpětně přenesenou opravu;
- jakou verzi PHP používají plánované úlohy, fronty, importy a servisní skripty;
- zda existuje obnovitelná záloha a cesta návratu;
- které firemní procesy je nutné ihned po změně ověřit.
Pokud mohla být aplikace již napadena, aktualizace není vyšetřením incidentu. Zachovejte relevantní stopy a dohodněte další kroky s osobou odpovědnou za infrastrukturu nebo reakci na incidenty. Tento článek takovou práci nenahrazuje.
Naléhavá aktualizace a modernizace aplikace jsou dva různé úkoly
Naléhavým cílem je provozovat vydání PHP s opravou nebo balíček, který příslušný dodavatel potvrdil jako opravený. Modernizace aplikace začíná ve chvíli, kdy kód, framework, knihovny nebo způsob nasazení aktualizaci blokují nebo činí její výsledek nepředvídatelným.
Bezpečné pořadí obvykle vypadá takto:
- určit prostředí, které skutečně zpracovává webové požadavky;
- použít nebo naplánovat bezpečnostní opravu dodavatele bez čekání na rozsáhlou přestavbu;
- připravit zálohu a ověřit její obnovu;
- spustit aplikaci v testovacím prostředí na opravené verzi PHP;
- zkontrolovat kritické procesy, integrace, fronty, plánované úlohy a operace se soubory;
- zapsat nekompatibility a oddělit naléhavé chyby od pozdějších zlepšení;
- zvolit nejmenší odůvodněnou etapu a určit její kritéria převzetí;
- nasadit změnu řízeně, restartovat potřebné procesy a ověřit účinnou verzi i hlavní procesy.
Nenechávejte zranitelnou veřejnou instanci dostupnou jen proto, abyste ověřili, zda stará aplikace stále funguje. Pokud práce na kompatibilitě trvá déle, je nutné riziko samostatně omezit na úrovni infrastruktury a provozu.
Čtyři možné směry po zabezpečení prostředí
| Směr | Kdy může stačit | Co je nutné ověřit |
|---|---|---|
| Aktualizace prostředí a test kompatibility | Aplikace a její závislosti podporují opravenou a udržovanou verzi PHP. | Zálohu, testovací prostředí, kritické procesy, úlohy na pozadí, integrace a návrat. |
| Aktualizace frameworku a závislostí | Firemní pravidla mají stále hodnotu, ale staré balíčky blokují nové prostředí. | Podporované cesty aktualizace, opuštěné balíčky, změny mezi verzemi, migrace dat a vlastní moduly. |
| Etapová modernizace | Části aplikace lze zachovat a problémy se soustředí do vybraných modulů nebo vrstev. | Hranice modulů, toky dat, pořadí výměny a období souběhu staré a nové části. |
| Řízená přestavba | Systém nelze bezpečně spustit v podporovaném prostředí nebo jeho architektura brání předvídatelnému rozvoji. | Firemní pravidla, data, integrace, rozsah první verze, přepnutí a cestu návratu. |
Samotná verze PHP k výběru směru nestačí. Stejná stará verze může v jedné aplikaci znamenat jednoduchou aktualizaci a v jiné rozsáhlejší projekt kompatibility.
Kdy může stačit samotná aktualizace prostředí?
Nejjednodušší varianta je možná, pokud aplikace používá podporovaný framework a knihovny, nasazení je opakovatelné a hlavní procesy lze před změnou otestovat. Rozsah se pak může omezit na přípravu zálohy, test opravené verze, aktualizaci prostředí a kontrolu po nasazení.
Ani tehdy nelze vynechat úlohy na pozadí. Plánované úlohy, fronty, importy a skripty mohou používat jinou konfiguraci než webová aplikace.
Kdy je nutné aktualizovat framework nebo knihovny?
Starší aplikace může obsahovat syntaxi odstraněnou z novějších verzí PHP, nepodporovaný framework nebo balíčky opuštěné jejich autory. Problémem mohou být také vlastní moduly a rozšíření, které nelze jednoduše nahradit.
Nejprve je vhodné určit nejmenší bezpečný rozsah kompatibility. Někdy stačí aktualizovat několik závislostí a omezenou část kódu. Jindy po sobě jdoucí verze frameworku vyžadují etapovou migraci. Z jediné chybové zprávy nelze udělat spolehlivý závěr.
Kdy modernizovat po etapách?
Etapová modernizace je rozumná, když aplikace stále zajišťuje důležité procesy, uchovává potřebná data a obsahuje části, které mohou dál fungovat. Místo přestavby všeho najednou lze nejprve ochránit kritické chování testy, stabilizovat nasazení a postupně měnit nejproblematičtější prvky.
Každá etapa má mít vlastní výsledek, kritéria převzetí a cestu návratu. Další rozhodnutí pak vycházejí z fungujícího systému, nikoli jen z předpokladů.
Širší kritéria popisuje článek Modernizace existujícího systému nebo vývoj od nuly.
Kdy může být přestavba opodstatněná?
Přestavbu stojí za to zvážit, pokud klíčové závislosti nejsou podporovány, aplikaci nelze reprodukovat v kontrolovaném prostředí, malé změny způsobují nepředvídatelné chyby nebo architektura neumožňuje oddělit procesy, které firma potřebuje.
Ani tehdy není nutné provést jedno velké přepnutí. Nejprve lze znovu vytvořit jeden proces, porovnat data a až podle výsledku rozšířit rozsah. Vývoj od nuly bez zmapování firemních pravidel často přenese staré problémy do nového kódu nebo odstraní chování, na které si při specifikaci nikdo nevzpomněl.
Dva příklady, dvě různé cesty
V projektu OBIBOOK jsme nejprve opravili nefunkční import CSV a zobrazení na mobilních zařízeních. Teprve po pochopení procesu jsme celý katalog knih přestavěli. Oprava a přestavba byly samostatné etapy.
U projektu Sprawdzeni.pl byla předchozí aplikace obtížně použitelná a pravidelně hlásila chyby. Její stav podporoval vývoj systému od nuly při zachování a rozšíření vizuální koncepce majitele.
Ani jeden projekt nezačal kvůli zranitelnostem popsaným v tomto článku. Ukazují pouze, že posouzení existujícího systému může vést k opravě, etapové práci nebo přestavbě. Pro každou starou aplikaci neexistuje jedna odpověď.
Co připravit pro první posouzení?
Nemusíte znát všechny technické podrobnosti. Užitečné budou:
- adresa a krátký popis role aplikace ve firmě;
- zpráva od hostingu nebo administrátora bez přístupových údajů;
- verze PHP a způsob jeho spuštění, pokud jsou známé;
- název a verze frameworku nebo CMS, pokud jsou známé;
- informace, odkud pochází kód a zda odpovídá produkční verzi;
- informace o zálohách, testovacím prostředí a způsobu nasazování;
- seznam procesů, které je nutné po aktualizaci ověřit;
- seznam integrací a úloh na pozadí;
- očekávaný výsledek první etapy.
Přes formulář neposílejte hesla, API klíče, kopie databáze ani data zákazníků. Bezpečný způsob předání materiálů dohodneme po stanovení rozsahu.
Předem můžete použít kontrolní seznam pro převzetí aplikace. Pomůže uspořádat dostupné informace, ale nenahrazuje technické posouzení.
Co nelze slíbit před kontrolou aplikace?
Před analýzou konkrétního systému nelze odpovědně zaručit, že:
- aktualizace PHP nebude vyžadovat změny kódu;
- všechny závislosti mají bezpečnou a kompatibilní náhradu;
- záloha umožní obnovit systém v požadovaném čase;
- každou část aplikace je vhodné zachovat;
- přestavba bude levnější než modernizace;
- samotná oprava PHP vyřeší všechny bezpečnostní problémy aplikace.
Pro širší rozpoznání rizik využijte bezpečnostní audit webové aplikace. Pokud systém po stabilizaci potřebuje trvalou péči, lze samostatně dohodnout správu aplikace nebo e-shopu.
Prověřme, co vaše aplikace potřebuje
Napište, k čemu firma systém používá, jaké oznámení vyvolalo potřebu změny a co se během aktualizace nesmí ztratit. Pokud znáte verzi PHP, framework, způsob spuštění a stav přístupu ke kódu a hostingu, uveďte je. Chybějící informace nebrání prvnímu rozhovoru.
Neposílejte tajné údaje ani data zákazníků. Na začátku potřebujeme popis situace a první očekávaný výsledek.
Prověřme, co vaše aplikace potřebuje, nebo nejprve uspořádejte podklady pomocí kontrolního seznamu.
Zdroje
Zdroje ověřeny 23. 10. 2026:
- PHP: Security advisory - Critical remote code execution vulnerabilities, update now
- PHP: Informational advisory - Session upload progress
- PHP: Supported Versions
- PHP security advisory: CVE-2026-109618, RCE via OOM corruption
- PHP security advisory: CVE-2026-109619, RCE via stale global state
- PHP Manual: php_sapi_name
- PHP Manual: phpversion