Kritické zraniteľnosti PHP (CVE-2026-109618 a CVE-2026-109619): čo sa stalo a čo robiť

Dňa 21. októbra 2026 vydal projekt PHP opravy dvoch kritických zraniteľností a CERT-EU v ten istý deň zverejnilo bezpečnostné upozornenie 2026-018. Obe sú hodnotené 9,2 a obe sú opísané ako vzdialené spustenie kódu bez prihlásenia. Ak prevádzkujete web na WordPresse, e-shop alebo inú aplikáciu v PHP, týka sa Vás to a náprava spočíva v aktualizácii, nie v nastavení. Tento článok vysvetľuje, čo je známe, ako sa útok dostane dovnútra a čo by ste mali urobiť. Stav k 22. októbru 2026, podľa verzie 1.1 upozornenia CERT-EU.

Čo sa stalo

Projekt PHP oznámil 20. októbra bezpečnostné vydanie a opravy zverejnil 21. októbra o 13:30 UTC. CERT-EU nazvalo svoje upozornenie „Critical Vulnerabilities in PHP“ a uvádza dve CVE: CVE-2026-109618 a CVE-2026-109619, každú s hodnotením 9,2. CERT-EU ďalej píše, že technické podrobnosti sa už verejne rozoberajú a že sa začali šíriť prvé ukážkové programy dokazujúce zneužiteľnosť. Upozornenie nepotvrdzuje útoky v praxi, ale uvádza, že je tým pravdepodobnejšie, že útočníci chyby už zneužívajú. Berte to ako naliehavé.

Koho sa to týka

Postihnutá je každá verzia PHP staršia ako opravená v podporovanej vetve a každá vetva, ktorej podpora skončila.

CERT-EU menuje PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Podľa tímu PHP nesie najvyššie riziko mod_php. Postihnuté môžu byť aj produkty, ktoré PHP obsahujú; CERT-EU odkazuje na zoznam holandského NCSC na konci tohto článku. Počíta sa každá inštalácia, ktorá obsluhuje webové požiadavky, či už má formulár na nahrávanie súborov, alebo nie.

Ako sa útočník dostane k prvej chybe

Nikto sa nemusí prihlásiť. Podľa CERT-EU predvedený útok ukazuje, že na jeho spustenie stačí jediná požiadavka bez prihlásenia, a to skôr, než sa spustí akýkoľvek kód aplikácie. To väčšina ľudí prehliadne: nezáleží na tom, či je Váš WordPress aktuálny, či sú Vaše zásuvné moduly opravené alebo či je Váš kontaktný formulár chránený. Požiadavka dorazí najprv k jadru PHP.

Prvá chyba, CVE-2026-109618, funguje takto:

1. Požiadavka dorazí na adresu, ktorú PHP obsluhuje. Žiadne prihlásenie, žiadny účet.
2. PHP začne čítať telo požiadavky. CERT-EU ako príklad uvádza spracovanie nahrávania súborov z formulárov.
3. PHP presadzuje svoj memory_limit pomocou longjmp(). Pri prekročení limitu vyskočí z toho, čo práve robilo, a požiadavku ukončí.
4. Ak sa to stane uprostred zostavovania vnútorných údajov požiadavky, sú tieto údaje zostavené len sčasti.
5. Následné upratovanie zaobchádza s neplatnými údajmi ako s platnými a uvoľní pamäť, ktorá nebola nikdy inicializovaná. Táto pamäť môže stále obsahovať údaje z predchádzajúcich pridelení, ktoré útočník ovládal.
6. Odtiaľ upozornenie opisuje spustenie kódu na serveri.

Ako útočník riadi posledný krok, zámerne neopisujeme. Stačí vedieť, že vstupným bodom nie je Vaša aplikácia, a preto ho nič vo vnútri Vašej aplikácie nemôže zastaviť.

Druhá chyba: stav, ktorý prežije svoju pamäť

CVE-2026-109619 je iný mechanizmus s rovnakým výsledkom. PHP drží pre každú požiadavku vnútorný stav. Po určitých zlyhaniach, napríklad po závažnej chybe, môže tento stav zostať, aj keď bola pamäť pod ním uvoľnená. Ďalšia požiadavka, ktorú spracuje ten istý pracovný proces, môže tento zastaraný stav použiť skôr, než sa bežným spôsobom vynuluje. Útočník potrebuje dve požiadavky, ktoré skončia u toho istého pracovného procesu; CERT-EU hodnotí výsledok rovnako ako pri prvej chybe: vzdialené spustenie kódu.

