PHP2Shell: was Betreiber von Websites und Web-Anwendungen jetzt tun müssen

Am 21. Oktober 2026 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Warnung der Stufe 3 von 4 herausgegeben. Zwei Schwachstellen in der Programmiersprache PHP erlauben es Angreifern, aus der Ferne Schadcode auf Webservern auszuführen. Dafür braucht es weder ein Benutzerkonto noch einen Klick eines Nutzers. In Fachmedien heißen die Lücken „PHP2Shell“, angelehnt an Log4Shell aus dem Jahr 2021. Wer eine Website, einen Webshop oder eine Web-Anwendung betreibt, sollte heute handeln.

Was ist passiert?

Das PHP-Projekt hat zwei Sicherheitslücken veröffentlicht, die beide mit 9.2 von 10 Punkten bewertet sind:

• CVE-2026-109618: Gerät PHP während einer Anfrage an seine Speichergrenze, können interne Daten halb initialisiert zurückbleiben. Ein Angreifer kann diesen Zustand gezielt herbeiführen und ausnutzen.
• CVE-2026-109619: Interne Daten einer Anfrage können länger überleben als der Speicher, auf dem sie liegen. Die nächste Anfrage im selben Prozess greift dann auf veraltete Daten zu.

Laut BSI gibt es unbestätigte Berichte über erste Angriffsversuche. Das Amt rechnet mit einer breiten Ausnutzung kurz nach Erscheinen der Updates, weil sich Patches mit KI-gestützten Werkzeugen heute sehr schnell analysieren lassen. Einige Betreiber haben ihre Server deshalb vorsorglich vom Netz genommen, was in Deutschland bereits zu nicht erreichbaren Websites geführt hat.

Wer ist betroffen?

Kurz gesagt: fast jeder, der PHP im Internet betreibt. Das PHP-Projekt nennt alle Installationen, die Webanfragen verarbeiten, ausdrücklich PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Verwundbar sind nach Angaben von CERT-EU alle Versionen bis mindestens zurück zu PHP 5. Das größte Risiko sieht das PHP-Team bei mod_php, weil der Angriff dort greifen kann, bevor überhaupt Code der Anwendung läuft.

PHP steckt in vielen Systemen, bei denen man nicht sofort daran denkt:

• Websites und Content-Management-Systeme wie WordPress, TYPO3, Joomla oder Drupal
• Webshops, zum Beispiel auf Basis von Magento
• Kollaborationsplattformen wie Nextcloud
• Firewalls wie pfSense und OPNsense sowie Weboberflächen von Appliances
• individuell entwickelte Portale und Fachanwendungen

Wichtig: Die Lücken stecken in PHP selbst, nicht in der Anwendung. Ein Update von WordPress oder Nextcloud allein schließt sie nicht.

Welche Versionen sind sicher?

Seit dem Nachmittag des 21. Oktober stehen Updates bereit: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für die Versionen 7.4, 8.0 und 8.1, die offiziell keine Updates mehr bekommen, hat das PHP-Team ausnahmsweise Quellcode-Korrekturen bereitgestellt. Wer PHP über die Paketverwaltung einer Linux-Distribution bezieht, erhält dort in der Regel zurückportierte Pakete mit eigener Versionsnummer. Dann hilft der Abgleich mit dem Sicherheitshinweis der Distribution, etwa bei Debian, Ubuntu oder Red Hat. Die Distributionen hatten die Korrekturen vorab erhalten.

Was jetzt zu tun ist

1. Bestand erfassen: Welche aus dem Internet erreichbaren Systeme nutzen PHP? Website, Shop, Intranet, Kundenportal, Firewall, Ticketsystem. Auch Systeme bei externen Dienstleistern gehören dazu.
2. Patchen und prüfen: PHP aktualisieren, alle PHP-Prozesse neu starten und den Stand mit php -v oder über den Paketstand kontrollieren.
3. Container neu bauen: Läuft PHP in Docker-Containern, reicht ein Update des Hosts nicht. Die Images müssen mit gepatchtem PHP neu gebaut werden.
4. Hersteller und Provider fragen: Bei Appliances und Firewalls braucht es neue Firmware. Bei gemietetem Webspace sollten Sie sich bestätigen lassen, dass das Update eingespielt ist.
5. Altversionen ablösen: PHP vor 8.2 bekommt vom PHP-Projekt keine Updates mehr, PHP 8.2 nur noch bis Jahresende. Solche Systeme sollten ohnehin auf eine unterstützte Version umziehen.

Wenn ein Update heute nicht möglich ist

Das BSI empfiehlt in diesem Fall, den Server vorübergehend vom Internet zu trennen. Das PHP-Team nennt zwar Einstellungen, die bekannte Angriffswege erschweren, etwa session.upload_progress.enabled=0 und ein niedriges post_max_size. Es betont aber selbst, dass diese Maßnahmen eine Installation nicht sicher machen. Gleiches gilt für Regeln einer Web Application Firewall, wie sie Anbieter inzwischen ausliefern: Sie blockieren bekannte Muster, nicht jede Variante. Vollständigen Schutz bietet nur das Update.

Unabhängig vom aktuellen Fall rät das BSI, Mechanismen wie SELinux oder AppArmor zu nutzen. Sie begrenzen den Schaden, falls eine Lücke doch einmal ausgenutzt wird.

Warum Patch-Management Chefsache ist

PHP2Shell zeigt, wie knapp die Zeit inzwischen ist. Zwischen Veröffentlichung eines Patches und ersten Angriffen liegen oft nur noch Stunden. Wer Updates erst im nächsten Wartungsfenster plant, ist dann zu spät. Ein gutes Patch-Management braucht deshalb drei Dinge: einen aktuellen Überblick, welche Software wo läuft, jemanden, der Sicherheitswarnungen laufend verfolgt, und die Möglichkeit, kritische Updates kurzfristig auszurollen und zu testen.

Genau das ist der Kern unseres Managed Hostings. Updates, Sicherheits-Patches und Systemhärtung gehören bei uns zum Standard, dazu kommen Monitoring rund um die Uhr und tägliche Backups. Unsere Server stehen im NTT-Rechenzentrum in Frankfurt am Main.

Fazit

Die beiden PHP-Lücken betreffen einen großen Teil des Internets, und das BSI erwartet schnelle Angriffe. Prüfen Sie heute, wo in Ihrem Unternehmen PHP läuft, und spielen Sie die Updates ein. Wo das nicht sofort geht, ist eine vorübergehende Trennung vom Netz die sicherere Wahl. Die Details finden Sie im Sicherheitshinweis des BSI und in der Meldung des PHP-Projekts.

Alle Beiträge