PHP-Sicherheitslücke PHP2Shell: Was Du jetzt tun musst

Mehr als 22,6 Millionen PHP-Installationen im Internet könnten laut Palo Alto Networks gerade angreifbar sein. Der Grund ist keine exotische Spezialsoftware, sondern PHP: die Programmiersprache, mit der WordPress, Shopware, TYPO3, Joomla und unzählige Firmenwebsites laufen.

Seit dem 21. Oktober 2026 sind Details zu einer kritischen PHP-Sicherheitslücke öffentlich, die unter dem Namen PHP2Shell bekannt geworden ist. Sie steckt nicht in einem Plugin oder Theme, sondern im Kern von PHP selbst. Das BSI rät, die verfügbaren Patches unverzüglich einzuspielen. Die US-Behörde CISA geht noch weiter: Wer nicht patchen kann, soll betroffene Systeme vom Netz nehmen.

Vermutlich denkst Du jetzt: Darum kümmert sich doch mein Hoster. Oft stimmt das. Aber eben nicht immer, und genau dort entstehen die Lücken.

In diesem Artikel erfährst Du, was hinter PHP2Shell steckt, ob Deine Website betroffen ist, wie Du in fünf Minuten Deine PHP-Version prüfst und welche Schritte jetzt wirklich zählen. Am Ende findest Du eine Checkliste, die Du direkt mit Deinem Hoster oder Dienstleister durchgehen kannst.

Was ist PHP2Shell? Die PHP-Sicherheitslücke kurz erklärt

PHP2Shell ist der Sammelname für zwei Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Beide wurden mit 9,2 von 10 Punkten im Bewertungssystem CVSS eingestuft, das gilt als kritisch. Angreifer können darüber aus der Ferne eigenen Code auf dem Webserver ausführen, ohne sich vorher anmelden zu müssen.

Technisch geht es um Fehler in der Speicherverwaltung von PHP:

• CVE-2026-109618: Wenn PHP während einer Anfrage der Speicher ausgeht, räumt es Daten auf, die noch gar nicht vollständig angelegt waren. Ein Angreifer kann genau diesen Zustand gezielt herbeiführen.
• CVE-2026-109619: Reste einer früheren Anfrage zeigen auf bereits freigegebenen Speicher. Eine spätere Anfrage an denselben PHP-Prozess kann diesen Speicher nutzen (ein sogenannter Use-after-free). Laut PHP-Projekt lassen sich darüber auch Speicherinhalte auslesen.

Das Gefährliche daran: Der Angriff funktioniert, bevor überhaupt Code Deiner Website ausgeführt wird. Ein gut gepflegtes WordPress mit aktuellen Plugins schützt Dich hier also nicht. Entscheidend ist allein die PHP-Version auf dem Server.

Wie ernst ist die Lage?

Die Einschätzungen unterscheiden sich, aber die Richtung ist eindeutig. Amazon Threat Intelligence hat nach eigenen Angaben einen ersten Angriffsversuch schon am 17. Oktober beobachtet, also vier Tage vor der offiziellen Veröffentlichung. Cloudflare meldet erste Angriffe und hat Filterregeln ausgerollt. Öffentlicher Beispielcode für Angriffe kursiert ebenfalls.

Das BSI schreibt in seiner Cybersicherheitswarnung mit Stand 22. Oktober, dass ihm noch keine erfolgreiche Ausnutzung in der Breite bekannt ist. Das ist eine gute Nachricht, aber keine Entwarnung. Bei Lücken dieser Kategorie vergehen zwischen Veröffentlichung und massenhaften Angriffen erfahrungsgemäß nur Tage.

Ist Deine Website von der PHP-Sicherheitslücke betroffen?

Die kurze Antwort: Wenn Deine Website mit PHP läuft und der Server noch nicht aktualisiert wurde, ja. Laut PHP-Projekt ist praktisch jede Installation gefährdet, die Webanfragen beantwortet. Das gilt für alle gängigen Betriebsarten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php.

Betroffen sind damit unter anderem:

• WordPress-Websites, inklusive Elementor- und WooCommerce-Seiten
• Online-Shops auf Basis von Shopware, Magento oder WooCommerce
• Systeme wie TYPO3, Joomla oder Drupal
• Kundenportale, Buchungstools und interne Webanwendungen, die in PHP geschrieben sind
• Admin-Oberflächen wie Hosting-Panels, die selbst auf PHP laufen

