Kurz gesagt: Bei der Drupal-PHP-Sicherheit geht es nach PHP2Shell vor allem um den Server: Die Lücke steckt in PHP, nicht in Drupal. Prüfen Sie den PHP-Stand im Statusbericht und beim Betreiber, starten Sie alle PHP-Prozesse neu und kontrollieren Sie danach settings.php, das files-Verzeichnis und die Rollenrechte.
Drupal und PHP2Shell: die Lage
Drupal wird häufig für größere Websites, Portale und öffentliche Stellen eingesetzt, oft mit vielen Redakteuren und Schnittstellen. Die PHP-Lücken CVE-2026-109618 und CVE-2026-109619 erlauben laut PHP-Team Schadcode aus der Ferne ohne Anmeldung. Wie gut Drupal selbst gepflegt ist, spielt dafür keine Rolle.
Drupal hat ein eigenes Sicherheitsteam, das Hinweise zu Core und Modulen veröffentlicht. PHP2Shell gehört nicht dazu, weil es keine Drupal-Lücke ist. Wer nur die Drupal-Hinweise verfolgt, kann die Meldung deshalb übersehen haben.
Bei größeren Drupal-Projekten verteilt sich die Verantwortung oft auf mehrere Stellen: Eine Agentur pflegt den Code, ein Rechenzentrum betreibt die Server, die Redaktion sitzt im Haus. Klären Sie schriftlich, wer das PHP-Update einspielt, wer den Neustart auslöst und wer prüft, ob vorher etwas passiert ist. Bei Setups mit mehreren Webservern hinter einem Load Balancer muss jeder einzelne Server gepatcht und neu gestartet sein, sonst bleibt ein Teil der Anfragen auf altem PHP.
Drupal-PHP-Sicherheit: Version und Patchstand prüfen
Unter Berichte > Statusbericht zeigt Drupal die PHP-Version, mit der die Website läuft, zusammen mit Warnungen zur Konfiguration. Auf der Kommandozeile liefert drush status die Version des CLI-PHP, mit dem auch Cronjobs und Deployments laufen. Beide müssen gepatcht sein.
Behobene Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Distributionen und Hoster spielen Korrekturen teils als Backport ein, dann bleibt die Nummer gleich; maßgeblich ist der bestätigte Paketstand. Welche PHP-Versionen Ihre Drupal-Version unterstützt, prüfen Sie laut Systemanforderungen auf drupal.org. Nach dem Update gehört der Neustart dazu, beschrieben unter PHP-FPM und alle Worker neu starten.
Verzeichnisse und Dateien, die zählen
| Ort | Inhalt | Prüfpunkt |
|---|---|---|
sites/default/settings.php |
Datenbank, Hash-Salt, trusted_host_patterns |
Änderungsdatum, eingeschobene includes |
sites/default/files/ |
öffentliche Uploads, erzeugte Bilder, CSS und JS | keine PHP-Dateien, .htaccess vorhanden |
| privates Dateiverzeichnis | geschützte Uploads, oft außerhalb der Dokumentwurzel | Zugriffsrechte |
modules/contrib/, modules/custom/ |
Module von drupal.org und Eigenentwicklungen | veränderte oder unbekannte Module |
themes/ |
Themes mit Twig-Templates | fremdes JavaScript |
vendor/ |
Composer-Abhängigkeiten | composer audit |
Drupal legt im files-Verzeichnis eine .htaccess an, die das Ausführen von PHP unterbindet. Unter Apache wirkt sie, unter Nginx nicht. Dort braucht es eine eigene Regel:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Ungefährliche Prüfungen mit Bordmitteln und Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Vergleichen Sie den Code-Stand auf dem Server mit Ihrem Git-Repository. Bei Drupal-Projekten mit Composer ist das der schnellste Weg, fremde oder veränderte Dateien zu finden, denn jede Abweichung muss erklärbar sein.
Rollen, Rechte und Module als Risiko
Die Anmeldung liegt unter /user/login, der Verwaltungsbereich unter /admin. In Drupal entscheiden nicht nur Administratorkonten über die Sicherheit, sondern einzelne Berechtigungen. Rechte wie das Verwalten von Modulen, Benutzern, Berechtigungen oder Textformaten mit vollem HTML sind praktisch Administratorrechte. Prüfen Sie unter Personen und Berechtigungen, welche Rollen sie haben und wer diesen Rollen angehört.
Contrib-Module erweitern Drupal stark, bringen aber eigenen Code mit. Module ohne aktive Betreuung und alte Eigenentwicklungen sind oft der Grund, warum ein PHP-Upgrade aufgeschoben wird. Mehr zu Abhängigkeiten steht unter Composer-Abhängigkeiten auf Lücken prüfen.
Was ein Drupal-Update leistet und was nicht
Ein Core- oder Modul-Update schließt Fehler in diesem Code und kann neuere PHP-Versionen ermöglichen. Es patcht nicht PHP, entfernt keine fremden Dateien aus sites/default/files, setzt keine Berechtigungen zurück und löscht keine heimlich angelegten Konten. Auch der Cache kann manipulierte Inhalte weiter ausliefern, bis er geleert wird. Nach einem Verdacht gehören Hash-Salt und Datenbankzugang erneuert.
Bei Multisite-Installationen teilen sich mehrere Websites denselben Code, haben unter sites/ aber jeweils eine eigene settings.php und ein eigenes files-Verzeichnis. Prüfen Sie dann jede Website einzeln. Ein Fund in einer Site betrifft wegen des gemeinsamen Codes meist alle anderen ebenfalls.
Wie hilft PHP SOS konkret?
- Wir prüfen Web- und CLI-PHP Ihres Drupal-Servers und lassen Patch und Neustart bestätigen.
- Wir sichern Logs und Daten und vergleichen den Code-Stand mit Ihrem Repository oder den Originalpaketen.
- Wir kontrollieren
settings.php, dasfiles-Verzeichnis, Serverregeln, Rollen und Berechtigungen. - Auf Wunsch übernehmen wir die laufende Pflege im Security-Wartungsvertrag, damit PHP- und Drupal-Updates nicht wieder auseinanderlaufen.
Häufige Fragen
Hilft ein Drupal-Sicherheitsupdate gegen PHP2Shell?
Nein. Drupal-Updates schließen Fehler in Drupal-Core und Modulen. PHP2Shell liegt im PHP des Servers und braucht ein PHP-Update oder einen bestätigten Backport sowie den Neustart aller PHP-Prozesse.
Wo zeigt Drupal die PHP-Version an?
Im Statusbericht unter Berichte. Mit Drush zeigt drush status die PHP-Version der Kommandozeile. Beide Angaben können sich unterscheiden, und ein Backport ist an keiner davon sicher zu erkennen.
Schützt die .htaccess im files-Ordner auch unter Nginx?
Nein. Die von Drupal angelegte .htaccess wird nur von Apache ausgewertet. Unter Nginx brauchen Sie eine eigene Regel in der Serverkonfiguration, die PHP-Dateien im files-Verzeichnis sperrt.
Was bedeutet trusted_host_patterns?
Die Einstellung in settings.php legt fest, unter welchen Hostnamen Drupal antwortet. Sie schützt vor Angriffen über manipulierte Host-Angaben und gehört in jede produktive Installation.