Na Facebooku Národného bezpečnostného úradu dnes predpoludním pribudlo varovanie o dvoch kritických zraniteľnostiach PHP. Pod menom úradu je štítok Obsah AI.

Pri bezpečnostnom varovaní od štátnej autority je to vec, po ktorej sa človek chce pozrieť k zdroju. Tak sme sa pozreli a čísla aj termín sedia.

Aktualizované 22. 10. Opravy sú vonku: PHP 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35, podľa vetvy. Pre nepodporované 7.4, 8.0 a 8.1 vyšli zdrojové záplaty. Medzitým sa ukázalo, že pokusy o zneužitie prebiehali už od 17. októbra, teda štyri dni pred zverejnením, a NSA odporúča systémy, ktoré sa nedajú hneď aktualizovať, odpojiť od siete. Spresnili sme aj časť o dočasných opatreniach.

Čo sa presne deje

Bezpečnostný tím PHP zverejnil predbežné oznámenie o mimoriadnom vydaní. V plnom znení hovorí toto:

Je naplánované na stredu 21. októbra 2026 o 14:00 UTC. Rieši dve kritické zraniteľnosti, obe s hodnotením CVSS v4.0 9,2. Vyhradzujeme si právo vydať opravu skôr, ak sa podrobnosti ktorejkoľvek zo zraniteľností stanú verejnými, alebo ak sa objavia dôkazy o aktívnom zneužívaní.

Štrnásta hodina UTC je u nás 16:00. Zraniteľnosti dostali označenia CVE-2026-109618 a CVE-2026-109619 a v komunite sa pre ne ujal názov php2shell.

SK-CERT k nim v ten istý deň vydal varovanie, v ktorom dopad opisuje strohou vetou: úspešné zneužitie umožní vzdialenému neautentifikovanému útočníkovi spustiť na postihnutom systéme ľubovoľný kód. Neautentifikovaný znamená, že sa nikam neprihlasuje. Stačí, že na váš web dočiahne.

Po vydaní opráv je už zverejnené aj to, čo tie chyby vlastne sú. Obe sú chyby v práci s pamäťou:

  • CVE-2026-109618 je spustenie kódu cez poškodenie pri nedostatku pamäte. Keď PHP narazí na strop pamäte, ošetrenie tej situácie ho preruší v momente, keď má vnútorné údaje o požiadavke rozrobené, a následné upratovanie prebehne nesprávne.
  • CVE-2026-109619 je spustenie kódu cez zabudnutý vnútorný stav. Údaje patriace jednej požiadavke prežijú aj po tom, čo sa uvoľní pamäť pod nimi, a ďalšia požiadavka spracovaná tým istým procesom ich môže použiť skôr, než sa stihnú vynulovať.

Druhá z nich je nepríjemná práve preto, že spája dve nesúvisiace požiadavky cez jeden pracovný proces.

Zraniteľné je podľa PHP všetko, čo obsluhuje webové požiadavky, teda PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP aj LiteSpeed, a všetky vydania staršie než tie dnešné opravené.

PHP zároveň píše, že najvyššie riziko vidí pri mod_php, kde je predvedený útok, pri ktorom neprihlásená požiadavka zaberie skôr, než sa vôbec spustí kód aplikácie. To je nepríjemné zistenie pre lacnejšie zdieľané hostingy, kde mod_php stále býva.

Najnebezpečnejšia je chvíľa po oprave

Podrobnosti o zraniteľnostiach unikli už 20. októbra, teda deň pred plánovaným zverejnením. Spolu s nimi koloval aj screenshot nástroja s názvom php2shell. Práve preto PHP celý proces zrýchlilo.

Ešte ráno nikto zneužitie v praxi nepotvrdil. Firma watchTowr uviedla pre BleepingComputer, že útoky nevidí, a Huntress dodal, že ich nevidí vo svojich prostrediach a chybu sa mu ani nepodarilo zreprodukovať.

Potom sa to zmenilo a jeden údaj posúva celý príbeh dozadu. Amazon ohlásil pokusy o zneužitie už 17. októbra, teda štyri dni pred zverejnením. Útočilo sa v čase, keď o chybe vedel len úzky okruh ľudí a nikto iný nemal šancu sa brániť.

