# Сигурност на PHP при Drupal след PHP2Shell: как да защитите уебсайта си

> Защитете Drupal след PHP2Shell: проверете PHP в отчета за състоянието, предпазете settings.php и папката files, контролирайте ролите и модулите.

Източник: https://phpsos.de/bg/plattformen/drupal/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

**Накратко:** При сигурността на 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 процеси](https://phpsos.de/bg/php2shell/php-fpm-neustart/).

## Директории и файлове, които имат значение

| Място | Съдържание | Какво да проверите |
|---|---|---|
| `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 не. Там е нужно собствено правило:

```nginx
location ~* ^/sites/.+/files/.+\.php$ {
    deny all;
}
```

Безопасни проверки с вградени средства и Drush:

```bash
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 за уязвимости](https://phpsos.de/bg/ratgeber/composer-abhaengigkeiten-pruefen/).

## Какво постига актуализацията на Drupal и какво не

Актуализация на ядрото или на модул затваря грешки в този код и може да позволи по-нови версии на PHP. Тя не пачва PHP, не премахва чужди файлове от `sites/default/files`, не връща разрешенията и не изтрива тайно създадени акаунти. И кешът може да продължи да доставя манипулирано съдържание, докато не бъде изчистен. При подозрение hash salt и достъпът до базата данни трябва да се сменят.

При multisite инсталации няколко уебсайта споделят един и същ код, но имат под `sites/` всеки собствен `settings.php` и собствена директория `files`. Проверете тогава всеки уебсайт поотделно. Находка в един сайт засяга заради общия код най-често и всички останали.

## Как помага PHP SOS конкретно?

- Проверяваме уеб PHP и CLI PHP на Вашия сървър с Drupal и получаваме потвърждение за пача и рестартирането.
- Запазваме логове и данни и сравняваме състоянието на кода с Вашето хранилище или с оригиналните пакети.
- Контролираме `settings.php`, директорията `files`, правилата на сървъра, ролите и разрешенията.
- При желание поемаме текущата поддръжка в [договора за поддръжка на сигурността](https://phpsos.de/bg/leistungen/security-wartungsvertrag/), за да не се разминават отново актуализациите на 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 отговаря. Тя защитава от атаки чрез манипулирани данни за хоста и трябва да има във всяка продукционна инсталация.

## Източници

- [php.net: Съобщения за сигурност](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)