PHP2Shell: Was die kritische PHP-Lücke für Ihre Website bedeutet

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen. Sie tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und laufen unter dem Namen „PHP2Shell“, in Anlehnung an Log4Shell. Das BSI hat noch am selben Tag eine Cybersicherheitswarnung mit der Warnstufe 3 von 4 (Orange) herausgegeben. Einige Betreiber haben ihre Server vorsorglich vom Netz genommen, Universitäten, Stadtverwaltungen und Kliniken waren zeitweise nicht erreichbar.

Hier steht, was betroffen ist, warum die Lage ernst ist und was Sie konkret prüfen sollten.

Was betroffen ist

Betroffen ist PHP selbst, also die Laufzeitumgebung auf dem Server, nicht eine einzelne Anwendung. Nach Angaben des BSI sind alle bekannten PHP-Versionen verwundbar, zurück bis mindestens PHP 5. Damit stehen praktisch alle PHP-Anwendungen im Feuer: WordPress, TYPO3, Joomla, Drupal, Nextcloud, Onlineshops mit Magento, aber auch Firewalls wie pfSense oder OPNsense, deren Oberfläche auf PHP aufbaut.

Beide Lücken haben im Bewertungssystem CVSS 4.0 einen Wert von 9,2 von 10. Für einen Angriff ist weder eine Anmeldung noch ein Zutun der Nutzer nötig. Wer eine verwundbare PHP-Installation erreicht, kann im schlimmsten Fall eigenen Programmcode auf dem Server ausführen und ihn damit vollständig übernehmen.

• CVE-2026-109618: Wenn PHP der Speicher ausgeht, kann eine Anfrage mitten in der Vorbereitung abbrechen. Beim Aufräumen werden halb angelegte Daten dann so behandelt, als wären sie gültig.
• CVE-2026-109619: Interne Daten einer Anfrage können überleben, obwohl ihr Speicher bereits freigegeben ist. Die nächste Anfrage im selben PHP-Prozess greift dann auf diese veralteten Daten zu.

Gefährdet ist jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM hinter nginx oder Apache, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das größte Risiko sieht das PHP-Team bei mod_php. Dort wurde ein Angriff gezeigt, der greift, bevor überhaupt Code der Anwendung läuft. Wer nginx mit PHP-FPM einsetzt, ist also ebenfalls betroffen, nur ist der Angriff dort schwieriger.

Warum die Lage ernst ist

Das BSI hielt schon vor der Veröffentlichung eine breite Ausnutzung innerhalb weniger Stunden für wahrscheinlich. Die Begründung: Mit KI-gestützten Werkzeugen lassen sich Sicherheitsupdates heute sehr schnell analysieren und in Angriffe übersetzen. Die Lücken selbst wurden übrigens ebenfalls mit Unterstützung von KI gefunden, von den Sicherheitsfirmen Wiz und Calif gemeinsam mit OpenAI.

Cloudflare berichtet inzwischen von Millionen Versuchen, die Lücken auszunutzen. Automatisierte Werkzeuge durchsuchen das Netz gezielt nach Servern, die noch nicht aktualisiert sind. Diese Welle wird nach Einschätzung von Fachleuten noch Wochen bis Monate anhalten.

Welche Versionen die Lücken schließen

Linux-Distributionen liefern teils eigene, zurückportierte Pakete mit anderer Versionsnummer. Dort zählt die Sicherheitsmeldung der jeweiligen Distribution, nicht die Nummer von php.net.

Was Sie jetzt prüfen sollten