K tomu pribudlo plošné oťukávanie webov a viaceré hlásenia o skutočných prienikoch. Patchstack mal vo vlastnej telemetrii 21. októbra o 13:57 UTC zatiaľ len oťukávanie, ale zároveň uviedol, že mu hostingoví partneri hlásili prípady zneužitia. Isté je to, čo píše samo PHP: funkčný útok existuje a pri mod_php mu stačí jediná neprihlásená požiadavka, ktorá zaberie skôr, než sa spustí kód vašej aplikácie.

Americká NSA v ten istý deň vydala odporúčanie, ktoré je na takúto inštitúciu nezvyčajne priame: aktualizovať, a ak to hneď nejde, odpojiť systém od siete, kým sa to nevyrieši. Rovnako sa ozvali ďalšie národné úrady vrátane českého NÚKIB.

Dôvod, prečo sa to zlomilo práve teraz, je samotná oprava. Je to verejný rozdiel v zdrojovom kóde, z ktorého sa dá spätne odvodiť, kde presne chyba bola. Pri zraniteľnosti tohto typu je to návod. Sansec to pred vydaním zhrnul jednou vetou:

Očakávame, že hromadné útoky začnú do pätnástich minút od vydania.

Preto sa neoplatí odkladať aktualizáciu na ráno. Opravy sú vonku a útočníci majú rovnaký náskok ako vy.

Komu oprava nepríde vôbec

Pre slovenské firmy je toto asi najnepríjemnejšia časť celej veci.

PHP podporuje štyri vetvy a riadne vydanie s opravou dostali len tie. Dnešné opravené čísla sú 8.5.12, 8.4.27, 8.3.36 a 8.2.35:

Ktoré verzie PHP dostanú opravu a ktoré nie

Ak beží váš web na PHP 8.1, 8.0, 7.4 alebo starších, riadne vydanie pre vás nepríde. Pritom práve 7.4 a 8.0 sú na lacnejších hostingoch a v starších inštaláciách WordPressu stále bežné.

Úplne bez pomoci ale nie ste. PHP k týmto dvom chybám zverejnilo pre vetvy 7.4, 8.0 a 8.1 aspoň zdrojové záplaty. Nie je to hotový balík na inštaláciu, je to úprava zdrojového kódu pre tých, čo si PHP prekladajú sami alebo nemajú dodávateľa, ktorý by to spravil za nich.

Máte teda tri cesty a prvé dve stoja za telefonát ešte dnes.

Prejsť na PHP 8.2 alebo vyššiu. Pri bežnom WordPresse alebo e-shope to býva prepnutie v administrácii hostingu a otázka minút, pri starej aplikácii na mieru to môže byť projekt na týždne.

Opýtať sa hostingu alebo distribúcie, či pre vašu verziu vydajú vlastnú záplatu. Veľkí poskytovatelia to robia a distribúcie ako Debian či RHEL udržiavajú vlastné balíky aj po skončení podpory v samotnom PHP. Pýtajte sa konkrétne na tieto dve CVE.

A ak ani jedno, ostáva odrezať aplikáciu od internetu, kým sa to vyrieši. Nepríjemné, ale menej nepríjemné než cudzí kód na serveri.

Dočasné opatrenia: čo naozaj platí

Ráno, keď boli známe len termín a skóre, kolovalo okolo dočasných opatrení dosť zmätku a my sme k nim boli zdržanliví. Po zverejnení podrobností je to jasnejšie a časť toho zmätku sa vysvetlila: nejde o protirečiace si rady, ale o dve rôzne opatrenia na dve rôzne chyby.

  • Proti CVE-2026-109618 (chyba pri nedostatku pamäte) odporúča PHP nastaviť memory_limit=-1.
  • Proti CVE-2026-109619 (zabudnutý stav) nastaviť session.upload_progress.enabled=0, na PHP 8.5 k tomu ešte fatal_error_backtraces=0, a reštartovať všetky pracovné procesy.

Obe teda treba naraz, inak si zavriete len jedny dvere. A aj potom platí to, čo PHP napísalo úplne jednoznačne: úplné opatrenie neexistuje, opraviť to vie jedine aktualizácia.

K tomu memory_limit=-1 jedna poznámka z praxe, lebo znie strašidelne a je to tak správne. Neobmedzená pamäť na produkčnom serveri je cesta k tomu, že vám jeden proces zje stroj. Ak po tom siahnete, dávajte to spolu s obmedzením veľkosti požiadaviek na webovom serveri a pamäťovým stropom kontajnera, nie samotné.

