Kritické zraniteľnosti PHP si vyžiadali reakciu aj v ui42. V 200 projektoch sme najprv upravili konfiguráciu PHP a Apache, následne nasadzovali bezpečnostné opravy. Tam, kde ich nasadeniu bránila verzia operačného systému, sme aktualizovali aj serverové prostredie. Ani jeden z riešených webov sme pritom nemuseli preventívne odstaviť.
V stredu 21. októbra 2026 sa bezpečnostný problém v PHP prejavil aj na dostupnosti slovenských aj svetových webov. Preventívne opatrenia sa dotkli ministerstva vnútra, Centrálneho registra zmlúv či Železničnej spoločnosti Slovensko. Podstatné je slovo preventívne: odstavenie týchto stránok samo osebe neznamenalo, že ich niekto úspešne napadol. Správcovia ich vypínali, aby obmedzili riziko.
V ui42 sme tú istú hrozbu riešili bez potreby preventívneho vypínania webov. Za týmto výsledkom však nebolo vyčkávanie. Náš vývojový tím vykonal zásahy v 200 projektoch od úpravy konfigurácie až po aktualizácie serverov.
Čo je PHP2Shell a prečo bolo potrebné konať
Pod označením PHP2Shell sa hovorí o dvojici kritických zraniteľností PHP: CVE-2026-109618 a CVE-2026-109619. SK-CERT na ne upozornil 21. októbra 2026. Obe získali hodnotenie závažnosti 9,2 z 10 podľa CVSS 4.0 a ich úspešné zneužitie mohlo umožniť vzdialené spustenie kódu bez prihlásenia.
Nešlo teda o chybu jedného pluginu ani konkrétneho webu. Problém bol v samotnom PHP, ktoré na serveri vykonáva kód aplikácie. Samotná aktualizácia WordPressu, iného redakčného systému alebo jeho doplnkov túto zraniteľnosť neodstraňovala. Zásah bol potrebný na úrovni serverového prostredia.
Vývojári PHP vydali bezpečnostné opravy 21. októbra. Zároveň zdôraznili, že dočasné opatrenia môžu obmedziť konkrétne spôsoby útoku, ale nenahrádzajú aktualizáciu.
Práve na tomto rozdiele stála aj naša reakcia: najprv znížiť riziko dostupnými opatreniami, následne nasadiť opravy.
Prvá fáza: úpravy PHP a Apache v 80 projektoch
Ešte pred nasadením bezpečnostných aktualizácií sme podľa odporúčaní SK-CERT pristúpili k úpravám konfigurácie PHP a webového servera Apache. Tento zásah sme vykonali naprieč 200 projektmi.
„Najprv sme upravili nastavenia PHP a Apache v rámci 200 projektov. Po 16.00 sme nasadzovali bezpečnostné opravy PHP. Na serveroch, kde ich nasadenie komplikovala verzia Ubuntu, sme aktualizovali aj serverové prostredie,“ opisuje Radoslav Kuchár, Head of Development v ui42.
Odporúčania, z ktorých sme vychádzali, zahŕňali napríklad dočasné vypnutie funkcie Session Upload Progress nastavením session.upload_progress.enabled=0. Pri službách, ktoré nepotrebujú nahrávanie súborov ani multipart formuláre, odporúčal zvážiť blokovanie požiadaviek multipart/form-data ešte pred ich spracovaním v PHP. Pri ostatných bolo potrebné zohľadniť nevyhnutnú funkcionalitu.
Konfiguračné zásahy sme nepovažovali za konečné riešenie. Boli prvou fázou reakcie, po ktorej nasledovalo nasadzovanie bezpečnostných opráv.
Druhá fáza: po 16.00 sme nasadzovali opravy PHP
Po 16.00 sme pristúpili k nasadzovaniu opráv PHP v riešených prostrediach.
Táto fáza bola zásadná. Kým predchádzajúce konfiguračné opatrenia obmedzovali možnosti zneužitia, aktualizácie PHP riešili samotné dve kritické zraniteľnosti. Opravené vydania boli PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35; pri distribučných balíkoch bolo potrebné sledovať dostupnosť opráv od ich poskytovateľa. PHP
Náš zásah sa preto neskončil pri zmene nastavení. Pokračovali sme nasadzovaním opráv aj riešením prekážok, ktoré sa pri jednotlivých serveroch objavili.
Na časti serverov bolo potrebné aktualizovať aj Ubuntu
Nie všetky serverové prostredia umožňovali rovnaký postup. Na časti serverov nebolo možné potrebné opravy PHP nasadiť pre používanú verziu Ubuntu.
V týchto prípadoch sme preto pristúpili aj k aktualizácii operačného systému, aby bolo možné aktualizovať PHP.
To je podstatná časť celého zásahu: neriešili sme iba aplikáciu alebo jeden balík, ale aj prostredie, od ktorého jeho aktualizácia závisela. Keď priame nasadenie opravy nebolo možné, bolo potrebné vyriešiť túto závislosť.
Pre majiteľa webu sa podobná práca odohráva v pozadí. Pre technický tím však rozhoduje o tom, či sa bezpečnostná oprava dá skutočne nasadiť.
Ďalšia vrstva ochrany: prečo sa oplatí využívať Cloudflare
Prípad PHP2Shell ukázal, že pri kritických zraniteľnostiach rozhodujú hodiny. Podľa CEO spoločnosti Cloudflare Matthewa Princea zaznamenala ich sieť tisíce pokusov o zneužitie zraniteľností už 10 hodín pred ich verejným oznámením. Do 45 minút po zverejnení ich počet vzrástol na desaťtisíce, v priebehu dvoch hodín na státisíce a následne na milióny.
Útočníkom navyše pomáhajú automatizované nástroje a umelá inteligencia, ktoré môžu urýchliť vyhľadávanie a zneužívanie bezpečnostných slabín. Riziko sa zvyšuje aj vtedy, keď prevádzkovateľ webu nemá prehľad o technológiách, ktoré využíva, a nevie, že jeho PHP potrebuje bezpečnostnú aktualizáciu.
Preto odporúčame myslieť aj na ďalšiu vrstvu ochrany, napríklad Cloudflare. Jeho webový aplikačný firewall (WAF) dokáže pri správnej konfigurácii blokovať škodlivé požiadavky ešte predtým, než sa dostanú na server. Môže tak pomôcť znížiť riziko aj v čase, keď bezpečnostná oprava ešte nie je dostupná.
Cloudflare však nenahrádza aktualizácie PHP ani správu serverového prostredia. Najlepšou ochranou je kombinácia preventívnych bezpečnostných opatrení, pravidelných aktualizácií a rýchlej reakcie technického tímu.
Výsledok: žiadny preventívne odstavený web
V rámci reakcie na PHP2Shell sme v ui42 nemuseli preventívne odstaviť ani jeden z riešených webov. Postup zahŕňal konfiguračné zásahy v 200 projektoch, nasadzovanie opráv PHP a tam, kde to bolo potrebné, aj aktualizáciu serverového prostredia.
Nezostali sme teda pri dočasných opatreniach. Nadviazali sme na ne opravami a potrebnými aktualizáciami serverov.
Tento výsledok zároveň neznamená, že preventívne odstavenie bolo v iných organizáciách nesprávnym rozhodnutím. CERT-EU odporúčal pri nemožnosti včasného nasadenia opravy zvážiť izoláciu verejne dostupných aplikácií až do vykonania a overenia nápravy. Každé prostredie malo vlastné podmienky a možnosti zásahu. CERT-EU
Naša skúsenosť ukazuje konkrétny priebeh riešenia v ui42, nie univerzálny návod, podľa ktorého sa zraniteľné weby nikdy nemajú vypínať.
Čo tento prípad znamená pre majiteľov webov a e-shopov
Pri správe webu sa oplatí pýtať nielen na aktualizácie jeho obsahu a funkcií, ale aj na technológie, ktoré zabezpečujú jeho chod. Kto zodpovedá za aktualizácie PHP? Kto vie zasiahnuť do konfigurácie webového servera? A čo sa stane, keď bezpečnostnú opravu nemožno nasadiť bez aktualizácie operačného systému?
Prípad PHP2Shell tieto otázky preniesol z plánovania údržby do reálnej prevádzky. V ui42 sme riešili obe nadväzujúce úlohy: konfiguračné opatrenia aj následné opravy vrátane aktualizácie serverového prostredia.
Zásah sa týkal 200 projektov, ale ani jeden z riešených webov sme nemuseli preventívne vypnúť. To je výsledok, ktorý môžeme pomenovať spolu s konkrétnou prácou, ktorá za ním stála.