Nicht betroffen sind rein statische Websites ohne PHP sowie Anwendungen, die komplett auf anderen Sprachen basieren. Auch Microsoft 365 und SharePoint Online sind von PHP2Shell nicht berührt.

Diese PHP-Versionen sind abgesichert

Das PHP-Projekt hat am 21. Oktober korrigierte Versionen veröffentlicht. Sicher sind:

PHP-Zweig	Abgesicherte Version	Status
PHP 8.5	ab 8.5.12	Update verfügbar
PHP 8.4	ab 8.4.27	Update verfügbar
PHP 8.3	ab 8.3.36	Update verfügbar
PHP 8.2	ab 8.2.35	Update verfügbar
PHP 7.4 bis 8.1	kein offizielles Release	nur minimale Quellcode-Korrekturen
PHP 5.4 bis 7.3	kein Fix	seit Jahren ohne Support

Wichtig für Server mit Linux-Distributionen wie Debian, Ubuntu oder Red Hat: Dort bekommst Du oft keine neue Versionsnummer, sondern ein gepatchtes Paket des Distributors. Eine Anzeige wie „PHP 8.3.6“ kann also sicher sein, wenn das Paket den Backport enthält. Ob das so ist, verrät nur das Änderungsprotokoll des Pakets, nicht die Versionsnummer allein.

Du bist Dir unsicher, wie es um Deine Website steht? Unser Team für Cyber Security prüft gemeinsam mit Dir den Patch-Stand und sagt Dir ehrlich, ob Handlungsbedarf besteht.

So prüfst Du Deine PHP-Version in fünf Minuten

Du musst kein Admin sein, um einen ersten Überblick zu bekommen. Je nach Setup hast Du drei Wege.

Weg 1: WordPress-Website-Zustand

In WordPress findest Du die PHP-Version unter Werkzeuge → Website-Zustand → Bericht → Server. Das ist der schnellste Check für alle, die eine WordPress-Website betreiben.

Der Haken: WordPress zeigt nur die Versionsnummer an, nicht den Patch-Stand des Distributors. Steht dort 8.1 oder älter, hast Du ein Problem. Steht dort 8.2 oder neuer, brauchst Du zusätzlich die Bestätigung Deines Hosters, dass das Update eingespielt ist.

Weg 2: Hosting-Panel und Hoster-Status

Bei klassischem Webhosting stellst Du die PHP-Version meist im Kundenbereich des Hosters ein. Viele Hoster haben in den vergangenen Tagen über ihre Statusseiten informiert, einige haben Hosting-Pakete vorsorglich kurz abgeschaltet und dann aktualisiert. Prüfe die Statusseite oder frag direkt nach. Eine kurze Mail mit der Frage „Ist PHP2Shell auf meinem Paket gepatcht?“ reicht.

Weg 3: Eigener Server oder vServer

Betreibst Du einen eigenen Server, bist Du selbst verantwortlich. Hier helfen diese Befehle:

• php -v zeigt die installierte Version auf der Kommandozeile.
• dpkg -l | grep php (Debian/Ubuntu) oder rpm -qa | grep php (RHEL/AlmaLinux) zeigt die Paketstände.
• Die Advisories Deiner Distribution verraten, welche Paketversion den Fix enthält.

Achtung: Die Kommandozeilen-Version kann von der Version abweichen, mit der der Webserver arbeitet. Im Zweifel prüfst Du den Wert aus dem Website-Zustand gegen.

Was Du jetzt konkret tun solltest

Die wichtigste Maßnahme ist unspektakulär: updaten. Laut PHP-Projekt ist das die einzige vollständige Lösung. Alles andere ist eine Notlösung für die Zeit bis zum Update.

Schritt 1: Update einspielen und PHP neu starten

Spiel die gepatchte Version oder das Distributionspaket ein. Danach müssen alle laufenden PHP-Prozesse neu gestartet werden, etwa der PHP-FPM-Dienst oder der Apache-Webserver. Ohne Neustart läuft der alte, verwundbare Code einfach weiter. Dieser Schritt wird erstaunlich oft vergessen.

Schritt 2: Alte PHP-Versionen ersetzen, nicht flicken

