PHP2Shell: kritická diera v PHP, ktorá obchádza aj vašu Joomlu - ako ju uzavrieť ešte dnes

Predstavte si, že ráno otvoríte administráciu hostingu, prepnete verziu PHP na novšiu, reštartujete PHP-FPM - a web ide ďalej.

A predsa ste práve o pol hodiny skôr mohli mať na serveri cudzí kód, ktorý sa do Joomly vôbec nemusel prihlasovať. Pri zraniteľnosti PHP2Shell je to presne ten scenár: problém nie je v Joomle, v šablóne ani v doplnku. Je v prostredí PHP, na ktorom váš web beží - a to prostredie spracuje požiadavku skôr, než sa vôbec spustí kód Joomly.

Čo sa vlastne stalo a prečo sa to netýka len „veľkých webov"

Bezpečnostný tím PHP vydal mimoriadne opravy. Dve chyby, spoločne prezývané PHP2Shell, umožňujú vzdialené spustenie kódu bez prihlásenia. Podľa Citadelo ide o chyby v práci s pamäťou: prvá vzniká pri zlyhaní alokácie pamäte, druhá pri opätovnom použití vnútorného stavu z predchádzajúcej požiadavky tým istým procesom.

PHP beží na veľkej časti webových stránok a pri zverejnení chýb boli voči nim vystavené milióny verejne dostupných inštancií. To nie je číslo o „niekom inom" - je to základ, na ktorom stojí aj väčšina joomlovských inštalácií.

Prečo vás neochráni ani aktuálna Joomla

Toto je najdôležitejšia veta celého textu: aktualizovaná Joomla nič nerieši, ak pod ňou beží zraniteľná verzia PHP. Rovnako to platí pre WordPress, Drupal či Magento - Toret.sk to vo svojom prehľade formuluje priamo: ohrozený je každý web na neopravenej verzii PHP bez ohľadu na to, ako dôsledne aktualizujete CMS.

Pri konfigurácii Apache s mod_php, ktorá na lacnejších zdieľaných hostingoch stále prežíva, je podľa PHP riziko najvyššie - útok je predvedený tak, že neprihlásená požiadavka zaberie skôr, než sa vôbec spustí kód aplikácie. Autentifikácia v Joomle, jej tokeny ani práva používateľov sa v takej situácii nedostanú k slovu.

Opravené verzie a čo s tými staršími

Bezpečné sú najnovšie vydania podporovaných vetiev PHP - konkrétne čísla verzií si overte v oznámení bezpečnostného tímu PHP. Ak váš web beží na vetve, ktorá už nemá riadnu podporu, riadne vydanie s opravou nepríde - pre tieto vetvy vyšli len zdrojové záplaty, teda úprava kódu pre tých, ktorí si PHP prekladajú sami. Z praktického hľadiska to znamená tri cesty:

• Prejsť na PHP 8.2 alebo vyššiu. Pri bežnej Joomle a modernom hostingu je to prepínač v administrácii a otázka minút. Pri starých doplnkoch na mieru to môže byť projekt na dni - a práve tu sa láme, či vás to pustí.
• Opýtať sa hostingu na vlastnú záplatu. Veľkí poskytovatelia a linuxové distribúcie udržujú balíky aj po skončení podpory v samotnom PHP. Pýtajte sa konkrétne na obe CVE, nie všeobecne na „najnovšie PHP".
• Odpojiť od internetu, kým sa to vyrieši. Nepríjemné, ale menej nepríjemné než cudzí kód na serveri.

Čo urobiť teraz - v tomto poradí

1. Zistite, kde všade PHP beží. Nielen weby. Administračné rozhrania NAS úložísk, kamerové systémy, interné nástroje, kontajnery, ktoré ste raz nasadili a odvtedy sa ich nedotkli.
2. Overte verziu dvakrát. Na serveri php -v a zvlášť php-fpm -v - príkazový riadok a web môžu bežať na inej verzii. V Joomle si pozrite Systém → Systémové informácie.
3. Aktualizujte a reštartujte. Bez reštartu PHP-FPM beží starý kód ďalej. Overte verziu po aktualizácii, nie len to, že príkaz prebehol bez chyby.
4. Prejdite logy spätne aspoň od doby pred zverejnením chýb. Prvé pokusy o zneužitie sa podľa dostupných správ objavili ešte pred zverejnením opráv. Hľadajte neobvyklé POST požiadavky a nové súbory v adresároch, kam sa nahrávajú prílohy.
5. Ak nájdete čokoľvek podozrivé, nestačí aktualizovať. Aktualizácia zavrie dvere, ale neodstráni to, čo sa cez ne už mohlo dostať. V takom prípade choďte na záložnú kópiu z doby pred incidentom a preverte, či v nej nie je ten istý problém.

Dočasné opatrenia: dve rôzne dvere, dve rôzne kľučky

Kým oprava nie je nasadená, odporúča sa vypnúť session.upload_progress.enabled a reštartovať pracovné procesy. Ide o dve rôzne opatrenia na dve rôzne chyby - proti jednej sa uvádzajú nastavenia session, proti druhej úprava pamäťových limitov. Obe treba naraz, inak si zavriete len jedny dvere. Aktuálne znenie odporúčaní si overte v oznámení bezpečnostného tímu PHP.

Pozor na memory_limit=-1: neobmedzená pamäť na produkčnom serveri je cesta k tomu, že jeden proces zje celý stroj. Ak po tom siahnete, kombinujte to s obmedzením veľkosti požiadaviek na webovom serveri a pamäťovým stropom kontajnera - nie samotné. A PHP samo píše jednoznačne: úplné opatrenie neexistuje, opraviť to vie jedine aktualizácia.

Čo si zazálohovať pred zásahom

Pred prepnutím verzie PHP na produkcii: celý súborový systém webu, databázu a export konfigurácie hostingu (vrátane verzie PHP a nastavení php.ini). Pri Joomle navyše overte, že záloha je obnoviteľná - nie že súbor existuje. Cesta späť je prepnutie na pôvodnú verziu PHP a obnova zo zálohy; ak ste medzitým menili nastavenia session, vráťte ich spolu s tým.

Pri starších šablónach a doplnkoch je reálne riziko, že po prechode na PHP 8.3 či 8.4 začnú hlásiť chyby alebo rovno spadnú. Preto: najprv staging (testovacia kópia), potom produkcia. Ak staging nemáte, urobte aspoň zálohu a prechod naplánujte na okno, keď web nemá návštevnosť - nie v piatok o piatej.

Servisný tip: Pri každom prechode na vyššiu vetvu PHP si najprv prejdite zoznam doplnkov a šablón a pozrite sa, kedy naposledy vyšla ich nová verzia. Doplnok, ktorý nemá vydanie viac ako dva roky a v changelogu nemá ani zmienku o PHP 8.3, je presne ten, ktorý vás pri prechode zdrží. Riešte ho skôr, než budete musieť - nie počas bezpečnostnej krízy, keď sa každá hodina počíta.

Zdroje

• Vo svete IT (Zoznam) - Dve kritické chyby v PHP otvorili hackerom cestu k miliónom webov, vosveteit.zoznam.sk (citované 2. 11. 2026)
• Citadelo - PHP2Shell: Kritické zraniteľnosti PHP, citadelo.com (citované 2. 11. 2026)
• Toret.sk - Kritická chyba v PHP ohrozuje weby a e-shopy. Aktualizujte čo najskôr, toret.sk (citované 2. 11. 2026)
• Tiptech.sk - Kritické zraniteľnosti PHP (php2shell): čo robiť, tiptech.sk (citované 2. 11. 2026)