# Drupal PHP-biztonság a PHP2Shell után: így védje a weboldalát

> Drupal védelme a PHP2Shell után: PHP ellenőrzése az állapotjelentésben, a settings.php és a files mappa védelme, szerepkörök és modulok átvizsgálása.

Forrás: https://phpsos.de/hu/plattformen/drupal/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A Drupal PHP-biztonsága a PHP2Shell után elsősorban a szervert érinti: a rés a PHP-ben van, nem a Drupalban. Ellenőrizze a PHP-állapotot az állapotjelentésben és az üzemeltetőnél, indítsa újra az összes PHP-folyamatot, majd vizsgálja át a `settings.php` fájlt, a `files` könyvtárat és a szerepkörök jogait.

## A Drupal és a PHP2Shell: a helyzet

A Drupalt gyakran használják nagyobb weboldalakhoz, portálokhoz és közfeladatot ellátó szervek számára, sokszor sok szerkesztővel és interfésszel. A CVE-2026-109618 és a CVE-2026-109619 PHP-rések a PHP-csapat szerint lehetővé teszik kártékony kód távoli futtatását bejelentkezés nélkül. Az nem számít, hogy maga a Drupal mennyire jól gondozott.

A Drupalnak saját biztonsági csapata van, amely a magra és a modulokra vonatkozó közleményeket tesz közzé. A PHP2Shell nem tartozik ide, mert nem Drupal-rés. Aki csak a Drupal-közleményeket követi, ezért átsiklhatott a hír fölött.

A nagyobb Drupal-projektekben a felelősség gyakran több helyre oszlik: egy ügynökség gondozza a kódot, egy adatközpont üzemelteti a szervereket, a szerkesztőség a házban ül. Tisztázza írásban, ki juttatja be a PHP-frissítést, ki indítja az újraindítást, és ki ellenőrzi, történt-e előtte valami. Terheléselosztó mögötti több webszerveres felállásoknál minden egyes szervernek javítottnak és újraindítottnak kell lennie, különben a kérések egy része régi PHP-n marad.

## Drupal PHP-biztonság: verzió és javítási állapot ellenőrzése

A **Jelentések > Állapotjelentés** alatt a Drupal megmutatja azt a PHP-verziót, amellyel a weboldal fut, a konfigurációra vonatkozó figyelmeztetésekkel együtt. A parancssorban a `drush status` a CLI-s PHP verzióját adja meg, amellyel a cron-feladatok és a telepítések is futnak. Mindkettőnek javítottnak kell lennie.

