Stručne: Po PHP2Shell sú ďalšie hlásenia k PHP pravdepodobné, pretože už dva dni po záplate prišlo tretie upozornenie, úplný advisory ešte chýba a distribúcie dodávajú svoje balíky postupne. Kto teraz zavedie pevný postup sledovania, vyhodnotenia, aktualizácie a reštartu, zareaguje na ďalšiu novú bezpečnostnú zraniteľnosť PHP v priebehu hodín namiesto dní.
Záplata nebola koncom príbehu
Dňa 21. októbra 2026 projekt PHP uzavrel obe kritické zraniteľnosti CVE-2026-109618 a CVE-2026-109619 verziami 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Mnohí zodpovední si potom odškrtli políčko. O dva dni neskôr, 23. októbra, však nasledovalo ďalšie upozornenie od php.net na CVE-2026-115560.
Toto tretie upozornenie sa týka len nezvyčajnej konfigurácie session. Ukazuje však vzorec, ktorý poznáme z veľkých bezpečnostných prípadov: keď sa nejaký komponent náhle ocitne v záujme verejnosti, mnohí odborníci sa naň súčasne pozerajú podrobnejšie. Či z toho vzniknú ďalšie zraniteľnosti, dnes nevie nikto. Pravdepodobné však je, že správy neutíchnu.
Pre vás ako prevádzkovateľa to znamená: počítajte s následnými hláseniami, namiesto aby vás každé prekvapilo. Doterajší priebeh udalostí zhŕňa naša chronológia PHP2Shell.
Prečo sú ďalšie hlásenia pravdepodobné
Nasledujúce zhodnotenie sa opiera o verejne známe fakty. Nie je predpoveďou konkrétnych zraniteľností.
- Advisory ešte chýba. php.net rieši CVE-2026-115560 v rámci riadneho cyklu vydávania a oznámil, že úplný advisory zverejní s nasledujúcim vydaním. Dovtedy platí ako náprava
session.upload_progress.enabled=0. - Podrobnosti boli skoro verejné. Podľa viacerých správ sa podrobnosti dostali na verejnosť pred skončením embarga. Podľa správ watchTowr podľa vlastných údajov zreprodukoval CVE-2026-109618. Takéto práce často vedú k následným otázkam k susedným miestam kódu.
- Distribúcie dodávajú postupne. Ubuntu zásobilo 21. októbra aktuálne vydania cez USN-8948-1 a opravy pre 14.04 až 20.04 doplnilo cez Ubuntu Pro v USN-8948-2. Red Hat vo svojom bulletine napísal, že niektoré aktualizácie sú k dispozícii, ďalšie sú v príprave.
- Vývojová verzia je dotknutá. Podľa php.net obsahuje opravy aj PHP 8.6.0 RC4. Kto testuje predbežné verzie, musí dotiahnuť aj tieto prostredia.
- Staré verzie zostávajú otvorené. Pre PHP 8.1 a staršie existujú len minimálne backporty zdrojového kódu. Každý poskytovateľ, ktorý takéto verzie dodáva, hlási svoj stav samostatne a vo vlastných termínoch.
Ako sa nová bezpečnostná zraniteľnosť PHP k vám dostane
Hlásenia prichádzajú rôznymi cestami a s rôznou spoľahlivosťou. Poradie je takmer vždy rovnaké: najprv projekt PHP, potom distribúcie a poskytovatelia hostingu, potom úrady a médiá.
| Zdroj | Čo sa tam dozviete | Aká spoľahlivá |
|---|---|---|
| php.net | Dotknuté vetvy, opravené verzie, prechodné opatrenia | Primárny zdroj |
| Ubuntu, Debian, Red Hat | Stavy balíkov pre každé vydanie, čas dodania | Primárny zdroj pre váš systém |
| Poskytovatelia hostingu a výrobcovia panelov | Stav vlastných zostavení PHP | Záväzné len písomne |
| BSI, CERT-Bund | Posúdenie situácie, stupeň varovania, odporúčania | Zaradenie úradu |
| Odborná tlač a bezpečnostné firmy | Pozorovania útokov, čísla, súvislosti | Užitočné, označiť ako správu |
Dôležitý je rozdiel medzi „existuje záplata“ a „môj systém má záplatu“. Prvé tvrdenie stojí na php.net. Druhé musíte pre každý server doložiť sami.
Odoberajte hlásenia php.net a vašej distribúcie cez RSS alebo e-mailovú konferenciu a presmerujte ich do spoločnej schránky alebo kanála, ktorý číta viac ako jedna osoba. Dovolenka a choroba sú najčastejšie dôvody oneskorených aktualizácií.
Čo by ste mali pripraviť pred ďalším hlásením
Skúsenosť z PHP2Shell ukazuje, kde sa stráca čas: pri hľadaní serverov, pri vyjasňovaní zodpovedností a pri zabudnutom reštarte. To všetko sa dá vybaviť vopred.
- Inventár: Zoznam všetkých serverov a webov s vetvou PHP, režimom prevádzky (PHP-FPM, mod_php, LiteSpeed) a zdrojom balíkov. Bez tohto zoznamu sa každé hlásenie začína hľadaním. Ako sa to podarí, popisuje príspevok Inventár všetkých webov a serverov.
- Zodpovednosť: Pre každý systém je určené, kto záplatuje, kto reštartuje a kto schvaľuje. Pri poskytovateľoch hostingu a agentúrach to patrí do zmluvy.
- Hodnotiaca schéma: Na prvé zaradenie stačia tri otázky. Je naša vetva dotknutá? Používame dotknutú funkciu alebo režim prevádzky? Existuje záplata, alebo len prechodné opatrenia?
- Testovacia cesta: Stagingové prostredie, v ktorom sa dá aktualizácia PHP preveriť v krátkom čase.
- Doklad: Pevný formát, v ktorom sa zaznamenáva stav balíka, zhoda v changelogu a čas reštartu.
Ako takýto postup funguje ako rutina namiesto hasičského zásahu, nájdete pod Správa záplat ako proces. Súvislosti k tomu, ako projekt PHP zaobchádza so zraniteľnosťami, poskytuje stránka Ako projekt PHP rieši bezpečnostné zraniteľnosti.
Vlastná konfigurácia ako systém včasného varovania
Časť následných hlásení sa týka len určitých nastavení. CVE-2026-115560 je toho príkladom: php.net uvádza ako predpoklad, že aplikácia prestaví serializer session za behu, kým je upload progress aktívny. Aplikácie, ktoré to nikdy nerobia, nie sú podľa php.net dotknuté.
Kto pozná svoju účinnú konfiguráciu, vie takéto hlásenia zaradiť rýchlejšie. Zaznamenajte preto pre každú vetvu, ktoré hodnoty sú nastavené na strane servera a ktoré aplikácie ich smú prepísať. Pomôže už jednoduché porovnanie aktívnych nastavení:
# Účinné hodnoty príkazového riadku (webová konfigurácia sa môže líšiť)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Nastavené hodnoty v poolech FPM (cesta sa podľa distribúcie líši)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Príkazový riadok nemusí ukazovať, čo platí vo webovom kontexte. Jasno urobí konfigurácia poolu alebo VirtualHost a, krátkodobo a chránene, stránka phpinfo.
Ďalšia výhoda: kto vie, ktoré prechodné hodnoty sú ešte nastavené z týždňa PHP2Shell, môže ich po nasledujúcom riadnom vydaní vedome skontrolovať. Niektoré nastavenia, napríklad vypnutý upload progress, môžu zostať trvalo zmysluplné. Iné, ako veľmi tesné limity uploadov, by ste po konzultácii s odbornými oddeleniami mali opäť prispôsobiť skutočnej potrebe.
Ako konkrétne pomáha PHP SOS?
- Sledujeme hlásenia php.net, distribúcií a BSI a nové upozornenia vyhodnocujeme pre vaše konkrétne systémy.
- S vami vytvoríme inventár všetkých inštalácií PHP a určíme zodpovednosti pre každý server.
- V rámci zmluvy o bezpečnostnej údržbe nasadzujeme aktualizácie, reštartujeme všetky procesy a dokumentujeme stav.
- Pri hláseniach bez záplaty nastavujeme prechodné opatrenia tak, aby sa nedali prepísať, a následne ich kontrolujeme.
Časté otázky
Existuje po PHP2Shell už nová bezpečnostná zraniteľnosť PHP?
Dňa 23. októbra 2026 zverejnil php.net upozornenie na CVE-2026-115560. Vykonanie kódu je podľa neho možné len pri nezvyčajnej konfigurácii session. Úplný advisory má nasledovať s nasledujúcim riadnym vydaním.
Musím po každom novom hlásení konať okamžite?
Nie každé hlásenie vyžaduje rovnakú naliehavosť. Rozhodujúce sú závažnosť, dotknutosť vašej konfigurácie a otázka, či je záplata k dispozícii. Stanovený postup pomáha vyhodnotiť to v priebehu minút namiesto dní.
Kde sa dozviem o nových zraniteľnostiach PHP ako prvý?
Primárne zdroje sú hlásenia na php.net a bezpečnostné upozornenia vašej distribúcie, napríklad Ubuntu Security Notices, Debian Security Tracker alebo Red Hat. BSI informuje cez varovné hlásenia. Mediálne správy sú užitočné, no často neskoršie a menej presné.
Prečo distribúcie hlásia niekedy o dni neskôr ako php.net?
Distribúcie musia opravu prevziať do vlastných balíkov, zostaviť a otestovať. Pri starších vydaniach to môže trvať dlhšie alebo prebehnúť len cez doplnkové ponuky. Preto sa oplatí sledovať oba zdroje oddelene.