Läuft Deine Website noch auf PHP 8.1 oder älter, gibt es kein offizielles Update. CISA empfiehlt in ihrer Warnung zu den PHP-Schwachstellen, solche Systeme vom Netz zu nehmen, wenn sie nicht gepatcht werden können. Das klingt drastisch, ist aber konsequent.

Der saubere Weg ist ein Wechsel auf eine gepatchte Version von PHP 8.3, 8.4 oder 8.5. Bei älteren WordPress-Installationen heißt das oft: erst Plugins und Theme auf Kompatibilität prüfen, dann umstellen. Eine Kopie der Website auf einer Testumgebung (Staging) spart Dir dabei böse Überraschungen.

Schritt 3: Übergangslösungen, wenn das Update dauert

Für Administratoren, die nicht sofort patchen können, nennt das PHP-Projekt vorläufige Schutzmaßnahmen:

• Für CVE-2026-109618: memory_limit=-1 auf Server-Ebene setzen, sodass Anwendungen den Wert nicht überschreiben können.
• Für CVE-2026-109619: session.upload_progress.enabled=0 setzen, bei PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Anschließend alle PHP-Worker neu starten.

Das ist keine Dauerlösung. Ohne Speicherlimit kann ein einzelnes fehlerhaftes Skript den Server ausbremsen, deshalb sollte zusätzlich ein Limit auf Container- oder Systemebene greifen. Eine Web Application Firewall (WAF), also ein vorgeschalteter Filter für den Datenverkehr, kann bekannte Angriffsmuster abfangen. Sie hilft aber nur, wenn der gesamte Traffic tatsächlich über sie läuft.

Schritt 4: Auf Spuren eines Angriffs prüfen

Da erste Angriffsversuche schon ab dem 17. Oktober beobachtet wurden, empfehlen mehrere Sicherheitsforscher, öffentlich erreichbare Systeme ab diesem Datum zu überprüfen. Achte in den Server-Logs auf ungewöhnlich viele Fehlermeldungen (Statuscodes 500, 502, 503), auffällige POST-Anfragen und unbekannte PHP-Dateien in Upload-Verzeichnissen. Verlässliche Erkennungsmerkmale gibt es laut Fachpresse derzeit noch nicht.

Findest Du Hinweise auf einen erfolgreichen Angriff, reicht ein Update allein nicht mehr. Dann gehören Passwörter, Datenbank-Zugänge und API-Schlüssel ausgetauscht, und die Website sollte aus einer sauberen Sicherung wiederhergestellt werden. Spätestens hier zeigt sich, wie gut Deine Datensicherung wirklich ist.

Zwei Szenarien aus dem Alltag

Wie PHP2Shell in der Praxis zuschlägt, zeigt sich selten an großen Konzernen. Gefährdet sind vor allem Websites, um die sich gerade niemand aktiv kümmert.

Szenario 1: Die Website, die „einfach läuft“. Eine Steuerkanzlei hat ihre WordPress-Website vor fünf Jahren von einem Freelancer bauen lassen. Seitdem läuft sie auf einem eigenen vServer, den niemand mehr betreut. Die Website funktioniert, also fragt keiner nach.

Auf dem Server läuft PHP 7.4, ein Update gibt es dafür nicht. Über das Kontaktformular gehen täglich Mandantenanfragen mit sensiblen Daten ein. Genau solche Systeme sind das ideale Ziel für automatisierte Angriffswellen.

Szenario 2: Der Shop mit dem halben Update. Ein Großhändler für Ersatzteile betreibt einen Online-Shop auf eigener Infrastruktur. Die IT spielt am Abend des 21. Oktober brav das Update ein, startet aber den PHP-FPM-Dienst nicht neu, weil der Shop gerade Bestellungen verarbeitet.

Zwei Tage lang läuft der alte Code weiter, obwohl das Monitoring „aktuell“ meldet. Erst bei einem externen Check fällt die Diskrepanz auf.

Beide Fälle haben dasselbe Muster: Es fehlt nicht an Wissen, sondern an klarer Verantwortung. Niemand fühlt sich für den Server zuständig, oder niemand prüft, ob ein Update wirklich wirkt.

Was die PHP-Sicherheitslücke über Deine IT-Sicherheit verrät

PHP2Shell wird nicht die letzte Lücke dieser Art sein. Die eigentliche Frage ist deshalb nicht nur „Bin ich jetzt sicher?“, sondern „Wie schnell reagiert mein Unternehmen beim nächsten Mal?“. Drei Punkte entscheiden darüber.

