Kort gezegd: Bij Drupal PHP-beveiliging gaat het na PHP2Shell vooral om de server: de kwetsbaarheid zit in PHP, niet in Drupal. Controleer de PHP-status in het statusrapport en bij de beheerder, herstart alle PHP-processen en controleer daarna settings.php, de files-map en de rolrechten.
Drupal en PHP2Shell: de situatie
Drupal wordt vaak ingezet voor grotere websites, portalen en overheidsinstanties, vaak met veel redacteuren en koppelingen. De PHP-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken het volgens het PHP-team mogelijk om op afstand en zonder inloggen schadelijke code uit te voeren. Hoe goed Drupal zelf wordt onderhouden, speelt daarbij geen rol.
Drupal heeft een eigen beveiligingsteam dat meldingen over core en modules publiceert. PHP2Shell hoort daar niet bij, omdat het geen Drupal-kwetsbaarheid is. Wie alleen de Drupal-meldingen volgt, kan dit bericht daarom hebben gemist.
Bij grotere Drupal-projecten is de verantwoordelijkheid vaak over meerdere partijen verdeeld: een bureau onderhoudt de code, een datacenter beheert de servers, de redactie zit in huis. Leg schriftelijk vast wie de PHP-update doorvoert, wie de herstart uitvoert en wie nagaat of er eerder iets is gebeurd. Bij opstellingen met meerdere webservers achter een load balancer moet elke afzonderlijke server zijn gepatcht en herstart, anders blijft een deel van de verzoeken op oude PHP draaien.
Drupal PHP-beveiliging: versie en patchstatus controleren
Onder Rapporten > Statusrapport toont Drupal de PHP-versie waarmee de website draait, samen met waarschuwingen over de configuratie. Op de opdrachtregel levert drush status de versie van de CLI-PHP, waarmee ook cronjobs en deployments draaien. Beide moeten zijn gepatcht.
Verholpen upstreamversies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Distributies en hostingproviders voeren correcties soms als backport door, dan blijft het nummer gelijk; bepalend is de bevestigde pakketstatus. Welke PHP-versies uw Drupal-versie ondersteunt, controleert u volgens de systeemeisen op drupal.org. Na de update hoort de herstart erbij, beschreven onder PHP-FPM en alle workers herstarten.
Mappen en bestanden die tellen
| Plek | Inhoud | Controlepunt |
|---|---|---|
sites/default/settings.php |
Database, hashsalt, trusted_host_patterns |
Wijzigingsdatum, ingevoegde includes |
sites/default/files/ |
openbare uploads, gegenereerde afbeeldingen, CSS en JS | geen PHP-bestanden, .htaccess aanwezig |
| privé-bestandsmap | beschermde uploads, vaak buiten de documentroot | Toegangsrechten |
modules/contrib/, modules/custom/ |
Modules van drupal.org en eigen ontwikkelingen | gewijzigde of onbekende modules |
themes/ |
Thema's met Twig-templates | vreemd JavaScript |
vendor/ |
Composer-afhankelijkheden | composer audit |
Drupal plaatst in de files-map een .htaccess die de uitvoering van PHP voorkomt. Onder Apache werkt die, onder Nginx niet. Daar is een eigen regel nodig:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Ongevaarlijke controles met standaardmiddelen en Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Vergelijk de codestatus op de server met uw Git-repository. Bij Drupal-projecten met Composer is dat de snelste manier om vreemde of gewijzigde bestanden te vinden, want elke afwijking moet te verklaren zijn.
Rollen, rechten en modules als risico
De aanmelding staat onder /user/login, het beheergedeelte onder /admin. In Drupal bepalen niet alleen beheerdersaccounts de beveiliging, maar ook afzonderlijke machtigingen. Rechten zoals het beheren van modules, gebruikers, machtigingen of tekstformaten met volledige HTML zijn praktisch beheerdersrechten. Controleer onder Personen en Machtigingen welke rollen ze hebben en wie tot die rollen behoort.
Contrib-modules breiden Drupal sterk uit, maar brengen eigen code mee. Modules zonder actief onderhoud en oude eigen ontwikkelingen zijn vaak de reden waarom een PHP-upgrade wordt uitgesteld. Meer over afhankelijkheden vindt u onder Composer-afhankelijkheden op kwetsbaarheden controleren.
Wat een Drupal-update wel en niet doet
Een core- of module-update dicht fouten in die code en kan nieuwere PHP-versies mogelijk maken. Ze patcht PHP niet, verwijdert geen vreemde bestanden uit sites/default/files, zet geen machtigingen terug en wist geen heimelijk aangemaakte accounts. Ook de cache kan gemanipuleerde inhoud blijven leveren tot ze wordt geleegd. Na een vermoeden moeten hashsalt en databasetoegang worden vernieuwd.
Bij multisite-installaties delen meerdere websites dezelfde code, maar hebben ze onder sites/ elk een eigen settings.php en een eigen files-map. Controleer dan elke website afzonderlijk. Een vondst in één site treft door de gedeelde code meestal ook alle andere.
Hoe helpt PHP SOS concreet?
- Wij controleren web- en CLI-PHP van uw Drupal-server en laten patch en herstart bevestigen.
- Wij maken een kopie van logs en gegevens en vergelijken de codestatus met uw repository of de originele pakketten.
- Wij controleren
settings.php, defiles-map, serverregels, rollen en machtigingen. - Desgewenst nemen wij het lopende onderhoud over in het beveiligingsonderhoudscontract, zodat PHP- en Drupal-updates niet weer uit elkaar lopen.
Veelgestelde vragen
Helpt een Drupal-beveiligingsupdate tegen PHP2Shell?
Nee. Drupal-updates dichten fouten in de Drupal-core en modules. PHP2Shell zit in de PHP van de server en vereist een PHP-update of een bevestigde backport, plus de herstart van alle PHP-processen.
Waar toont Drupal de PHP-versie?
In het statusrapport onder Rapporten. Met Drush toont drush status de PHP-versie van de opdrachtregel. Beide opgaven kunnen verschillen, en een backport is aan geen van beide met zekerheid te herkennen.
Beschermt de .htaccess in de files-map ook onder Nginx?
Nee. De door Drupal aangemaakte .htaccess wordt alleen door Apache geïnterpreteerd. Onder Nginx hebt u een eigen regel in de serverconfiguratie nodig die PHP-bestanden in de files-map blokkeert.
Wat betekent trusted_host_patterns?
De instelling in settings.php bepaalt onder welke hostnamen Drupal antwoordt. Ze beschermt tegen aanvallen via gemanipuleerde hostgegevens en hoort in elke productie-installatie.