Stručně: U bezpečnosti PHP v Drupalu jde po PHP2Shell především o server: zranitelnost je v PHP, ne v Drupalu. Zkontrolujte stav PHP ve zprávě o stavu a u provozovatele, restartujte všechny procesy PHP a poté prověřte settings.php, adresář files a oprávnění rolí.
Drupal a PHP2Shell: situace
Drupal se často nasazuje pro větší weby, portály a veřejné instituce, často s mnoha redaktory a rozhraními. Zranitelnosti PHP CVE-2026-109618 a CVE-2026-109619 umožňují podle týmu PHP spuštění škodlivého kódu na dálku bez přihlášení. Jak dobře je samotný Drupal udržován, přitom nehraje roli.
Drupal má vlastní bezpečnostní tým, který zveřejňuje upozornění k jádru a modulům. PHP2Shell mezi ně nepatří, protože to není zranitelnost Drupalu. Kdo sleduje jen upozornění Drupalu, mohl proto zprávu přehlédnout.
U větších projektů na Drupalu je odpovědnost často rozdělena mezi několik míst: agentura udržuje kód, datové centrum provozuje servery, redakce sedí ve vlastním domě. Písemně ujasněte, kdo nasadí aktualizaci PHP, kdo spustí restart a kdo zkontroluje, zda se předtím něco nestalo. U nastavení s více webovými servery za load balancerem musí být každý jednotlivý server záplatován a restartován, jinak část požadavků zůstane na starém PHP.
Bezpečnost PHP v Drupalu: kontrola verze a stavu záplat
V nabídce Zprávy > Zpráva o stavu Drupal zobrazuje verzi PHP, se kterou web běží, spolu s varováními ke konfiguraci. Na příkazové řádce poskytuje drush status verzi CLI PHP, se kterým běží i úlohy cron a nasazení. Obě musí být záplatovány.
Opravené verze upstreamu jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Distribuce a poskytovatelé hostingu opravy částečně nasazují jako backport, číslo pak zůstane stejné; rozhodující je potvrzený stav balíčku. Které verze PHP vaše verze Drupalu podporuje, ověříte podle systémových požadavků na drupal.org. Po aktualizaci patří k věci restart, popsaný v článku Restart PHP-FPM a všech workerů.
Adresáře a soubory, na kterých záleží
| Místo | Obsah | Bod kontroly |
|---|---|---|
sites/default/settings.php |
Databáze, hash salt, trusted_host_patterns |
Datum změny, vložené includes |
sites/default/files/ |
Veřejné nahrávky, vygenerované obrázky, CSS a JS | Žádné soubory PHP, .htaccess přítomen |
| Soukromý adresář souborů | Chráněné nahrávky, často mimo kořen dokumentů | Přístupová práva |
modules/contrib/, modules/custom/ |
Moduly z drupal.org a vlastní vývoj | Změněné nebo neznámé moduly |
themes/ |
Motivy se šablonami Twig | Cizí JavaScript |
vendor/ |
Závislosti Composeru | composer audit |
Drupal vytváří v adresáři files soubor .htaccess, který spouštění PHP zakazuje. Pod Apache funguje, pod Nginx nikoli. Tam je potřeba vlastní pravidlo:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Neškodné kontroly vestavěnými prostředky a Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Porovnejte stav kódu na serveru se svým repozitářem Git. U projektů na Drupalu s Composerem je to nejrychlejší cesta, jak najít cizí nebo změněné soubory, protože každá odchylka musí být vysvětlitelná.
Role, oprávnění a moduly jako riziko
Přihlášení leží na adrese /user/login, oblast správy na adrese /admin. V Drupalu o bezpečnosti nerozhodují jen účty administrátorů, ale jednotlivá oprávnění. Práva jako správa modulů, uživatelů, oprávnění nebo textových formátů s plným HTML jsou prakticky práva administrátora. V části Lidé a Oprávnění zkontrolujte, jaké role ho mají a kdo do těchto rolí patří.
Moduly contrib Drupal výrazně rozšiřují, ale přinášejí vlastní kód. Moduly bez aktivní péče a staré vlastní vývojové práce bývají důvodem, proč se upgrade PHP odkládá. Více o závislostech najdete v článku Kontrola zranitelností v závislostech Composeru.
Co aktualizace Drupalu zvládne a co ne
Aktualizace jádra nebo modulu uzavře chyby v tomto kódu a může umožnit novější verze PHP. Nezáplatuje PHP, neodstraní cizí soubory z sites/default/files, neresetuje oprávnění a nesmaže skrytě vytvořené účty. Také cache může dál doručovat zmanipulovaný obsah, dokud se nevyprázdní. Po podezření je třeba obnovit hash salt a přístup k databázi.
U instalací multisite sdílí více webů stejný kód, ale pod sites/ má každý vlastní settings.php a vlastní adresář files. Pak zkontrolujte každý web zvlášť. Nález v jednom webu se kvůli společnému kódu většinou týká i všech ostatních.
Jak konkrétně pomáhá PHP SOS?
- Zkontrolujeme webové a CLI PHP vašeho serveru s Drupalem a necháme si potvrdit záplatu a restart.
- Zálohujeme logy a data a porovnáme stav kódu s vaším repozitářem nebo originálními balíčky.
- Kontrolujeme
settings.php, adresářfiles, pravidla serveru, role a oprávnění. - Na přání převezmeme průběžnou péči v rámci bezpečnostní servisní smlouvy, aby se aktualizace PHP a Drupalu zase nerozešly.
Časté dotazy
Pomůže bezpečnostní aktualizace Drupalu proti PHP2Shell?
Ne. Aktualizace Drupalu uzavírají chyby v jádru Drupalu a modulech. PHP2Shell je v PHP serveru a vyžaduje aktualizaci PHP nebo potvrzený backport a restart všech procesů PHP.
Kde Drupal zobrazuje verzi PHP?
Ve zprávě o stavu v nabídce Zprávy. S Drush zobrazí drush status verzi PHP příkazové řádky. Oba údaje se mohou lišit a backport nelze spolehlivě poznat u žádného z nich.
Chrání .htaccess ve složce files i pod Nginx?
Ne. Soubor .htaccess vytvořený Drupalem vyhodnocuje jen Apache. Pod Nginx potřebujete vlastní pravidlo v konfiguraci serveru, které soubory PHP v adresáři files zablokuje.
Co znamená trusted_host_patterns?
Nastavení v settings.php určuje, pod jakými názvy hostitele Drupal odpovídá. Chrání před útoky přes zmanipulované údaje o hostiteli a patří do každé produkční instalace.