A javított upstream verziók: 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A disztribúciók és a tárhelyszolgáltatók a javításokat részben backportként juttatják be, ilyenkor a szám ugyanaz marad; a megerősített csomagállapot az irányadó. Hogy a Drupal-verziója mely PHP-verziókat támogatja, azt a rendszerkövetelmények szerint a drupal.org oldalon ellenőrizheti. A frissítés után az újraindítás is hozzátartozik, amelyet a [A PHP-FPM és az összes worker újraindítása](https://phpsos.de/hu/php2shell/php-fpm-neustart/) oldal ír le.

## Könyvtárak és fájlok, amelyek számítanak

| Hely | Tartalom | Ellenőrzési pont |
|---|---|---|
| `sites/default/settings.php` | adatbázis, hash-só, `trusted_host_patterns` | módosítás dátuma, beszúrt include-ok |
| `sites/default/files/` | nyilvános feltöltések, generált képek, CSS és JS | nincs PHP-fájl, van `.htaccess` |
| privát fájlkönyvtár | védett feltöltések, gyakran a dokumentumgyökéren kívül | hozzáférési jogok |
| `modules/contrib/`, `modules/custom/` | a drupal.org modulai és egyedi fejlesztések | módosított vagy ismeretlen modulok |
| `themes/` | témák Twig-sablonokkal | idegen JavaScript |
| `vendor/` | Composer-függőségek | `composer audit` |

A Drupal a `files` könyvtárban létrehoz egy `.htaccess` fájlt, amely megakadályozza a PHP futtatását. Apache alatt hat, Nginx alatt nem. Ott saját szabály kell:

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

Veszélytelen ellenőrzések a beépített eszközökkel és a Drushsal:

```bash
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
```

> **Tipp:**
> Vesse össze a szerveren lévő kódállapotot a Git-tárolójával. A Composert használó Drupal-projekteknél ez a leggyorsabb mód az idegen vagy módosított fájlok megtalálására, mert minden eltérésnek megmagyarázhatónak kell lennie.

## Szerepkörök, jogok és modulok mint kockázat

A bejelentkezés a `/user/login`, az adminisztrációs terület az `/admin` alatt található. A Drupalban nem csak az adminisztrátori fiókok döntenek a biztonságról, hanem az egyes jogosultságok. Az olyan jogok, mint a modulok, felhasználók, jogosultságok vagy teljes HTML-t engedő szövegformátumok kezelése, gyakorlatilag adminisztrátori jogok. Az Emberek és a Jogosultságok alatt ellenőrizze, mely szerepköröknek mik a jogaik, és kik tartoznak ezekhez a szerepkörökhöz.

A contrib modulok erősen bővítik a Drupalt, de saját kódot hoznak. Az aktív gondozás nélküli modulok és a régi egyedi fejlesztések gyakran az oka annak, hogy a PHP-frissítést elhalasztják. A függőségekről bővebben a [Composer-függőségek ellenőrzése résekre](https://phpsos.de/hu/ratgeber/composer-abhaengigkeiten-pruefen/) oldalon olvashat.

## Mit tud egy Drupal-frissítés, és mit nem

Egy mag- vagy modulfrissítés lezárja az ebben a kódban lévő hibákat, és lehetővé tehet újabb PHP-verziókat. A PHP-t nem javítja, idegen fájlokat nem távolít el a `sites/default/files` mappából, nem állít vissza jogosultságokat, és nem töröl titokban létrehozott fiókokat. A gyorsítótár is kiszolgálhat manipulált tartalmakat, amíg ki nem ürítik. Gyanú esetén a hash-sót és az adatbázis-hozzáférést meg kell újítani.

A multisite telepítéseknél több weboldal osztozik ugyanazon a kódon, de a `sites/` alatt mindegyiknek saját `settings.php` fájlja és saját `files` könyvtára van. Ilyenkor minden weboldalt külön ellenőrizzen. Az egyik oldalon talált lelet a közös kód miatt többnyire az összes többit is érinti.

## Hogyan segít konkrétan a PHP SOS?

- Ellenőrizzük a Drupal-szerver web- és CLI-s PHP-ját, és megerősíttetjük a javítást és az újraindítást.
- Mentjük a naplókat és az adatokat, és összevetjük a kódállapotot az Ön tárolójával vagy az eredeti csomagokkal.
- Ellenőrizzük a `settings.php` fájlt, a `files` könyvtárat, a szerverszabályokat, a szerepköröket és a jogosultságokat.
- Kívánságra átvesszük a folyamatos gondozást a [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében, hogy a PHP- és Drupal-frissítések ne fussanak újra szét.


## Gyakori kérdések

**Segít egy Drupal biztonsági frissítés a PHP2Shell ellen?**  
Nem. A Drupal-frissítések a Drupal-mag és a modulok hibáit zárják le. A PHP2Shell a szerver PHP-jában van, és PHP-frissítést vagy megerősített backportot, valamint az összes PHP-folyamat újraindítását igényli.

**Hol mutatja a Drupal a PHP-verziót?**  
A Jelentések alatti állapotjelentésben. A Drushsal a drush status a parancssor PHP-verzióját mutatja. A két adat eltérhet, és egyikből sem ismerhető fel biztosan a backport.

**Véd a files mappában lévő .htaccess Nginx alatt is?**  
Nem. A Drupal által létrehozott .htaccess fájlt csak az Apache értékeli ki. Nginx alatt saját szabály kell a szerverkonfigurációban, amely letiltja a PHP-fájlokat a files könyvtárban.

**Mit jelent a trusted_host_patterns?**  
A settings.php-ban lévő beállítás határozza meg, mely hosztnevek alatt válaszol a Drupal. Védi a manipulált Host-adatokon keresztüli támadások ellen, és minden éles telepítésbe beletartozik.

## Források

- [php.net: biztonsági közlemények](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)