PHP-Sicherheitslücke PHP2Shell: was sie für Drupal-Websites bedeutet

Die PHP-Sicherheitslücke PHP2Shell (CVE-2026-109618 und CVE-2026-109619), für die das PHP-Team am 21. Oktober 2026 Korrekturen veröffentlicht hat, steckt in PHP selbst. Das ist die Software, die auf dem Server jede Drupal-Seite ausführt. Damit ist jede Drupal-Website ohne gepatchtes PHP betroffen, egal ob Drupal 7, 10 oder 11. Ein Update von Drupal oder seinen Modulen hilft nicht. Sicher ist die Website erst, wenn auf dem Server ein gepatchtes PHP läuft.

Wir haben am 21. und 22. Oktober 2026 alle Server aktualisiert, die wir für unsere Kunden betreiben. In diesem Beitrag steht, was über die Lücke bekannt ist, wie Sie prüfen, ob Ihre Website geschützt ist, und was bei älteren PHP-Versionen zu tun ist.

Was über die PHP-Sicherheitslücke PHP2Shell bekannt ist

Die Entwickler von PHP haben die Lücke am 20. Oktober 2026 angekündigt und am 21. Oktober um 16 Uhr deutscher Zeit die Korrekturen bereitgestellt. Es handelt sich um zwei Schwachstellen in der Art, wie PHP Anfragen und Speicher verwaltet. Beide sind mit 9,2 von 10 Punkten bewertet. Im ungünstigsten Fall kann ein Angreifer ohne Anmeldung eigenen Programmcode auf dem Server ausführen.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat eine Warnung der Stufe 3 (Orange) herausgegeben. Laut BSI sind alle bekannten PHP-Versionen verwundbar, mindestens zurück bis PHP 5. Einige Betreiber haben ihre Server am 21. Oktober vorsorglich vom Netz genommen, bis das Update eingespielt war. Bestätigte Angriffe waren dem BSI zum Zeitpunkt der Warnung nicht bekannt. Es geht aber davon aus, dass Angreifer die Lücke kurzfristig ausnutzen.

Die Sicherheitsmeldung von PHP nennt alle Installationen als gefährdet, die Webanfragen verarbeiten, also praktisch jeden Webserver mit PHP (PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed). Das höchste Risiko sieht das PHP-Team bei mod_php. Dort wurde ein Angriff gezeigt, der greift, bevor überhaupt Code der Website ausgeführt wird.

Warum ein Drupal-Update nicht hilft

Drupal ist in PHP geschrieben. PHP ist die Laufzeitumgebung darunter, die der Server bereitstellt. Die Lücke sitzt in dieser Laufzeitumgebung und nicht im Code von Drupal. Auch das BSI weist darauf hin, dass ein Update der Anwendung nicht reicht.

Das Drupal Security Team hat vorab einen öffentlichen Hinweis (PSA-2026-10-20) herausgegeben. Darin bittet es Betreiber, Zeit für das PHP-Update einzuplanen, und nennt das Update als einzigen vollständigen Schutz. Ein Drupal-Release zu PHP2Shell ist nicht angekündigt und würde auch nicht helfen, weil die Lücke in PHP liegt.

Zuständig ist also, wer den Server betreut. Bei einem Managed Hosting ist das der Hoster. Liegt die Website auf einem eigenen Server oder einem virtuellen Server, müssen Sie oder Ihr Dienstleister das Update selbst einspielen.

So prüfen Sie, ob Ihre Drupal-Website geschützt ist

1. Klären, wer PHP verwaltet. Bei einem Managed Hosting fragen Sie beim Hoster nach, ob und wann PHP aktualisiert wurde. Bei einem eigenen Server geht es mit Schritt 2 weiter.
2. Version und Paket prüfen. Der Befehl php -v zeigt die PHP-Version, reicht aber allein nicht aus. Linux-Distributionen bauen Sicherheitskorrekturen in ihre bestehenden Versionen ein. Unter Ubuntu 24.04 meldet PHP zum Beispiel weiter 8.3.6, sicher ist es trotzdem ab dem Paket 8.3.6-0ubuntu0.24.04.13. Welche Paketversion die Korrektur enthält, steht in den Sicherheitshinweisen der Distribution, etwa bei Ubuntu.
3. Paketquelle prüfen. Viele Server holen ihre Updates von einem Spiegelserver des Hosters. Der kann einige Stunden hinter der offiziellen Quelle liegen. Bietet der Server die Korrektur nicht an, lohnt ein Blick, ob die Sicherheitsquelle der Distribution eingetragen ist.
4. Alle PHP-Versionen erfassen. Auf vielen Servern sind mehrere PHP-Versionen parallel installiert, etwa für verschiedene Websites. Jede Version, die Webanfragen annimmt, braucht das Update. Was nicht mehr gebraucht wird, schalten Sie besser ab.
5. PHP neu starten. Das neue Paket wirkt erst, wenn die PHP-Prozesse neu gestartet sind, also PHP-FPM oder Apache. Bis dahin läuft der alte Code im Speicher weiter.
6. Container neu bauen. Läuft PHP in einem Docker-Container, muss das Image mit dem gepatchten PHP neu gebaut und der Container ersetzt werden. Ein Update auf dem Server selbst erreicht den Container nicht.

