Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) 21. října 2026 upozornil na dvě kritické chyby v PHP, programovacím jazyce, na kterém běží většina webů na světě. Odborníci jim říkají php2shell (CVE-2026-109618 a CVE-2026-109619). Útočník přes ně může na serveru spustit vlastní program, a to bez jakéhokoli hesla. Podrobnosti unikly ještě před vydáním oprav a návod na zneužití je veřejně dostupný.

Řešení existuje a je jediné: aktualizovat PHP. Níže popisujeme, jak zjistit, jestli se vás to týká, a co udělat podle toho, kde váš web běží.

Týká se to mě?

Pravděpodobně ano, pokud váš web nebo aplikace běží na:

  • WordPressu, Joomle, Drupalu nebo jiném redakčním systému, do kterého se přihlašujete přes /wp-admin nebo /administrator,
  • e-shopu na vlastním hostingu (PrestaShop, WooCommerce, Magento),
  • objednávkovém nebo rezervačním systému, intranetu, docházce či jiné webové aplikaci na zakázku, pokud je napsaná v PHP.

Netýká se vás to, pokud máte web nebo e-shop v hotové službě, kde se o server nestaráte (Shoptet, Webnode, Wix a podobné). Tam aktualizaci řeší provozovatel služby.

Důležité je, že nezáleží na tom, jak silné heslo máte do administrace. Chyba je v samotném PHP a útočník ji zneužije dřív, než se web vůbec dostane ke kontrole přihlášení.

Co udělat podle toho, kde web běží

Web na sdíleném hostingu (Wedos, Websupport, Active24 a další)

Většina velkých hostingů aktualizuje PHP sama a rychle. Přesto to ověřte:

  1. Přihlaste se do administrace hostingu a najděte nastavení PHP u svého webu.
  2. Opravené verze jsou 8.2.35, 8.3.36, 8.4.27 a 8.5.12 a novější. Pokud máte zvolenou starší řadu (7.4, 8.0, 8.1), přepněte na novější. Před přepnutím si web zazálohujte a hned po něm ho proklikejte.
  3. Pokud si nejste jistí, napište hostingu dotaz. Odpověď „opraveno“ by měli mít připravenou.

Vlastní server nebo virtuální server

Tady je aktualizace na vás nebo na vašem správci:

  • Aktualizujte jen balíčky PHP, ne celý systém naráz. Kdyby se něco pokazilo, víte hned, co to způsobilo.
  • Před aktualizací udělejte zálohu nebo snapshot serveru. Pokud web po aktualizaci nepoběží, vrátíte ho za minutu.
  • Po aktualizaci restartujte webový server (Apache, PHP-FPM). Dokud běží staré procesy, oprava neplatí.
  • Využijte příležitost a nainstalujte i ostatní bezpečnostní záplaty systému. Často zjistíte, že se na server měsíce nesahalo.
Technik v noci aktualizuje server a ráno s majitelkou firmy kontroluje web na tabletu
Záloha, aktualizace PHP, restart a kontrola webu. U každého serveru zvlášť.

Starý web, který na novém PHP nepoběží

Tohle je nejtěžší případ. Aplikace napsaná před lety pro PHP 7 nebo starší často na nové verzi nejede a oprava pro staré řady PHP od tvůrců nevyšla. Pak máte tři možnosti:

  1. Převést aplikaci na novou verzi PHP. Je to trvalé řešení, ale trvá dny až týdny podle velikosti aplikace.
  2. Do té doby omezit přístup. Pokud aplikaci používá jen pár poboček nebo zaměstnanců, nastavte na serveru, aby se k ní dostaly jen jejich IP adresy. Ostatní dostanou „přístup odepřen“ dřív, než se požadavek dostane k PHP. Funguje to i jako heslo na úrovni serveru, které se zadává před samotnou stránkou.
  3. Z jednoduchého webu udělat statický. Prezentační web, kde se jen občas mění text nebo jídelní lístek, nepotřebuje PHP vůbec. Statická kopie běží bez redakčního systému a tahle chyba se jí netýká.

Pozor: PHP 8.2 přestane dostávat opravy 31. prosince 2026. Pokud teď aktualizujete v rámci řady 8.2, naplánujte si na příští rok přechod na 8.3 nebo novější.

Jak poznat, že už se někdo dostal dovnitř

Chyba byla zneužívána ještě před vydáním opravy. Aktualizace zavře dveře, ale nevyhodí toho, kdo už je uvnitř. Po aktualizaci se proto podívejte na:

  • neznámé procesy spuštěné pod uživatelem webového serveru, typicky programy, které vytěžují procesor (těžba kryptoměn),
  • nové nebo změněné soubory .php ve složkách webu, hlavně v adresářích pro nahrávané obrázky,
  • neobvykle vysoké vytížení serveru nebo odchozí provoz bez zjevného důvodu,
  • nové uživatele v administraci webu.

Pokud něco z toho najdete, nestačí soubor smazat. Server je potřeba prověřit celý, změnit všechna hesla (k databázi, FTP, administraci) a v horším případě obnovit ze zálohy, která je starší než útok.

Jak jsme to řešili u nás

NÚKIB poslal varování večer 21. října a ještě ten večer jsme prošli všechny weby a servery, které spravujeme:

  • Většina našich webů PHP vůbec nepoužívá, takže se jich chyba netýkala.
  • Webové servery s PHP jsme aktualizovali ještě tu noc, jeden po druhém a vždy se zálohou předem. Rovnou jsme na nich nainstalovali i ostatní čekající bezpečnostní záplaty. Interní systémy, jako je pošta, následují v samostatných oknech údržby.
  • Jednu starší aplikaci, která na novém PHP nepoběží, jsme do jejího převodu omezili jen na IP adresy poboček, které ji používají.
  • Jednoduchý prezentační web na redakčním systému převádíme na statický, aby PHP a jeho aktualizace přestaly být potřeba.

Ostré weby byly při aktualizaci mimo provoz jen pár sekund, po dobu restartu webového serveru. Jedna věc nás ale překvapila: na testovacím serveru se po bezpečnostních záplatách nespustila databáze kvůli změně v nové verzi. Proto aktualizujeme vždy nejdřív test, a teprve potom ostrý provoz.

Shrnutí

  • Máte web na WordPressu, Joomle nebo vlastní aplikaci v PHP? Ověřte verzi PHP ještě dnes a aktualizujte na 8.2.35, 8.3.36, 8.4.27, 8.5.12 nebo novější.
  • Na sdíleném hostingu stačí zkontrolovat nastavení. Na vlastním serveru zálohujte, aktualizujte, restartujte a zkontrolujte web.
  • Starou aplikaci, kterou aktualizovat nejde, do jejího převodu schovejte za omezení IP adres.
  • Pokud jste regulovaná organizace podle zákona o kybernetické bezpečnosti, patří takový zásah i do vaší evidence. Více v článku Týká se vás NIS2?

Nevíte, na čem váš web běží, nebo nemáte, kdo by aktualizaci udělal? Zjistíme to za vás a během jednoho dne vám řekneme, jestli se vás chyba týká a co s ní. Objednejte si kontrolu zdarma.