Накратко: При сигурността на PHP при Drupal след PHP2Shell става дума най-вече за сървъра: уязвимостта е в PHP, а не в Drupal. Проверете състоянието на PHP в отчета за състоянието и при оператора, рестартирайте всички PHP процеси и след това проверете settings.php, директорията files и правата на ролите.
Drupal и PHP2Shell: положението
Drupal се използва често за по-големи уебсайтове, портали и публични органи, често с много редактори и интерфейси. PHP уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват според екипа на PHP изпълнение на злонамерен код от разстояние без вход в системата. Колко добре се поддържа самият Drupal, няма значение за това.
Drupal има собствен екип по сигурност, който публикува съобщения за ядрото и модулите. PHP2Shell не е сред тях, защото не е уязвимост на Drupal. Който следи само съобщенията на Drupal, може затова да е пропуснал новината.
При по-големите проекти на Drupal отговорността често е разпределена между няколко места: агенция поддържа кода, център за данни експлоатира сървърите, редакцията е в къщи. Изяснете писмено кой внася актуализацията на PHP, кой задейства рестартирането и кой проверява дали преди това нещо се е случило. При настройки с няколко уеб сървъра зад load balancer всеки отделен сървър трябва да е пачнат и рестартиран, иначе част от заявките остава на стария PHP.
Сигурност на PHP при Drupal: проверка на версията и състоянието на пача
Под Reports > Status report Drupal показва версията на PHP, с която работи уебсайтът, заедно с предупреждения за конфигурацията. В командния ред drush status дава версията на CLI PHP, с който работят и cron задачите и deployment-ите. И двата трябва да са пачнати.
Поправените версии на оригиналния проект са 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Дистрибуциите и хостинг доставчиците понякога внасят корекциите като backport, тогава номерът остава същият; меродавно е потвърденото състояние на пакета. Кои версии на PHP поддържа Вашата версия на Drupal, проверете според системните изисквания на drupal.org. След актуализацията влиза и рестартирането, описано в Рестартиране на PHP-FPM и на всички worker процеси.
Директории и файлове, които имат значение
| Място | Съдържание | Какво да проверите |
|---|---|---|
sites/default/settings.php |
база данни, hash salt, trusted_host_patterns |
дата на промяна, вмъкнати includes |
sites/default/files/ |
публични качвания, генерирани изображения, CSS и JS | без PHP файлове, .htaccess налице |
| частна файлова директория | защитени качвания, често извън коренната директория | права за достъп |
modules/contrib/, modules/custom/ |
модули от drupal.org и собствени разработки | променени или непознати модули |
themes/ |
теми с Twig шаблони | чужд JavaScript |
vendor/ |
зависимости на Composer | composer audit |
Drupal създава в директорията files файл .htaccess, който възпрепятства изпълнението на PHP. При Apache той действа, при Nginx не. Там е нужно собствено правило:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Безопасни проверки с вградени средства и Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Сравнете състоянието на кода на сървъра с Вашето Git хранилище. При проекти на Drupal с Composer това е най-бързият начин да се намерят чужди или променени файлове, защото всяко отклонение трябва да може да се обясни.
Роли, права и модули като риск
Входът е на /user/login, административната зона на /admin. В Drupal за сигурността решават не само администраторските акаунти, а и отделните разрешения. Права като управление на модули, потребители, разрешения или текстови формати с пълен HTML на практика са администраторски права. Проверете под People и Permissions кои роли ги имат и кой принадлежи към тези роли.
Contrib модулите разширяват силно Drupal, но носят собствен код. Модулите без активна поддръжка и старите собствени разработки често са причината надграждането на PHP да се отлага. Повече за зависимостите има на страницата Проверка на зависимостите на Composer за уязвимости.
Какво постига актуализацията на Drupal и какво не
Актуализация на ядрото или на модул затваря грешки в този код и може да позволи по-нови версии на PHP. Тя не пачва PHP, не премахва чужди файлове от sites/default/files, не връща разрешенията и не изтрива тайно създадени акаунти. И кешът може да продължи да доставя манипулирано съдържание, докато не бъде изчистен. При подозрение hash salt и достъпът до базата данни трябва да се сменят.
При multisite инсталации няколко уебсайта споделят един и същ код, но имат под sites/ всеки собствен settings.php и собствена директория files. Проверете тогава всеки уебсайт поотделно. Находка в един сайт засяга заради общия код най-често и всички останали.
Как помага PHP SOS конкретно?
- Проверяваме уеб PHP и CLI PHP на Вашия сървър с Drupal и получаваме потвърждение за пача и рестартирането.
- Запазваме логове и данни и сравняваме състоянието на кода с Вашето хранилище или с оригиналните пакети.
- Контролираме
settings.php, директориятаfiles, правилата на сървъра, ролите и разрешенията. - При желание поемаме текущата поддръжка в договора за поддръжка на сигурността, за да не се разминават отново актуализациите на PHP и на Drupal.
Често задавани въпроси
Помага ли актуализация за сигурност на Drupal срещу PHP2Shell?
Не. Актуализациите на Drupal затварят грешки в ядрото и модулите на Drupal. PHP2Shell е в PHP на сървъра и изисква актуализация на PHP или потвърден backport, както и рестартиране на всички PHP процеси.
Къде Drupal показва версията на PHP?
В отчета за състоянието (Status report) под Reports. С Drush командата drush status показва версията на PHP за командния ред. Двете данни могат да се различават и по нито една от тях не може да се разпознае сигурно backport.
Защитава ли .htaccess в папката files и при Nginx?
Не. Създаденият от Drupal .htaccess се обработва само от Apache. При Nginx Ви трябва собствено правило в конфигурацията на сървъра, което блокира PHP файловете в директорията files.
Какво означава trusted_host_patterns?
Настройката в settings.php определя при кои имена на хостове Drupal отговаря. Тя защитава от атаки чрез манипулирани данни за хоста и трябва да има във всяка продукционна инсталация.