Kritické zranitelnosti PHP si vyžádaly reakci i v ui42. Ve 200 projektech jsme nejprve upravili konfiguraci PHP a Apache, následně nasazovali bezpečnostní opravy. Tam, kde jejich nasazení bránila verze operačního systému, jsme aktualizovali i serverové prostředí. Ani jeden z řešených webů jsme přitom nemuseli preventivně odstavit.
Ve středu 21. října 2026 se bezpečnostní problém v PHP projevil i na dostupnosti slovenských i světových webů. Preventivní opatření se dotkla ministerstva vnitra, Centrálního registru smluv či Železniční společnosti Slovensko. Podstatné je slovo preventivní: odstavení těchto stránek samo o sobě neznamenalo, že je někdo úspěšně napadl. Správci je vypínali, aby omezili riziko.
V ui42 jsme tu stejnou hrozbu řešili bez potřeby preventivního vypínání webů. Za tímto výsledkem však nebylo vyčkávání. Náš vývojový tým provedl zásahy ve 200 projektech od úpravy konfigurace až po aktualizace serverů.
Co je PHP2Shell a proč bylo nutné jednat
Pod označením PHP2Shell se hovoří o dvojici kritických zranitelností PHP: CVE-2026-109618 a CVE-2026-109619. SK-CERT na ně upozornil 21. října 2026. Obě získaly hodnocení závažnosti 9,2 z 10 podle CVSS 4.0 a jejich úspěšné zneužití mohlo umožnit vzdálené spuštění kódu bez přihlášení.
Nešlo tedy o chybu jednoho pluginu ani konkrétního webu. Problém byl v samotném PHP, které na serveru vykonává kód aplikace. Samotná aktualizace WordPressu, jiného redakčního systému nebo jeho doplňků tuto zranitelnost neodstraňovala. Zásah byl potřebný na úrovni serverového prostředí.
Vývojáři PHP vydali bezpečnostní opravy 21. října. Zároveň zdůraznili, že dočasná opatření mohou omezit konkrétní způsoby útoku, ale nenahrazují aktualizaci.
Právě na tomto rozdílu stála i naše reakce: nejprve snížit riziko dostupnými opatřeními, následně nasadit opravy.
První fáze: úpravy PHP a Apache v 80 projektech
Ještě před nasazením bezpečnostních aktualizací jsme podle doporučení SK-CERT přistoupili k úpravám konfigurace PHP a webového serveru Apache. Tento zásah jsme provedli napříč 200 projekty.
„Nejprve jsme upravili nastavení PHP a Apache v rámci 200 projektů. Po 16.00 jsme nasazovali bezpečnostní opravy PHP. Na serverech, kde jejich nasazení komplikovala verze Ubuntu, jsme aktualizovali i serverové prostředí,“ popisuje Radoslav Kuchár, Head of Development v ui42.
Doporučení, z nichž jsme vycházeli, zahrnovala například dočasné vypnutí funkce Session Upload Progress nastavením session.upload_progress.enabled=0. U služeb, které nepotřebují nahrávání souborů ani multipart formuláře, doporučoval zvážit blokování požadavků multipart/form-data ještě před jejich zpracováním v PHP. U ostatních bylo třeba zohlednit nezbytnou funkcionalitu.
Konfigurační zásahy jsme nepovažovali za konečné řešení. Byly první fází reakce, po které následovalo nasazování bezpečnostních oprav.
Druhá fáze: po 16.00 jsme nasazovali opravy PHP
Po 16.00 jsme přistoupili k nasazování oprav PHP v řešených prostředích.
Tato fáze byla zásadní. Zatímco předchozí konfigurační opatření omezovala možnosti zneužití, aktualizace PHP řešily samotné dvě kritické zranitelnosti. Opravené vydání byly PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35; u distribučních balíků bylo třeba sledovat dostupnost oprav od jejich poskytovatele. PHP
Náš zásah se proto neskončil při změně nastavení. Pokračovali jsme nasazováním oprav i řešením překážek, které se při jednotlivých serverech objevily.
Na části serverů bylo třeba aktualizovat i Ubuntu
Ne všechna serverová prostředí umožňovala stejný postup. Na části serverů nebylo možné potřebné opravy PHP nasadit pro používanou verzi Ubuntu.
V těchto případech jsme proto přistoupili i k aktualizaci operačního systému, aby bylo možné aktualizovat PHP.
To je podstatná část celého zásahu: neřešili jsme pouze aplikaci nebo jeden balík, ale i prostředí, od kterého jeho aktualizace závisela. Když přímé nasazení opravy nebylo možné, bylo třeba vyřešit tuto závislost.
Pro majitele webu se podobná práce odehrává v pozadí. Pro technický tým však rozhoduje o tom, zda se bezpečnostní oprava dá skutečně nasadit.
Další vrstva ochrany: proč se vyplatí využívat Cloudflare
Případ PHP2Shell ukázal, že při kritických zranitelnostech rozhodují hodiny. Podle CEO společnosti Cloudflare Matthewa Prince zaznamenala jejich síť tisíce pokusů o zneužití zranitelností již 10 hodin před jejich veřejným oznámením. Do 45 minut po zveřejnění jejich počet vzrostl na desetitisíce, v průběhu dvou hodin na statisíce a následně na miliony.
Útočníkům navíc pomáhají automatizované nástroje a umělá inteligence, které mohou urychlit vyhledávání a zneužívání bezpečnostních slabin. Riziko se zvyšuje i tehdy, když provozovatel webu nemá přehled o technologiích, které využívá, a neví, že jeho PHP potřebuje bezpečnostní aktualizaci.
Proto doporučujeme myslet i na další vrstvu ochrany, například Cloudflare. Jeho webový aplikační firewall (WAF) dokáže při správné konfiguraci blokovat škodlivé požadavky ještě předtím, než se dostanou na server. Může tak pomoci snížit riziko i v době, kdy bezpečnostní oprava ještě není dostupná.
Cloudflare však nenahrazuje aktualizace PHP ani správu serverového prostředí. Nejlepší ochranou je kombinace preventivních bezpečnostních opatření, pravidelných aktualizací a rychlé reakce technického týmu.
Výsledek: žádný preventivně odstavený web
V rámci reakce na PHP2Shell jsme v ui42 nemuseli preventivně odstavit ani jeden z řešených webů. Postup zahrnoval konfigurační zásahy ve 200 projektech, nasazování oprav PHP a tam, kde to bylo třeba, i aktualizaci serverového prostředí.
Nezůstali jsme tedy při dočasných opatřeních. Navázali jsme na ně opravami a potřebnými aktualizacemi serverů.
Tento výsledek zároveň neznamená, že preventivní odstavení bylo v jiných organizacích nesprávným rozhodnutím. CERT-EU doporučoval při nemožnosti včasného nasazení opravy zvážit izolaci veřejně dostupných aplikací až do provedení a ověření nápravy. Každé prostředí mělo vlastní podmínky a možnosti zásahu. CERT-EU
Naše zkušenost ukazuje konkrétní průběh řešení v ui42, nikoli univerzální návod, podle kterého se zranitelné weby nikdy nemají vypínat.
Co tento případ znamená pro majitele webů a e-shopů
Při správě webu se vyplatí ptát nejen na aktualizace jeho obsahu a funkcí, ale i na technologie, které zajišťují jeho chod. Kdo zodpovídá za aktualizace PHP? Kdo ví zasáhnout do konfigurace webového serveru? A co se stane, když bezpečnostní opravu nelze nasadit bez aktualizace operačního systému?
Případ PHP2Shell tyto otázky přenesl z plánování údržby do reálného provozu. V ui42 jsme řešili obě navazující úkoly: konfigurační opatření i následné opravy včetně aktualizace serverového prostředí.
Zásah se týkal 200 projektů, ale ani jeden z řešených webů jsme nemuseli preventivně vypnout. To je výsledek, který můžeme pojmenovat spolu s konkrétní prací, která za ním stála.
