# Bezpieczeństwo PHP w Drupal po PHP2Shell: jak zabezpieczyć stronę > Zabezpiecz Drupal po PHP2Shell: sprawdź PHP w raporcie stanu, chroń settings.php i folder files, skontroluj role oraz moduły. Oto jak to zrobić. Źródło: https://phpsos.de/pl/plattformen/drupal/ Stan: 25.10.2026 Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6 **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](https://phpsos.de/pl/php2shell/php-fpm-neustart/). ## 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: ```nginx location ~* ^/sites/.+/files/.+\.php$ { deny all; } ``` Bezpieczne kontrole za pomocą wbudowanych narzędzi i Drusha: ```bash find sites/*/files -type f -name "*.php" drush pm:list --status=enabled --type=module composer audit ``` > **Wskazówka:** > 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](https://phpsos.de/pl/ratgeber/composer-abhaengigkeiten-pruefen/). ## 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`, katalog `files`, reguły serwera, role i uprawnienia. - Na życzenie przejmujemy bieżącą opiekę w ramach [umowy serwisowej bezpieczeństwa](https://phpsos.de/pl/leistungen/security-wartungsvertrag/), 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. ## Źródła - [php.net: komunikaty bezpieczeństwa](https://www.php.net/) - [Drupal](https://www.drupal.org/) - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)