PHP2Shell ohrozuje weby naprieč internetom. Čo je potvrdené a prečo samotný firewall nestačí

Dve kritické chyby v jadre PHP umožňujú za určitých podmienok spustiť kód bez prihlásenia. Opravy sú dostupné, no prevádzkovatelia musia aktualizovať samotné PHP.

Web môže mať aktuálny redakčný systém, bezpečné heslá aj pravidelne kontrolované doplnky, a predsa zostať zraniteľný. Dôvodom je vrstva pod aplikáciou: PHP, ktoré na serveri spracúva požiadavky návštevníkov. Projekt PHP 21. októbra 2026 vydal štyri opravné verzie pre dve kritické chyby súhrnne označované ako PHP2Shell. Za určitých podmienok umožňujú útočníkovi spustiť vlastný kód bez prihlásenia. Rozhodujúca otázka preto neznie, či je aktualizovaný web, ale či je opravené PHP, na ktorom skutočne beží.

Udalosť vyvolala aj preventívne odstávky niektorých služieb. The Verge opisuje nedostupnosť viacerých známych webov, no zo samotnej odstávky nemožno vyvodiť, že sa do nich útočník dostal. Prevádzkovateľ môže službu vypnúť práve preto, aby prieniku zabránil. Pri takto rozšírenej technológii treba dôsledne odlišovať potvrdenú zraniteľnosť, zachytený útočný pokus a preukázané kompromitovanie konkrétneho servera.

Čo sa skrýva pod názvom PHP2Shell

Projekt PHP eviduje problémy ako CVE-2026-109618 a CVE-2026-109619. Obe chyby súvisia s tým, ako samotné PHP nakladá s pamäťou pri spracovaní webovej požiadavky a pri chybe. Nejde o slabé heslo administrátora ani o chybu jedného konkrétneho doplnku. PHP ich hodnotí ako kritické; každá dosahuje 9,2 bodu podľa metodiky CVSS 4.0. Toto skóre vyjadruje závažnosť technického problému, nie počet serverov, do ktorých sa už niekto vlámal.

Pri prvej chybe môže nedostatok pamäte prerušiť spracovanie vo chvíli, keď ešte vnútorné údaje nie sú úplne pripravené. Následné upratovanie s nimi môže pracovať, akoby boli platné. Pri druhej môžu po skončení požiadavky zostať odkazy na pamäť, ktorá už bola uvoľnená. Ak ten istý proces vybavuje ďalšiu požiadavku, môže sa o takéto neplatné údaje znovu oprieť. Zjednodušené vysvetlenie nevystihuje celý postup útoku, ukazuje však jeho podstatu: problém nastáva hlboko v serverovom prostredí.

Výskumníci spoločnosti Wiz uvádzajú, že na testovaných nasadeniach predviedli vykonanie kódu bez prihlásenia pri aplikáciách WordPress, Drupal a Joomla. Demonštrovali aj možnosť získať citlivé údaje z pamäte procesu bez toho, aby najprv museli spustiť vlastný kód. Ide o výsledky ich bezpečnostného výskumu, nie o dôkaz, že každý web s týmito systémami už bol napadnutý. Konkrétna cesta zneužitia môže závisieť od verzie, konfigurácie a spôsobu prevádzky PHP.

Odporúčame

Dôležité Biznis 21. októbra 2026

Meta má zaplatiť 25 miliárd dolárov: čo stojí za verdiktom o súkromí Facebooku

Súd v Novom Mexiku uložil Mete sankciu 25 miliárd dolárov. Rozoberáme, čo porota skutočne posudzovala, ako vznikla suma a prečo nejde o zaplatené odškodnenie.

9 min 0

Dôležité AI 21. októbra 2026

Anthropic vykázal stratu 80,7 miliardy dolárov. Čo čísla pred plánovaným IPO skutočne hovoria?

Anthropic mal podľa návrhu prospektu za prvý polrok 2026 stratu 80,7 miliardy dolárov. Väčšinu tvorili účtovné úpravy; tržby aj náklady na výpočtovú kapacitu prudko rástli.

9 min 0

Rozsah rizika nie je to isté ako počet napadnutých webov

Podľa merania W3Techs používa PHP 69,3 percenta webov, pri ktorých služba pozná serverový programovací jazyk. Menovateľom teda nie sú bez výnimky všetky webové stránky na svete. Číslo dobre vysvetľuje, prečo má chyba v PHP mimoriadny dosah, ale nie je počtom zraniteľných ani kompromitovaných serverov. Každý prevádzkovateľ potrebuje poznať vlastnú verziu a pôvod bezpečnostných aktualizácií; všeobecná štatistika mu stav jeho systému neprezradí.

