Krótko: W kwestii bezpieczeństwa PHP w Drupalu chodzi po PHP2Shell przede wszystkim o serwer: luka tkwi w PHP, a nie w Drupalu. Proszę sprawdzić stan PHP w raporcie stanu i u operatora, zrestartować wszystkie procesy PHP, a następnie skontrolować settings.php, katalog files i uprawnienia ról.
Drupal i PHP2Shell: sytuacja
Drupal jest często wykorzystywany do większych stron, portali i w podmiotach publicznych, często z wieloma redaktorami i interfejsami. Luki PHP CVE-2026-109618 i CVE-2026-109619 umożliwiają według zespołu PHP zdalne wykonanie złośliwego kodu bez logowania. To, jak dobrze utrzymywany jest sam Drupal, nie odgrywa tu roli.
Drupal ma własny zespół bezpieczeństwa, który publikuje komunikaty o rdzeniu i modułach. PHP2Shell do nich nie należy, ponieważ nie jest luką Drupala. Kto śledzi wyłącznie komunikaty Drupala, mógł więc przeoczyć to ostrzeżenie.
W większych projektach Drupal odpowiedzialność rozkłada się często na kilka podmiotów: agencja pielęgnuje kod, centrum danych prowadzi serwery, a redakcja siedzi we własnym domu. Proszę ustalić na piśmie, kto wprowadza aktualizację PHP, kto uruchamia restart i kto sprawdza, czy wcześniej coś się wydarzyło. W konfiguracjach z kilkoma serwerami WWW za load balancerem każdy serwer z osobna musi być załatany i zrestartowany, w przeciwnym razie część żądań pozostaje na starym PHP.
Bezpieczeństwo PHP w Drupalu: sprawdzanie wersji i stanu poprawek
W Raporty > Raport stanu Drupal pokazuje wersję PHP, na której działa strona, wraz z ostrzeżeniami dotyczącymi konfiguracji. W wierszu poleceń drush status podaje wersję PHP CLI, na którym działają także zadania cron i wdrożenia. Oba muszą być załatane.
Naprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dystrybucje i firmy hostingowe czasem wprowadzają poprawki jako backport, a wtedy numer pozostaje ten sam; miarodajny jest potwierdzony stan pakietów. To, które wersje PHP obsługuje Państwa wersja Drupala, można sprawdzić w wymaganiach systemowych na drupal.org. Po aktualizacji niezbędny jest restart, opisany w artykule Restart PHP-FPM i wszystkich procesów worker.
Katalogi i pliki, które się liczą
| Miejsce | Zawartość | Punkt kontroli |
|---|---|---|
sites/default/settings.php |
Baza danych, hash salt, trusted_host_patterns |
Data zmiany, dopisane includes |
sites/default/files/ |
Publiczne przesłane pliki, wygenerowane obrazy, CSS i JS | Brak plików PHP, obecny .htaccess |
| Prywatny katalog plików | Chronione przesłane pliki, często poza katalogiem głównym dokumentów | Prawa dostępu |
modules/contrib/, modules/custom/ |
Moduły z drupal.org i własne rozwiązania | Zmienione lub nieznane moduły |
themes/ |
Motywy z szablonami Twig | Obcy JavaScript |
vendor/ |
Zależności Composera | composer audit |
Drupal tworzy w katalogu files plik .htaccess, który uniemożliwia wykonywanie PHP. Pod Apache działa, pod Nginx nie. Tam potrzebna jest własna reguła:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Bezpieczne kontrole za pomocą wbudowanych narzędzi i Drusha:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Proszę porównać stan kodu na serwerze z repozytorium Git. W projektach Drupal z Composerem jest to najszybszy sposób na znalezienie obcych lub zmienionych plików, ponieważ każde odstępstwo musi dać się wyjaśnić.
Role, uprawnienia i moduły jako ryzyko
Logowanie znajduje się pod /user/login, a obszar zarządzania pod /admin. W Drupalu o bezpieczeństwie decydują nie tylko konta administratorów, lecz także pojedyncze uprawnienia. Uprawnienia takie jak zarządzanie modułami, użytkownikami, uprawnieniami lub formatami tekstu z pełnym HTML są w praktyce uprawnieniami administratora. Proszę sprawdzić w Osoby i Uprawnienia, jakie role je mają i kto do tych ról należy.
Moduły contrib bardzo rozszerzają Drupala, ale wnoszą własny kod. Moduły bez aktywnej opieki i stare własne rozwiązania są często powodem odkładania aktualizacji PHP. Więcej o zależnościach znajdą Państwo w artykule Sprawdzanie zależności Composera pod kątem luk.
Co daje aktualizacja Drupala, a czego nie
Aktualizacja rdzenia lub modułu zamyka błędy w tym kodzie i może umożliwić nowsze wersje PHP. Nie łata PHP, nie usuwa obcych plików z sites/default/files, nie resetuje uprawnień i nie kasuje potajemnie utworzonych kont. Również pamięć podręczna może nadal dostarczać zmanipulowane treści, dopóki nie zostanie opróżniona. W razie podejrzenia należy odnowić hash salt i dane dostępowe do bazy danych.
W instalacjach multisite kilka stron dzieli ten sam kod, ale pod sites/ każda ma własny settings.php i własny katalog files. Wtedy proszę sprawdzić każdą stronę z osobna. Znalezisko na jednej stronie dotyczy z powodu wspólnego kodu zwykle również wszystkich pozostałych.
Jak konkretnie pomaga PHP SOS?
- Sprawdzamy PHP sieciowe i CLI na Państwa serwerze Drupal oraz prosimy o potwierdzenie poprawki i restartu.
- Zabezpieczamy logi i dane oraz porównujemy stan kodu z Państwa repozytorium lub oryginalnymi pakietami.
- Kontrolujemy
settings.php, katalogfiles, reguły serwera, role i uprawnienia. - Na życzenie przejmujemy bieżącą opiekę w ramach umowy serwisowej bezpieczeństwa, aby aktualizacje PHP i Drupala nie rozjeżdżały się ponownie.
Częste pytania
Czy aktualizacja bezpieczeństwa Drupala pomaga na PHP2Shell?
Nie. Aktualizacje Drupala zamykają błędy w rdzeniu Drupala i modułach. PHP2Shell leży w PHP serwera i wymaga aktualizacji PHP lub potwierdzonego backportu oraz restartu wszystkich procesów PHP.
Gdzie Drupal pokazuje wersję PHP?
W raporcie stanu w sekcji Raporty. Za pomocą Drusha polecenie drush status pokazuje wersję PHP wiersza poleceń. Oba wskazania mogą się różnić, a backportu nie da się pewnie rozpoznać po żadnym z nich.
Czy .htaccess w folderze files chroni także pod Nginx?
Nie. Utworzony przez Drupala plik .htaccess jest interpretowany tylko przez Apache. Pod Nginx potrzebna jest własna reguła w konfiguracji serwera, która blokuje pliki PHP w katalogu files.
Co oznacza trusted_host_patterns?
Ustawienie w settings.php określa, pod jakimi nazwami hostów Drupal odpowiada. Chroni przed atakami przez zmanipulowane dane hosta i powinno znaleźć się w każdej instalacji produkcyjnej.