1. Die laufende Version prüfen, nicht nur die installierte. Auf der Kommandozeile zeigt php -v die Version für Skripte. Die Website läuft aber meist über PHP-FPM, das eine eigene Versionsangabe hat, zum Beispiel php-fpm8.3 -v. Beide müssen auf dem neuen Stand sein.
2. PHP nach dem Update neu starten. Ein eingespieltes Paket hilft erst, wenn der Dienst neu gestartet ist. Der Startzeitpunkt von PHP-FPM muss nach dem Update liegen.
3. Container nicht vergessen. Läuft eine Anwendung in Docker, bringt das Update des Servers nichts. Das Image muss mit einem gepatchten PHP neu gebaut werden.
4. Beim Hoster nachfragen. Wer Webspace mietet, kann PHP meist nicht selbst aktualisieren. Große Hoster haben bereits nachgezogen, kleinere nicht unbedingt. Fragen Sie nach, und prüfen Sie in der Verwaltungsoberfläche, welche PHP-Version eingestellt ist.
5. Geräte mit eingebautem PHP prüfen. Firewalls, NAS-Systeme und manche Industrie-Komponenten haben eine Weboberfläche auf PHP-Basis. Hier braucht es ein Firmware-Update des Herstellers. Das niederländische NCSC sammelt betroffene Produkte in einer öffentlichen Liste.
6. Alte Versionen ablösen. PHP vor 8.2 bekommt keine offiziellen Updates mehr. Solche Systeme sollten Sie vom Netz trennen oder abschotten, bis sie auf eine unterstützte Version umgestellt sind.

Kann ein Update nicht sofort eingespielt werden, empfiehlt das BSI als letztes Mittel, den Server vorübergehend vom Internet zu trennen. Das PHP-Team nennt zwar Einstellungen, die die Angriffsfläche verkleinern, etwa ein niedriges post_max_size oder session.upload_progress.enabled=0. Einen vollständigen Schutz bieten diese Einstellungen aber nicht, sie überbrücken nur die Zeit bis zum Update. Auch eine Web Application Firewall erschwert Angriffe, ersetzt das Update aber nicht.

Woran man einen Angriff erkennt

Verbindliche Angriffsmerkmale gibt es laut BSI noch nicht. Für WordPress-Seiten lohnt trotzdem ein kurzer Blick auf ein paar Punkte, die ich auch an meinem eigenen Server geprüft habe:

• Stimmen WordPress-Kern und Plugins mit den Originaldateien überein? Mit WP-CLI geht das über wp core verify-checksums und wp plugin verify-checksums --all.
• Liegen PHP-Dateien im Upload-Ordner? Dort gehören nur Bilder und Dokumente hin.
• Gibt es neue Administrator-Konten, die niemand angelegt hat?
• Wurden seit dem 21. Oktober PHP-Dateien geändert, ohne dass ein Update lief?
• Zeigt das Fehlerprotokoll auffällig viele abgestürzte PHP-Prozesse oder Speicherfehler?

Bei meinem Server war das Update automatisch eingespielt und PHP-FPM neu gestartet. Alle Prüfungen waren unauffällig. Wer keine automatischen Sicherheitsupdates nutzt, sollte das zum Anlass nehmen, sie einzurichten.

Was das für die Praxis heißt

PHP2Shell zeigt, wie kurz die Zeit zwischen Sicherheitsupdate und Angriff geworden ist. Früher blieben Tage oder Wochen, heute rechnet das BSI mit Stunden. Wer Server betreibt, braucht deshalb drei Dinge: automatische Sicherheitsupdates, einen Überblick, wo überall PHP läuft, und jemanden, der im Ernstfall zeitnah reagieren kann. Das gilt für die Firmenwebsite genauso wie für die Weboberfläche einer Firewall oder eines Geräts in der Fertigung.

Wenn Sie unsicher sind, ob Ihre Systeme betroffen sind, schauen wir gemeinsam drauf: Kontakt aufnehmen.

Quellen

• BSI-IT-Sicherheitshinweis „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“, BITS-H Nr. 2026-297981-1132, Version 1.1 vom 21.10.2026: bsi.bund.de
• PHP Security Advisory „Critical remote code execution vulnerabilities, update now“: php.net
• GitHub Advisories zu CVE-2026-109618 und CVE-2026-109619
• Liste betroffener Produkte des NCSC-NL: github.com/NCSC-NL/php2shell
• tagesschau.de, „PHP-Bedrohung: Was über die Sicherheitslücke bekannt ist“: tagesschau.de