1. Du weißt, was Du betreibst. Viele Unternehmen haben neben der Hauptwebsite noch Landingpages, alte Microsites, ein Bewerberportal oder ein Kundenportal. Jedes davon ist ein möglicher Einstiegspunkt. Eine einfache Liste aller Systeme mit Hoster, PHP-Version und Ansprechpartner ist der erste Schritt.

2. Updates haben einen festen Prozess. Wer spielt Sicherheitsupdates ein, wie schnell, und wer kontrolliert das Ergebnis? Bei kritischen Lücken sollten es Stunden sein, nicht Wochen. Für kleinere Betriebe ohne eigene IT-Abteilung ist eine laufende Betreuung durch einen festen Dienstleister oft der realistischste Weg.

3. Du lässt Deine Angriffsfläche regelmäßig prüfen. Ein externer Blick findet veraltete Systeme, die intern niemand mehr auf dem Schirm hat. Wie so eine Prüfung abläuft, erklären wir im Artikel zum Penetrationstest für KMU.

Wer unter die NIS2-Richtlinie fällt, also die EU-Vorgaben für Cybersicherheit in wichtigen Branchen, muss solche Prozesse ohnehin nachweisen können. Aber auch ohne gesetzliche Pflicht gilt: Eine kompromittierte Website kostet Vertrauen, Zeit und im schlimmsten Fall Kundendaten. Einen breiteren Überblick zu sinnvollen Schutzmaßnahmen findest Du in unserem Beitrag zur Cyber-Sicherheit für Unternehmen.

Du hast keine eigene IT, die Updates und Server im Blick behält? Wir übernehmen das als Deine externe IT-Abteilung, mit festem Ansprechpartner statt anonymer Hotline. Sprich uns einfach an.

Checkliste: PHP2Shell in 7 Schritten abhaken

Diese Liste kannst Du direkt an Deinen Hoster, Deine Agentur oder Deine IT weitergeben:

1. Alle Systeme erfassen, die mit PHP laufen: Website, Shop, Portale, Microsites, Admin-Panels.
2. PHP-Version prüfen, etwa im WordPress-Website-Zustand oder im Hosting-Panel.
3. Patch-Stand bestätigen lassen: 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder gepatchtes Distributionspaket.
4. PHP-Prozesse neu starten und den Patch-Stand danach erneut kontrollieren.
5. PHP 8.1 und älter ersetzen oder das System bis zur Umstellung vom Netz nehmen.
6. Logs ab dem 17. Oktober prüfen auf Fehlerhäufungen, verdächtige Anfragen und unbekannte Dateien.
7. Verantwortung festlegen: Wer kümmert sich beim nächsten kritischen Update, und bis wann?

Fazit: Die PHP-Sicherheitslücke ist ernst, aber beherrschbar

PHP2Shell gehört zu den kritischsten Lücken der letzten Jahre, weil sie fast jede PHP-basierte Website trifft und ohne Anmeldung ausgenutzt werden kann. Die gute Nachricht: Die Lösung ist bekannt und in den meisten Fällen schnell umgesetzt.

Die wichtigsten Punkte noch einmal:

• Die PHP-Sicherheitslücke steckt im PHP-Kern, nicht in Plugins. Aktuelle WordPress-Plugins schützen nicht.
• Sicher sind PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder gepatchte Distributionspakete.
• Nach dem Update PHP-Prozesse neu starten, sonst läuft der alte Code weiter.
• PHP 8.1 und älter bekommen kein offizielles Update und gehören ersetzt.
• Prüfe Deine Systeme ab dem 17. Oktober auf Spuren eines Angriffs.

Nimm Dir heute zehn Minuten, prüf Deine PHP-Version und hol Dir eine schriftliche Bestätigung Deines Hosters. Wenn Du dabei Unterstützung brauchst oder Deine Websites dauerhaft in sicheren Händen wissen willst, hilft Dir unser Team für Cyber Security. Für den Wechsel auf eine aktuelle PHP-Version samt WordPress-Pflege unterstützen Dich unsere Kolleginnen und Kollegen aus der WordPress-Entwicklung.

Jetzt Erstgespräch anfragen und gemeinsam klären, wo Du stehst.