Čo robiť ešte dnes

1. Zistite, akú verziu PHP Váš web skutočne obsluhuje. php -v v príkazovom riadku ukazuje verziu príkazového riadka, ktorá sa môže líšiť od verzie Vášho webového servera. Skontrolujte php-fpm -v, administračný panel hostingu alebo stránku, ktorá volá phpinfo(). Pri zdieľanom hostingu sa opýtajte poskytovateľa.
2. Aktualizujte na opravenú verziu: 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35. Distribúcie často preberajú opravy spätne bez zmeny čísla verzie; hľadajte preto čísla CVE v bezpečnostnom oznámení svojho dodávateľa. V kontajneroch zostavte znova z aktualizovaného základného obrazu. Tím PHP upozorňuje, že rpms.remirepo.net v deň vydania ešte nemalo žiadne aktualizácie, a odporúča balíky distribúcie alebo zostavenie zo zdrojových kódov.
3. Reštartujte každý pracovný proces PHP. Aktualizácia na disku nezmení procesy, ktoré už bežia. Reštartujte PHP-FPM alebo webový server a potom znova skontrolujte bežiacu verziu.
4. Ak dnes nemôžete aktualizovať, odpojte server od verejných sietí, kým oprava nie je nasadená a overená. CERT-EU jasne hovorí, že tieto chyby plne odstráni len aktualizácia.
5. Ak používate PHP 8.1 alebo staršie, požiadajte dodávateľa o spätne portovanú opravu alebo prejdite na podporovanú vetvu. Tieto verzie nedostávajú pravidelné aktualizácie.

Opatrenia, ktoré riziko znižujú, ale chybu neodstraňujú

CERT-EU uvádza opatrenia, ktoré útok sťažujú. Výslovne hovorí, že inštaláciu bezpečnou neurobia. Používajte ich počas prípravy aktualizácie, nie namiesto nej.

• Proti CVE-2026-109618: Nastavte memory_limit=-1 tak, aby ho aplikácie nemohli prepísať, napríklad pomocou php_admin_value v pooli FPM, a overte, že žiadny záznam poolu, adresára ani aplikácie opäť nenastavuje konečný limit. Nastavte nízku hodnotu post_max_size (8M bez nahrávania súborov, 32M s ním) a držte upload_max_filesize pod ňou. Obmedzte veľkosť požiadavky, počet polí, časti multipart, počet hlavičiek a hĺbku vnorenia na webovom serveri alebo proxy serveri. Použite limit pamäte kontajnera alebo cgroup ako hranicu dostupnosti, ale nie RLIMIT_AS ani RLIMIT_DATA, ktoré môžu vyvolať zraniteľné zlyhanie pridelenia pamäte.
• Proti CVE-2026-109619: Nastavte session.upload_progress.enabled=0 v php.ini, v pooli FPM alebo v konfigurácii servera, ktorá sa uplatní pred spracovaním požiadavky (nie pomocou ini_set() ani .user.ini), a reštartujte všetky pracovné procesy. Pri PHP 8.5 nastavte navyše fatal_error_backtraces=0. Odstráňte neplatné alebo zastarané nastavenia pre jednotlivé požiadavky, ktoré vypisujú diagnostické hlásenia pred inicializáciou, a opravte závažné chyby a prekročenia časového limitu behu, ktoré môže útočník vyvolať.

Čo SilentShield tu dokáže a čo nie

Toto nie je problém botov a radšej to hovoríme otvorene, než by sme dovolili produktovej stránke naznačiť opak. Útok zasiahne jadro PHP skôr, než požiadavku uvidí čokoľvek od nás alebo akýkoľvek CAPTCHA, zásuvný modul či pravidlo firewallu vo vnútri Vašej aplikácie. Ochrana pred botmi pri formulári ho nezastaví a nikto by Vám nemal tvrdiť, že áno. Jediná úplná náprava je aktualizácia PHP.

API a prehľadový panel SilentShield nie sú napísané v PHP. Zásuvný modul pre WordPress a PHP SDK bežia vo Vašom vlastnom PHP, takže pri nich musí aktualizácia prebehnúť na Vašom serveri. Po aktualizácii je obvyklá ochrana pred botmi a spamom z formulárov rovnako užitočná ako predtým; len nikdy nebola odpoveďou na tento problém.

Zdroje

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Oznámenie projektu PHP z 20. októbra 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produkty, ktoré obsahujú PHP