Zablokovať multipart POST požiadavky skôr, než sa dostanú k PHP, má zmysel ako ďalšia brzda tam, kde na danom webe nahrávanie súborov nepotrebujete. Ale je to brzda, nie oprava.

Čo urobiť teraz

  1. Zistite, kde všade vám beží PHP. Nielen weby. Patria sem administračné rozhrania sieťových zariadení, NAS úložiská, kamerové systémy, interné nástroje a kontajnery, ktoré ste raz nasadili a odvtedy sa ich nedotkli.
  2. Overte verziu. Na serveri php -v a zvlášť php-fpm -v, lebo príkazový riadok a web môžu bežať na inej. Na hostingu v administrácii, pri WordPrese v sekcii Nástroje a Zdravie stránky.
  3. Oddeľte to, čo je dostupné z internetu, od toho, čo beží len vnútri. Prvá skupina má prednosť.
  4. Aktualizujte na 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35, podľa vetvy, ktorú máte. Nezabudnite na reštart php-fpm, bez neho beží starý kód ďalej.
  5. Overte verziu po aktualizácii, nie len to, že príkaz prebehol bez chyby.
  6. Pozrite si logy spätne, aspoň od 17. októbra. Nie od zverejnenia, ale od dňa, keď boli zaznamenané prvé pokusy. Hľadajte neobvyklé POST požiadavky a nové súbory v adresároch, kam sa nahrávajú prílohy.
  7. Ak nájdete čokoľvek podozrivé, neriešte to len aktualizáciou. Aktualizácia zavrie dvere, ale neodstráni to, čo sa cez ne už mohlo dostať.

Na overenie verzie po aktualizácii sa hodia tieto príkazy:

php -v
php-fpm -v
systemctl restart php8.3-fpm   # číslo podľa vašej verzie

Pätnásť minút pri zdroji

Ten štítok o obsahu z umelej inteligencie je presne ten moment, keď sa oplatí otvoriť si php.net a stránku SK-CERT a pozrieť sa, či čísla sedia. Trvalo to pätnásť minút. Sedia.

Pri tom sa ale ukázalo aj to, čo sa do krátkeho príspevku nezmestilo: že nebezpečná je až chvíľa po oprave a že staršie verzie PHP ju nedostanú. Nie je to výčitka voči úradu, krátky príspevok na Facebooku nemá priestor na všetko. Je to dôvod, prečo si varovanie preveriť skôr, než podľa neho začnete konať.

Doplnené po vydaní opráv. Opravené verzie sú 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Pre nepodporované 7.4, 8.0 a 8.1 vyšli zdrojové záplaty. A to, čo sme vyššie písali opatrne o dočasných opatreniach, PHP medzitým potvrdilo: úplné neexistuje, pomôže len aktualizácia.

Neviete, kde všade vám PHP beží?

Prejdeme vaše servery, weby aj zariadenia s webovým rozhraním, zistíme verzie a aktualizáciu nasadíme za vás. Pre domácnosti aj firmy na Liptove, inde na diaľku.

Ozvite sa nám

Overenie a zdroje. Termín, počet zraniteľností aj skóre CVSS v4.0 9,2 sme overili priamo v oznámení bezpečnostného tímu na php.net, kde sú uvedené aj aktuálne podporované vetvy. Označenia CVE a opis dopadu potvrdzuje varovanie SK-CERT z 21. 10. 2026. Rozsah zraniteľných verzií a očakávanie hromadných útokov po vydaní uvádza Sansec. Informáciu, že ráno zneužitie v praxi nikto nepotvrdil, priniesol SecurityWeek na základe vyjadrení firiem watchTowr a Huntress. Že pokusy o zneužitie prebiehali už od 17. októbra, ohlásil Amazon a zhrnul Datadog Security Labs, odkiaľ pochádza aj rozpis dočasných opatrení podľa jednotlivých chýb. Varovania národných úradov vydali NÚKIB aj americká NSA. Podrobnosti oboch chýb sú v bezpečnostných upozorneniach na GitHube: GHSA-w8hw-w9fx-j79w a GHSA-6wmf-4rv5-p3rp. Článok sme po vydaní opráv o 16:35 aktualizovali: doplnili sme čísla opravených verzií, povahu oboch chýb, zdrojové záplaty pre 7.4, 8.0 a 8.1 a aktuálny stav zneužívania podľa telemetrie Patchstack a súhrnu Help Net Security.

Tento článok je súčasťou prehľadu Kybernetická bezpečnosť.