Oficiálne upozornenie projektu PHP zahŕňa inštalácie obsluhujúce webové požiadavky cez PHP-FPM, modul mod_php v Apache, php-cgi, FrankenPHP aj LiteSpeed. Najvyššie riziko projekt pripisuje konfigurácii mod_php, pri ktorej bol predvedený útok vyvolateľný anonymnou požiadavkou ešte pred spustením aplikačného kódu. Neznamená to však, že pri ostatných spôsoboch nasadenia možno opravu odložiť. Výrobca vyzýva na aktualizáciu všetkých dotknutých prevádzkovateľov PHP.

WordPress v samostatnom upozornení výslovne oddeľuje svoju aplikáciu od serverového prostredia. Pre tieto dve chyby neplánuje aktualizáciu WordPressu, pretože oprava patrí do PHP. Rovnaký princíp platí pri inej aplikácii postavenej na PHP: aktualizovať jej kód je užitočné pre jej vlastnú bezpečnosť, ale tento problém tým nezmizne. Rozdiel je dôležitý najmä na zdieľanom hostingu, kde môže vlastník stránky spravovať WordPress, no verziu PHP mení poskytovateľ.

Ako sa chyba dostala z výskumu do naliehavého varovania

Príbeh sa nezačal v deň vydania záplaty. PHP Foundation uvádza, že prvé náznaky problému súvisiaceho s nedostatkom pamäte zaznamenal vývojár pri bezpečnostnej práci už v roku 2024. Vtedy sa uvažovalo o možnom zneužití, ale nebol známy konkrétny postup s preukázaným dosahom. Nadácia dnes otvorene priznáva, že rozhodovanie o zložitej oprave brzdili kompromisy týkajúce sa kompatibility a výkonu, malý počet špecialistov aj spôsob prijímania rozhodnutí v bezpečnostnom tíme.

V roku 2026 prišli konkrétnejšie dôkazy. Podľa PHP Foundation začala spoločnosť Calif audit 30. júla a 11. augusta nahlásila možnosť spustenia kódu spojenú s problémom známym z roku 2024. OpenAI v ten istý deň nezávisle nahlásila rovnakú základnú príčinu; Wiz doručil ďalšie zistenia 24. augusta. OpenAI uvádza, že Calif pri výskume použila model GPT-5.6 Sol. Wiz opisuje využitie viacerých nástrojov AI pri hľadaní a overovaní útočných postupov.

Podstatné nie je tvrdenie, že umelá inteligencia sama opravila internet. Pomohla výskumníkom premeniť dlho známy, ale ťažko uchopiteľný problém na overiteľné bezpečnostné hlásenia. Opravu pripravili a vydali správcovia PHP. Ako uvádza PHP Foundation, ľudia zároveň vyhodnocujú hlásenia, rozhodujú o zásahoch do kódu a kontrolujú ich dôsledky. Ten istý pokrok vo výskumných nástrojoch však môže skrátiť čas, ktorý budú po zverejnení detailov potrebovať útočníci.

Útočné požiadavky áno, potvrdené prieniky nie automaticky

Koordinované zverejnenie skomplikoval únik identifikátorov chýb 20. októbra. PHP Foundation opisuje aj predčasne zverejnené ukážkové materiály a balíky obsahujúce opravu. Pôvodne plánované vydanie sa preto presunulo na 21. októbra. Nadácia zároveň uvádza, že jej bezpečnostný tím v čase zverejnenia opráv neidentifikoval funkčný exploit medzi verejne sa šíriacimi ukážkami. Toto tvrdenie má presnú hranicu: nehovorí, že sa nikto nepokúšal o útok alebo že útok nemohol fungovať.

Cloudflare naopak uvádza, že v prevádzke svojich zákazníkov zaznamenal požiadavky cieliace na PHP2Shell a zmeny útočných dát, ktorými sa ich autori snažili obísť ochranné pravidlá. To nie je nevyhnutne rozpor s PHP Foundation. Cloudflare hovorí o pozorovanej útočnej aktivite, kým nadácia o stave verejne dostupných funkčných ukážok v konkrétnom okamihu. Bez ďalšieho potvrdenia nemožno z týchto vyjadrení vypočítať počet úspešne napadnutých webov.

Oprava existuje. Ktorú verziu treba nasadiť?