Drupal 7 und ältere PHP-Versionen

Für PHP 8.1 und älter liefert das PHP-Team keine fertigen Versionen mehr. Für 7.4, 8.0 und 8.1 hat es die Korrekturen als Quellcode bereitgestellt, für noch ältere Versionen gar nicht. Abhilfe kommt in diesem Fall von den Linux-Distributionen und Anbietern mit Langzeit-Support. Ubuntu hat zum Beispiel auch PHP 7.2 und 7.4 auf älteren Ubuntu-Versionen über seine erweiterte Sicherheitsversorgung (ESM, Teil von Ubuntu Pro) gepatcht.

Das betrifft vor allem Websites mit Drupal 7. Drupal 7 bekommt seit dem 5. Januar 2025 keine Sicherheitsupdates mehr und läuft oft noch mit einer älteren PHP-Version. Manche Betreiber haben gute Gründe, die Website trotzdem weiter zu betreiben, etwa weil eine Migration geplant, aber noch nicht umgesetzt ist. Mit PHP2Shell wird aus dieser Übergangslösung ein akutes Risiko.

Läuft eine Drupal-7-Website in einem Container mit einer PHP-Version ohne Korrektur, ersetzen wir den Container durch einen mit gepatchtem PHP aus dem Langzeit-Support. Vorher setzen wir eine Kopie der Website lokal auf, prüfen den Code automatisch auf Probleme mit der neuen PHP-Version und passen ihn wo nötig an. Die Umstellung selbst dauert dann nur Sekunden.

Das ist eine Brücke und keine Dauerlösung. Wie der Weg von Drupal 7 auf eine aktuelle Version aussieht, steht in unserem Beitrag zum Drupal-7-Update und Support-Ende und auf der Seite zur Drupal-Migration.

Workarounds überbrücken nur

Das PHP-Team nennt einige Einstellungen, die einen Angriff erschweren. Dazu gehören ein abgeschalteter Upload-Fortschritt für Sessions (session.upload_progress.enabled=0), ein niedriger Wert für post_max_size und eine aufgehobene Speichergrenze (memory_limit=-1). Die Einstellungen müssen in der php.ini oder der Konfiguration von PHP-FPM oder Apache stehen, nicht in einer .user.ini oder im Code der Website. Danach muss PHP neu starten.

Laut PHP-Team machen diese Maßnahmen eine Installation nicht sicher. Sie überbrücken höchstens die Zeit, bis das Update verfügbar ist. Kann das Update nicht zeitnah eingespielt werden, rät das BSI, eine vorübergehende Trennung vom Internet zu erwägen.

Wie wir reagiert haben

Wir haben 40 Minuten nach Erscheinen der Korrekturen mit der Prüfung begonnen. Der erste Server war knapp eine Stunde nach der Veröffentlichung aktualisiert. Am frühen Abend des 21. Oktober waren die meisten Server aktualisiert, alle übrigen am nächsten Vormittag, weniger als 24 Stunden nach Erscheinen der Korrekturen.

Auf jedem Server sind wir gleich vorgegangen:

• Paketquelle geprüft und bei Bedarf die offizielle Sicherheitsquelle der Distribution eingetragen, weil der Spiegelserver des Hosters die Korrektur noch nicht hatte
• alle installierten PHP-Versionen erfasst und nicht mehr genutzte abgeschaltet
• die Pakete aktualisiert und PHP-FPM und Apache neu gestartet
• anhand der Paketversion und der laufenden Prozesse geprüft, dass kein alter PHP-Code mehr im Speicher läuft
• die Websites aufgerufen und auf Fehler geprüft

Wo die Korrektur für eine PHP-Version am ersten Abend noch nicht als Paket vorlag, haben wir die Workarounds gesetzt und am nächsten Morgen das Update nachgeholt. Server mit älteren PHP-Versionen haben die Korrektur über die erweiterte Sicherheitsversorgung von Ubuntu bekommen.

Diese Arbeit gehört für uns zur Drupal-Wartung. Kritische Sicherheitslücken schließen wir innerhalb von 24 Stunden, nachdem das Update erschienen ist. Das gilt für Drupal-Core und Module und, wenn wir den Server betreiben, auch für PHP und das Betriebssystem. Unsere Server stehen in Deutschland. Mehr zu den einzelnen Schritten bei Drupal-Updates steht im Beitrag über Drupal-Sicherheitsupdates.

Wenn Ihre Drupal-Website keine Betreuung mehr hat

Nicht jede Drupal-Website hat noch einen Dienstleister. Manchmal hat die Agentur aufgehört, der Entwickler ist weg oder der Server wurde vor Jahren eingerichtet und seitdem nicht mehr angefasst. PHP2Shell zeigt, warum das riskant ist: Bei einer Lücke dieser Größe zählen die Stunden nach dem Update.

Wir übernehmen bestehende Drupal-Websites, auch ältere. Zuerst prüfen wir PHP-Version, Server, Drupal-Version und Module und schließen offene Lücken. Danach betreuen wir die Website in der Wartung weiter oder planen mit Ihnen das Upgrade. Wie eine Drupal-Projektübernahme abläuft, steht auf der Leistungsseite. Wenn Sie wissen möchten, ob Ihre Website geschützt ist, schreiben Sie uns über das Kontaktformular.