Záplaty vyšly. Jenže ne pro všechny
Bezpečnostní doporučení k PHP2Shell bylo jednoduché: okamžitě aktualizujte PHP. Pro hostingové společnosti tím ale práce teprve začínala.
Oficiální opravy totiž dostaly pouze čtyři podporované větve PHP, od 8.2 do 8.5. Na sdílených serverech přitom stále běží množství webů se staršími verzemi, které už vývojáři PHP neudržují. Hostingy se proto rozdělily. Některé aktualizovaly jen podporované větve a ostatním zákazníkům doporučily upgrade. Jiné sáhly po backportech, které pro starší verze připravili správci balíčků, případně po vlastních opravách.
„Samotná oprava PHP nebyla technicky složitá. Nejtěžší bylo dostat ji co nejrychleji na všechny servery, včetně těch se zastaralými verzemi. Když máte na starosti 1 200 serverů, nemůžete si dovolit řešit každý zvlášť,“ vysvětluje Matúš Kosa, CTO Webglobe.
Podporované verze PHP se na serverech Webglobe podařilo aktualizovat přibližně za tři hodiny. Ještě týž večer přišly na řadu verze od PHP 5.6 výš. Pro ně připravil opravy Ondřej Surý. Verze pod 5.6 žádnou opravu neměly. Tým Webglobe je musel připravit sám a jejich nasazování pokračovalo celý následující den.
Ani aktualizace podporovaných verzí se neobešla bez komplikací. Vyžadovaly restart příslušných služeb, což znamenalo krátkou nedostupnost webů. Dočasná ochranná opatření se před vydáním oprav podařilo nasadit jen na část infrastruktury. Podle vývojářů PHP navíc neexistoval způsob, jak zranitelnosti bez aktualizace zcela odstranit.
Největší komplikace však přišla s LiteSpeed.
„LiteSpeed používá vlastní PHP balíčky, ale pro verze 7.4, 8.0 a 8.1 neměl opravy. Museli jsme proto narychlo přejít na balíčky Ondřeje Surého. Jenže repozitáře byly přetížené. U jedné starší verze jsme dokonce dočasně vynechali méně používané rozšíření, abychom aktualizaci zbytečně nezdržovali,“ popisuje Kosa.
Podobné provozní komplikace se do bezpečnostních oznámení obvykle nedostanou. Přitom právě na nich často závisí, zda poskytovatel zvládne kritickou opravu nasadit během několika hodin, nebo až následující den.
Tisíce odražených útoků? Tak jednoduché to není
Krátce po zveřejnění PHP2Shell začala média informovat o masivní vlně útoků. Cloudflare během prvních 24 hodin zaznamenal miliony požadavků souvisejících se zranitelnostmi.
Jenže podezřelý požadavek, pokus o zneužití zranitelnosti a úspěšný průnik jsou tři různé věci.
Také Webglobe zaznamenal tisíce požadavků souvisejících s PHP2Shell. Neodpovídaly však tehdy známému způsobu zneužití zranitelnosti. Šlo především o automatické kontroly, které měly odhalit zranitelné servery.
„Mohli bychom napsat, že jsme odrazili tisíce útoků. Jenže to by nebyla pravda. Podle tehdy dostupných informací vedl útok přes speciálně sestavené POST požadavky, a ty jsme neviděli. Šlo hlavně o skeny. Posílaly je nástroje, které vznikly po zveřejnění zranitelností, aby si provozovatelé mohli ověřit, zda jsou jejich servery zranitelné,“ vysvětluje Kosa.
Podobně opatrný byl i bezpečnostní tým PHP. Mezi ukázkami exploitů, které se bezprostředně po zveřejnění šířily internetem, nenašel ani jednu funkční.
To ovšem neznamená, že skutečné útoky nehrozily.
Amazon zpětně identifikoval první pokus o zneužití už 17. října, čtyři dny před zveřejněním záplat. První potvrzený průnik zachytily honeypoty 24. října. O dva dny později zařadila americká agentura CISA obě zranitelnosti do katalogu aktivně zneužívaných chyb.
Samotný počet podezřelých požadavků proto o bezpečnosti hostingu mnoho nevypovídá. Rozhodující je, zda server dostal záplatu dřív, než na něj dorazil funkční exploit.
AI našla čtrnáct let staré chyby. A změnila pravidla hry.
Na PHP2Shell je pozoruhodné především to, jak dlouho zranitelnosti zůstávaly neodhalené. Problematický kód existoval přinejmenším od PHP 5.4 z roku 2012.
V srpnu 2026 chyby nezávisle objevili výzkumníci společností Calif a Wiz za pomoci pokročilých AI modelů. Podle Cloud Security Alliance dospěly ke stejnému závěru tři nezávislé týmy během přibližně pěti týdnů.
Společnost Wiz přitom uvedla, že prokázat praktickou zneužitelnost chyby by bylo bez AI mimořádně obtížné.
„AI ty chyby nevytvořila. V PHP byly čtrnáct let a prošla kolem nich spousta lidí i bezpečnostních nástrojů. O jednom z problémů s pamětí se podle všeho dokonce vědělo. Jen nikdo nedokázal prokázat, že z něj lze udělat funkční útok,“ říká Kosa.
AI tak na jedné straně výrazně usnadňuje a zlevňuje hledání zranitelností. Na druhé straně ale dává útočníkům do rukou stejně mocný nástroj, s jehož pomocí mohou nově objevené chyby okamžitě zneužít.
Jakmile vyjde bezpečnostní aktualizace, je možné porovnat opravený kód s původním a odhalit, co přesně se změnilo. Tato technika, známá jako patch diffing, není nová. AI ale výrazně urychluje analýzu změn i přípravu exploitu.
Pro provozovatele infrastruktury to znamená jediné: času na aktualizaci ubývá.
Zatímco hledání zranitelností PHP2Shell trvalo týdny a příprava oprav přibližně dva měsíce, po jejich zveřejnění se začalo počítat v hodinách. Situaci navíc zkomplikoval únik informací před plánovaným termínem, který přiměl tým PHP vydat aktualizace dříve.
Amazon po incidentu doporučil měřit dobu potřebnou k nasazení kritických záplat v hodinách, nikoli ve dnech.
„Dřív bylo možné spoléhat na to, že vytvořit funkční exploit z nové záplaty nějakou dobu potrvá. AI tuhle výhodu obránců zmenšuje. Proto se musíme soustředit nejen na hledání chyb, ale hlavně na rychlost jejich opravování,“ upozorňuje Kosa.
U Webglobe trvalo nasazení záplat na podporované verze PHP přibližně tři hodiny. U těch nejstarších téměř dva dny.
„Na chybu, kterou ještě nikdo neobjevil, nemůžete mít připravenou záplatu. A u nejstarších verzí PHP ani nemáte jistotu, že ji někdo vydá. Jediné, co můžete připravit předem, je krizový scénář a tým schopný okamžitě zasáhnout. V praxi to stále častěji může znamenat, že naši administrátoři a vývojáři stráví celou noc analýzou zranitelnosti, hledáním možností, jak riziko alespoň omezit, a přípravou vlastních oprav, jak to jsme zažili teď u PHP2Shell,“ říká Kosa.
Staré PHP: Bezpečnostní dluh, který za vás nikdo nesplatí
PHP2Shell také připomněl problém, který hostingové společnosti řeší už řadu let: obrovské množství webů stále používá zastaralé verze PHP.
Podle analýzy společnosti Mallory založené na datech ze Shodanu používalo 73,5 % z přibližně 2,6 milionu internetově dostupných PHP služeb, u kterých bylo možné zjistit verzi, PHP 8.1 nebo starší. Jde o údaj odvozený ze zveřejněných verzí PHP, nikoli o podíl všech webů nebo přesný počet skutečně zranitelných instalací. I tak dobře ilustruje rozsah problému.
Pro PHP 7.4, 8.0 a 8.1 poskytl tým PHP pouze základní úpravy zdrojového kódu. Ty ovšem provozovatelé museli sami zkompilovat, případně počkat na upravené balíčky. Pro ještě starší verze nebyly oficiálně připraveny ani tyto opravy.
„Útočníka nezajímá, jestli má vaše PHP ještě podporu. Zajímá ho, jestli v něm existuje zneužitelná chyba. A AI bude podobné chyby hledat i v kódu, který už dávno nikdo neudržuje,“ upozorňuje Kosa.
S každou další objevenou zranitelností se tak může prohlubovat rozdíl mezi podporovanými a nepodporovanými verzemi PHP.
Pro poskytovatele sdíleného webhostingu představuje zastaralé PHP ještě další problém. Kompromitovaný web může útočníkovi posloužit jako výchozí bod pro další útoky na server. Pokud se mu podaří zneužít další zranitelnost, například při eskalaci oprávnění nebo obejití izolace účtů, mohou být ohroženi i ostatní zákazníci.
Řetězení zranitelností přitom není jen teoretický scénář. Při útocích na administrační rozhraní firewallů Palo Alto Networks útočníci kombinovali PHP2Shell s další chybou v linuxovém jádře, aby získali práva správce.
„Bezpečnost sdíleného serveru není jen věcí jednoho zákazníka. Izolace účtů je důležitá, ale neměla by být jedinou obrannou linií. Pokud víme o kritické zranitelnosti PHP, musíme ji odstranit bez ohledu na to, jak starou verzi zákazník používá,“ vysvětluje Kosa.
Webglobe proto nabízí Rozšířenou podporu PHP, která zajišťuje bezpečnostní opravy starších verzí i po skončení jejich oficiální podpory. Služba se automaticky aktivuje webům používajícím PHP 8.1 a starší, a to na webhostingu i Managed VPS.
Právě při PHP2Shell se podle Kosy ukázalo, proč podobná služba dává smysl.
„U nejstarších verzí jsme ten večer zvažovali, jestli dotčené weby raději dočasně nevypnout. Nakonec jsme ale připravili vlastní záplaty a opravili i je. Chráníme tím nejen konkrétní zákazníky, ale celou sdílenou infrastrukturu.“
Rozšířená podpora ovšem není trvalou náhradou upgradu.
Záplata PHP totiž neřeší chyby ve starém WordPressu, neudržovaných pluginech ani zastaralých šablonách. Zákazníkům poskytuje čas na přechod, nikoli důvod aktualizace donekonečna odkládat.
Další důležitý termín se přitom blíží: oficiální bezpečnostní podpora PHP 8.2 končí 31. prosince 2026.
Hosting už není jen o rychlosti a ceně
Výkon procesoru, kapacita disku, rychlost webu a cena. To jsou parametry, podle kterých se hostingové služby tradičně porovnávají. Bezpečnost serverové infrastruktury zákazníci většinou považují za samozřejmost.
PHP2Shell ale ukázal, že mezi poskytovateli mohou být zásadní rozdíly v parametru, který v produktových tabulkách obvykle nenajdete: v rychlosti reakce na kritickou zranitelnost.
Na sdíleném hostingu si zákazník PHP sám neopraví. Nemá k tomu potřebná oprávnění a ani by to neměla být jeho odpovědnost. Je odkázán na provozovatele infrastruktury.
„Zákazník by měl vědět, kdo jeho PHP aktualizuje, jak rychle a co se stane, když používá verzi bez oficiální podpory. Na tyto otázky by měl umět odpovědět každý poskytovatel. Kdo provozuje vlastní server nebo nespravovanou VPS, musí mít odpovídající proces nastavený sám,“ říká Kosa.
S nástupem AI význam tohoto procesu dál poroste. Bezpečnostní výzkumníci budou nacházet zranitelnosti, které roky unikaly pozornosti. Útočníkům ovšem stejné nástroje usnadní jejich analýzu i zneužití.
Výsledný závod proto nebude rozhodovat jen kvalita AI modelů, ale také připravenost lidí a infrastruktury.
„Rada ‚aktualizujte PHP‘ je samozřejmě správná. Jenže v praxi existují tisíce webů, které na novou verzi nepřejdou přes noc. To ale neznamená, že je můžeme nechat bez ochrany. Bezpečný hosting se podle mě pozná právě ve chvíli, kdy jednoduchá řešení přestanou fungovat. Za Webglobe můžu říct, že PHP2Shell nám také ukázal, kde máme prostor se zlepšit. Chceme především zrychlit nasazování oprav na nejstarší verze PHP a lépe připravit záložní postupy pro případ, že standardní řešení selžou. Na neznámou zranitelnost si záplatu předem nepřipravíte. Můžete ale zajistit, aby váš tým při příští krizi trávil čas řešením samotné chyby, ne zbytečných komplikací kolem ní,“ uzavírá Matúš Kosa, CTO Webglobe.
Nejdůležitější poučení z PHP2Shell je proto poměrně prosté. Nestačí vědět, že pro kritickou chybu existuje záplata. Rozhodující je, jak rychle ji dokážete dostat do provozu.
ČLÁNKY DO MAILU