Stand: 26.10.2026. Bei allen Hostern, die ich für meine Kunden geprüft habe, ist die Korrektur inzwischen eingespielt. Es gibt Millionen Angriffsversuche, und am 26. Oktober wurde der erste erfolgreiche Angriff bestätigt, auf einen Testserver von Sicherheitsforschern mit nicht korrigiertem PHP. Eine Ausnutzung in der Breite ist dem BSI bisher nicht bekannt. Erste Angriffsversuche gab es schon vor der Korrektur. Wichtig sind deshalb jetzt zwei Dinge: die Korrektur bestätigen lassen und nach Spuren eines Einbruchs sehen. Was hinter der Lücke steckt, erkläre ich im Ratgeber PHP2Shell: Was die kritische PHP-Lücke bedeutet.
Die PHP-Version herausfinden
Entscheidend ist die PHP-Version, mit der Ihre Website ausgeliefert wird. So finden Sie sie:
- 01
WordPress
Werkzeuge > Website-Zustand > Bericht, Abschnitt „Server“, Zeile „PHP-Version“. Dort steht die genaue Version, etwa 8.3.36.
- 02
Joomla
System > Systeminformationen, Zeile „PHP-Version“.
- 03
Shopware und andere
Im Kundenmenü des Hosters bei den PHP-Einstellungen der Domain. Dort steht oft nur die Hauptversion, etwa 8.3; die genaue Unterversion nennt Ihnen der Hoster.
Die Version auf der Kommandozeile (php -v), etwa über SSH, kann von der Version abweichen, mit der die Website läuft, auch bei Hosting-Paketen. Maßgeblich ist die des Webservers.
Mit den korrigierten Versionen vergleichen
Gleiche Nummer, trotzdem korrigiert
Viele Server nutzen nicht die Pakete des PHP-Projekts, sondern die ihrer Linux-Distribution oder eigene des Hosters. Diese bauen die Korrektur oft ein, ohne die Versionsnummer zu ändern: Ubuntu 24.04 zeigt vorher wie nachher 8.3.6, und bei Hostern habe ich korrigierte Fassungen gesehen, die weiter 8.3.35 oder 7.4.33 anzeigen. Eine ältere Nummer heißt also nicht sicher, dass die Website verwundbar ist. Ob Ihr Server die korrigierte Fassung nutzt, kann nur Ihr Hoster oder Administrator bestätigen.
Installiert heißt noch nicht wirksam
Eine korrigierte Version wirkt erst, wenn die PHP-Prozesse neu gestartet wurden. Fragen Sie im Zweifel auch danach.
Weitere Lücke seit dem 23. Oktober
Das PHP-Projekt hat eine weitere Lücke gemeldet (CVE-2026-115560), für die es noch keine Korrektur gibt; sie kommt mit der nächsten regulären PHP-Version. Ausnutzbar ist sie nur, wenn eine Anwendung eine bestimmte Sitzungseinstellung während der Laufzeit umstellt, laut PHP-Projekt ein unwahrscheinlicher Fall. Abhilfe schafft die Einstellung session.upload_progress.enabled = 0, die Ihr Hoster setzen kann.
| Ihre Hauptversion | Korrigiert ab |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 und älter | keine neue Version vom PHP-Projekt, Hoster fragen und umstellen (Schritt 05) |
Den Hoster fragen
Ist Ihre Version nicht eindeutig korrigiert, fragen Sie Ihren Hoster schriftlich, per Mail oder über das Kontaktformular im Kundenmenü. Diese Vorlage können Sie übernehmen; ersetzen Sie die Angaben in spitzen Klammern.
Betreff: PHP2Shell (CVE-2026-109618, CVE-2026-109619): Stand für <Ihre Domain> Guten Tag, zu den kritischen PHP-Lücken PHP2Shell (CVE-2026-109618 und CVE-2026-109619) bitte ich um eine kurze Bestätigung für meine Website <Ihre Domain>, Kundennummer <Ihre Kundennummer>: 1. Läuft die Website bereits mit einer korrigierten PHP-Version (8.5.12, 8.4.27, 8.3.36, 8.2.35 oder ein Paket mit eingebauter Korrektur), und wurden die PHP-Prozesse danach neu gestartet? 2. Falls nicht: Wann wird die Korrektur eingespielt? 3. Gibt es bis dahin eine Schutzmaßnahme auf Ihrer Seite? 4. Falls meine Website noch PHP 8.1 oder älter nutzt: Gibt es dafür eine Korrektur, oder soll ich auf eine neuere Version umstellen? Das BSI rät, Server ohne Korrektur vorübergehend vom Netz zu nehmen. Ich bitte daher um eine kurzfristige Antwort. Vielen Dank und freundliche Grüße <Ihr Name>
Noch keine Korrektur: die Website übergangsweise schützen
Solange Ihr Hoster die Korrektur nicht bestätigt hat, rät das BSI, Server vorübergehend vom Internet zu trennen. Diese Wege gibt es:
Wartungsseite ohne PHP
Der Webserver liefert für alle Adressen eine einfache HTML-Seite aus, PHP läuft gar nicht. Viele Hoster können eine Domain im Kundenmenü auf eine statische Seite umstellen oder übernehmen das für Sie. Für Shops und Websites mit Kundendaten halte ich diesen Weg für richtig, bis die Korrektur da ist. Suchmaschinen werten eine Wartungsseite mit dem Status 503 als vorübergehend.
Der Wartungsmodus von WordPress oder Shopware. Er wird selbst von PHP ausgeliefert, und die Lücke greift, bevor er aktiv wird.
Formular-Uploads am Webserver sperren
Die bekannten Angriffe nutzen Anfragen im Format multipart/form-data, wie sie Formulare mit Dateiupload senden. Wer diese Anfragen am Webserver ablehnt, bevor PHP sie sieht, hält die Website online, schließt aber nur den bekannten Weg. Dabei fallen Bild-Uploads im Backend, viele Kontaktformulare und manche Schritte im Bestellprozess aus. Testen Sie danach Formulare und Kasse.
Quelle: SansecCloudflare
Läuft Ihre Website bereits über Cloudflare, sind dort Regeln gegen die bekannten Angriffe aktiv, auch im kostenlosen Tarif. Cloudflare selbst nennt das eine Überbrückung bis zum Update.
Quelle: CloudflareBeides ist eine Überbrückung, keine Lösung. Schutz bietet erst die korrigierte PHP-Version.
PHP 8.1 oder älter: jetzt umstellen
PHP 8.1 und ältere Versionen bekommen vom PHP-Projekt keine neuen Versionen mehr. Für PHP 7.4 bis 8.1 hat es nur Korrekturen im Quellcode veröffentlicht, die manche Hoster und Linux-Distributionen eingebaut haben; für 7.3 und älter gibt es keine Korrektur. Fragen Sie Ihren Hoster, ob Ihre Version korrigiert ist. Dauerhaft sicher ist nur der Wechsel: Stellen Sie im Kundenmenü Ihres Hosters auf PHP 8.3 oder 8.4 um; PHP 8.2 wird nur noch bis Ende 2026 mit Sicherheitsupdates versorgt.
- 1Vorher eine Sicherung von Dateien und Datenbank anlegen.
- 2Im Kundenmenü auf PHP 8.3 oder 8.4 umstellen.
- 3Danach die wichtigsten Seiten, Formulare und bei Shops die Kasse prüfen.
Die alte Version ist kein Ausweg, denn sie bleibt verwundbar. Dann gehört bis zur Reparatur eine Wartungsseite ohne PHP davor. Am sichersten ist ein Wechsel, der vorher auf einer Kopie der Website getestet wurde.
Nach Spuren eines Einbruchs sehen
Laut Amazon gab es einen ersten Angriffsversuch schon am 17. Oktober, vier Tage bevor die Korrektur erschien. Eine Website, die inzwischen korrigiert ist, kann also schon vorher getroffen worden sein.
Neue Administrator-Konten
Konten, die niemand angelegt hat. In WordPress unter Benutzer, in Shopware unter Einstellungen > System > Benutzer.
PHP-Dateien im Upload-Ordner
Dort sollten nur Bilder und Dokumente liegen, bei WordPress in wp-content/uploads, bei Shopware in public/media.
Neue oder geänderte Dateien
Dateien, die seit dem 17. Oktober 2026 hinzugekommen sind oder sich verändert haben, ohne dass jemand etwas aktualisiert hat.
Unbekannte Cronjobs
Geplante Aufgaben im Kundenmenü des Hosters, die niemand eingerichtet hat.
Hinweise des Hosters
Mails über Spamversand, ungewöhnlich hohe Last oder einen Fund des Malware-Scanners.
- 1Die Website vom Netz nehmen, mit einer Wartungsseite ohne PHP.
- 2Eine Kopie von Dateien und Datenbank für die Analyse anlegen, nichts blind löschen.
- 3Alle Zugangsdaten ändern: Administratoren, Hosting-Kundenmenü, FTP und SSH, Datenbank, Schnittstellen und Zahlungsanbieter.
- 4Einen sauberen Stand aus einer Sicherung von vor dem 17. Oktober 2026 wiederherstellen und erst wieder online gehen, wenn PHP korrigiert ist.
Betroffen sein können Kundenkonten, Bestellungen oder Anfragen aus dem Kontaktformular. Das ist keine Rechtsberatung; im Zweifel klären Sie es mit Ihrem Datenschutzbeauftragten.
Ausführlich beschreibe ich das in den Ratgebern WordPress gehackt und Onlineshop gehackt.
Eigener Server: aktualisieren und neu starten
Betreiben Sie einen eigenen Server oder VPS, sind Sie oder Ihr Administrator für PHP zuständig.
- 01
Pakete aktualisieren
Über die Paketverwaltung Ihrer Distribution. Die korrigierten Pakete nennen die Sicherheitshinweise, etwa Ubuntu USN-8948-1, Debian 13 DSA-6574-1 und Debian 12 DLA-4848-1. Vergleichen Sie die Paketversion, nicht die PHP-Versionsnummer.
Ubuntu · Debian - 02
PHP-FPM und Apache neu starten
Erst danach läuft die korrigierte Fassung. Container mit PHP müssen neu gebaut werden.
- 03
Panels und fremde Paketquellen
Plesk, cPanel und andere Panels bringen eigene PHP-Pakete mit, die Sie über das Panel aktualisieren. Nicht jede fremde Paketquelle hatte die Korrektur am 21. Oktober schon.
Help Net Security - 04
Bis zum Update
session.upload_progress.enabled = 0 in der php.ini oder der FPM-Pool-Konfiguration verringert die Angriffsfläche, laut PHP-Projekt aber nur für einen Teil der Angriffswege. Über eine .user.ini wirkt die Einstellung nicht. Sie schützt auch vor der weiteren Lücke CVE-2026-115560 vom 23. Oktober; lassen Sie sie bis zur nächsten PHP-Version gesetzt.
PHP-Projekt · PHP-Projekt, 23.10.2026
Hilfe von mir
Wenn Sie das nicht selbst prüfen möchten, schreiben Sie mir oder rufen Sie an. Halten Sie dafür bitte die Zugangsdaten zu Ihrem Hosting-Kundenbereich bereit.
PHP-Stand prüfen
Ich finde heraus, mit welcher PHP-Version Ihre Website läuft und ob sie korrigiert ist.
Beim Hoster nachfragen
Ich kläre mit Ihrem Hoster, wann die Korrektur kommt und was bis dahin gilt.
Übergangsweise schützen
Fehlt die Korrektur noch, stelle ich eine Wartungsseite ohne PHP davor und nehme sie wieder weg, sobald sie eingespielt ist.
Spuren prüfen
Ich sehe nach neuen Konten, fremden Dateien und geplanten Aufgaben.
Mit dem Doppelgänger läuft Ihre Website zusätzlich als exakte Kopie auf einem eigenen Server in Deutschland. Jede Nacht wird jede Datei der Live-Website mit dem freigegebenen Stand abgeglichen, so fällt ein Einbruch früh auf. Einen Wechsel der PHP-Version teste ich auf der Kopie, bevor er live geht.
Quellen: PHP-Projekt, Sicherheitshinweis vom 21.10.2026 · BSI, IT-Sicherheitshinweis 2026-297981-1032, Version 1.2 vom 22.10.2026 · Sansec, PHP2Shell, aktualisiert am 22.10.2026 · Amazon Threat Intelligence, 21.10.2026 · watchTowr, PHP2Shell FAQ · Cloudflare, 21.10.2026 · Ubuntu, USN-8948-1 · Debian Security Tracker · Help Net Security, 21.10.2026 · PHP-Projekt, Hinweis zu CVE-2026-115560 vom 23.10.2026 · BleepingComputer, 26.10.2026
Kurz beantwortet.
Wie finde ich die PHP-Version meiner Website heraus?
In WordPress unter Werkzeuge > Website-Zustand > Bericht, im Abschnitt Server steht die PHP-Version. In Joomla unter System > Systeminformationen. Bei Shopware und anderen Systemen im Kundenmenü des Hosters bei den PHP-Einstellungen der Domain. Dort steht oft nur die Hauptversion wie 8.3; die genaue Unterversion nennt Ihnen der Hoster.
Meine Website zeigt PHP 8.3.6. Ist sie ungeschützt?
Nicht unbedingt. Viele Server nutzen PHP-Pakete ihrer Linux-Distribution, etwa Ubuntu oder Debian, oder eigene Pakete des Hosters. Die bauen die Korrektur in ihre Pakete ein, ohne die Versionsnummer zu ändern; Ubuntu 24.04 zeigt vorher wie nachher 8.3.6. Ob Ihr Server die korrigierte Fassung nutzt, kann nur Ihr Hoster oder Administrator bestätigen.
Hilft der Wartungsmodus von WordPress oder Shopware?
Nein. Beide Wartungsmodi werden von PHP ausgeliefert, und die Lücke greift, bevor WordPress oder Shopware starten. Schutz bietet übergangsweise nur eine Wartungsseite, die der Webserver ohne PHP ausliefert. Viele Hoster können eine Domain im Kundenmenü auf eine einfache HTML-Seite umstellen oder das für Sie übernehmen.
Soll ich meine Website vom Netz nehmen?
Wenn Ihr Hoster die Korrektur noch nicht bestätigt hat, rät das BSI, Server vorübergehend vom Internet zu trennen. Für Onlineshops und Websites mit Kundenkonten oder Formularen mit personenbezogenen Daten halte ich das für den richtigen Weg, bis die Korrektur eingespielt ist. Eine Wartungsseite mit dem Status 503 werten Suchmaschinen als vorübergehend.
Meine Website läuft noch mit PHP 8.1 oder älter. Was jetzt?
Fragen Sie Ihren Hoster, ob er Ihre Version selbst korrigiert hat; manche Hoster haben das getan. Dauerhaft sicher ist nur der Wechsel auf PHP 8.3 oder 8.4 im Kundenmenü Ihres Hosters. Diese Versionen sind korrigiert und werden weiter gepflegt. Legen Sie vorher eine Sicherung an und prüfen Sie danach die wichtigsten Seiten, Formulare und bei Shops die Kasse. Läuft die Website mit der neuen Version nicht, ist der Weg zurück auf die alte Version keine Lösung, denn sie bleibt verwundbar; dann gehört bis zur Reparatur eine Wartungsseite ohne PHP davor.
Woran erkenne ich, dass meine Website schon angegriffen wurde?
Typische Anzeichen sind neue Administrator-Konten, die niemand angelegt hat, PHP-Dateien im Upload-Ordner, wo nur Bilder liegen sollten, unbekannte geplante Aufgaben (Cronjobs) im Kundenmenü und Hinweise des Hosters auf Spamversand oder Schadsoftware. Was Sie bei einem Fund tun, steht in den Ratgebern WordPress gehackt und Onlineshop gehackt.
Muss ich einen Einbruch der Datenschutzbehörde melden?
Wenn personenbezogene Daten betroffen sein können, etwa Kundenkonten, Bestellungen oder Anfragen aus dem Kontaktformular, in der Regel ja: binnen 72 Stunden, nachdem Sie davon erfahren haben (Art. 33 DSGVO), es sei denn, ein Risiko für die Betroffenen ist unwahrscheinlich. Das ist keine Rechtsberatung; im Zweifel klären Sie es mit Ihrem Datenschutzbeauftragten.