Od 21. októbra sú dostupné opravené vydania PHP 8.2.35, 8.3.36, 8.4.27 a 8.5.12. Správca by mal aktualizovať vetvu, ktorú jeho web skutočne používa, a overiť výsledok na serveri obsluhujúcom návštevníkov. Nestačí skontrolovať iba verziu nástroja spúšťaného z príkazového riadka, ak web využíva samostatný proces alebo iný balík PHP. Po aktualizácii treba zabezpečiť, aby služba používala nový kód, a preskúšať fungovanie aplikácie.

Pri balíkoch linuxových distribúcií je potrebné sledovať bezpečnostné oznámenie dodávateľa. Projekt PHP poskytol opravy distribúciám a poskytovateľom dlhodobej podpory vopred; niektorí ich môžu preniesť do vlastného balíka. Samotné číslo hlavnej verzie potom nemusí povedať celý príbeh. PHP 8.1 a staršie vetvy už nedostávajú štandardné bezpečnostné vydania od projektu. Ten sprístupnil obmedzené opravy zdrojového kódu pre 7.4, 8.0 a 8.1, čo však nie je nová oficiálna aktualizovaná verzia pre každú starú inštaláciu.

Majiteľ webu na spravovanom hostingu má položiť poskytovateľovi konkrétnu otázku: ktorá verzia PHP alebo ktorý opravený balík dnes spracúva požiadavky jeho stránky? Pri WordPresse môže v administrácii nájsť údaje o serveri v časti Nástroje, Zdravie stránky, Informácie. Táto kontrola je začiatkom, nie náhradou potvrdenia od hostingu pri spätne prenesených opravách. Správca viacerých služieb musí skontrolovať aj ďalšie weby, testovacie prostredia a aplikácie, ktoré využívajú vlastné nasadenie PHP.

Cloudflare nasadil pravidlá webového aplikačného firewallu aj pre zákazníkov bezplatného plánu. Sú doplnkovou vrstvou: podľa firmy vedia zachytiť známe podoby útoku, ale správca má PHP napriek tomu opraviť. Projekt PHP upozorňuje, že žiadne zverejnené dočasné opatrenie nepokrýva problém úplne. Preto nie je bezpečné považovať zapnutý firewall, obmedzenie nahrávania súborov či jedinú zmenu konfigurácie za rovnocennú aktualizácii.

Kedy má zmysel službu dočasne vypnúť?

Britské Národné centrum kybernetickej bezpečnosti odporúča prednostne identifikovať inštalácie PHP dostupné z internetu a nasadiť opravy. Ak ich nemožno vykonať bezodkladne, treba vyhodnotiť dočasné opatrenia; keď nie sú uskutočniteľné alebo by trvali príliš dlho, centrum odporúča zvážiť odstavenie systému. Ide o rozhodnutie podľa rizika konkrétnej služby, nie o dôkaz, že už bola napadnutá. Podobnú radu dáva WordPress prevádzkovateľom vlastných serverov so starým PHP.

Pri službe, ktorá uchováva údaje zákazníkov alebo umožňuje platby, treba okrem aktualizácie sledovať aj známky podozrivej aktivity. Ak správca zistí indície kompromitácie, samotná výmena balíka nevyrieši prípadný zásah, ku ktorému došlo skôr. NCSC odporúča preveriť systém a hľadať možné zadné vrátka; organizácia bez potrebných kapacít má vyhľadať odbornú pomoc. Táto opatrnosť neznamená, že existuje potvrdený prienik do každého neopraveného webu.

Čo z toho vyplýva pre návštevníkov internetu

Bežný návštevník si PHP na cudzom serveri neaktualizuje. Chyba necieli priamo na jeho telefón či prehliadač, no úspešné ovládnutie webu by mohlo ohroziť údaje uložené na serveri alebo dôveryhodnosť jeho obsahu. Ak obľúbená služba nefunguje, je rozumnejšie sledovať jej oficiálne oznámenie než predpokladať, že výpadok potvrdzuje krádež dát. O konkrétnych používateľských opatreniach má rozhodovať až oznámenie prevádzkovateľa alebo dôveryhodné zistenie o incidente.

PHP2Shell tak ukazuje dve veci súčasne. AI pomohla bezpečnostným tímom preukázať riziko skryté v široko používanej infraštruktúre, no zverejnenie opravy okamžite preveruje schopnosť prevádzkovateľov dostať ju na všetky servery. Potvrdeným riešením je opravené PHP, nie samotná existencia záplaty niekde na internete. Kým sa neoverí jej nasadenie v konkrétnej službe, všeobecný údaj o počte používateľov PHP ani správa o zapnutom firewalle nedávajú jej zákazníkom istotu.