PHP2Shell: Ist Ihre Website von der PHP-Lücke betroffen?

Stand 22.10.2026, nachgesehen in der Sicherheitsmeldung auf php.net und in der Warnung des BSI. Die Lage ändert sich gerade von Tag zu Tag.

Was passiert ist

PHP ist die Programmiersprache, in der ein großer Teil aller Websites läuft. Sie arbeitet auf dem Server, nicht im Browser Ihrer Besucher. Die beiden Lücken (CVE-2026-109618 und CVE-2026-109619) stecken in PHP selbst, eine Ebene unter WordPress oder Ihrem Shop. Betroffen sind alle PHP-Versionen ab 5.4, und zwar in jeder üblichen Betriebsart auf dem Webserver. Ein Angreifer braucht dafür kein Konto auf Ihrer Seite.

Eigentlich sollten die Einzelheiten erst mit dem Update öffentlich werden. Erste Details sickerten am 20. Oktober durch, einen Tag vorher. Einen Angriffsversuch hat Amazon schon am 17. Oktober beobachtet, seit dem 21. melden mehrere Sicherheitsfirmen laufende Angriffe. Behörden in den Niederlanden, Frankreich und Finnland haben Seiten vorsorglich vom Netz genommen, bis das Update eingespielt war. Das BSI hat am 21. Oktober gewarnt.

Ist Ihre Website betroffen?

Das hängt davon ab, worauf sie läuft und wer den Server betreibt.

• WordPress, Joomla, TYPO3, Contao, Shopware oder WooCommerce bei einem Webhoster: betroffen, solange dort eine alte PHP-Version läuft. Das Update auf dem Server spielt der Hoster ein, nicht Sie.
• Eigener Server, also ein gemieteter vServer oder ein Rechner im Haus, auf dem PHP läuft (etwa für eine eigene Nextcloud): Hier sind Sie selbst der Hoster. Dazu weiter unten mehr.
• Baukasten-Dienste wie Wix, Jimdo oder Squarespace: Den Server betreibt der Anbieter. Sie können dort nichts aktualisieren und müssen es auch nicht.
• Statische Website aus fertigen HTML-Dateien: Der Server führt kein PHP aus, die Lücke greift nicht. Mit einer Einschränkung, die oft übersehen wird.

Die Einschränkung ist die vergessene Installation. Auf vielen Webspaces liegt mehr als die eigentliche Website: die Testkopie von damals unter /alt oder /test, ein altes Formular-Skript, eine Bildergalerie aus den Zehnerjahren. Läuft dort PHP, ist auch das ein Einfallstor, denn ein Angreifer braucht nur eine einzige Datei, die PHP ausführt. Der Hoster schließt die Lücke für alle diese Ordner mit, aber nur in den PHP-Versionen, die er tatsächlich korrigiert hat. Hängt die alte Testseite noch an PHP 7.2, für das es keine Korrektur gibt, bleibt sie in aller Regel offen.

So finden Sie die PHP-Version heraus

In WordPress dauert das eine Minute: im Menü links auf Werkzeuge, dann Website-Zustand, oben der Reiter Bericht. Unter dem Punkt Server steht die PHP-Version. Für andere Systeme, und um alle Domains auf einmal zu sehen, schauen Sie ins Kundenmenü Ihres Hosters, meist unter einem Punkt wie „PHP-Version“ oder „PHP-Einstellungen“. Dort sehen Sie auch, ob einzelne Domains oder Unterordner eine andere Version nutzen.

Sicher sind diese Fassungen und alles, was danach kam:

Eine Einschränkung gibt es auch hier. Manche Server bekommen die Korrektur als Paket ihres Linux-Systems. Dort bleibt die Versionsnummer oft unverändert, obwohl der Fix drin ist. Eine ältere Nummer heißt also nicht sicher, dass die Lücke offen ist. Sie heißt, dass Sie nachfragen müssen.

Was Ihr Hoster tun muss und was Sie ihn fragen

Bei einem gemieteten Webspace liegt das Update beim Hoster. Er muss PHP auf eine korrigierte Fassung bringen und danach die laufenden PHP-Prozesse neu starten. Erst dann ist der alte Code wirklich aus dem Speicher. Ob das erledigt ist, steht oft auf seiner Statusseite oder in einer Kundenmail. Steht dort nichts Konkretes, schreiben Sie dem Kundendienst kurz, zum Beispiel:

• Läuft PHP auf meinem Paket inzwischen in einer Fassung, die CVE-2026-109618 und CVE-2026-109619 behebt?
• Gilt das für alle PHP-Versionen, die ich in meinem Paket auswählen kann, auch für die älteren?
• Wann genau wurde das Update eingespielt? (Das Datum brauchen Sie für den nächsten Schritt.)

Ihre Seite läuft noch auf PHP 7.4, 8.0 oder 8.1?

Dann haben Sie das eigentliche Problem. Für diese Reihen gibt das PHP-Projekt kein fertiges Update heraus, nur Korrekturen im Quelltext für alle, die PHP selbst bauen. Einzelne Hoster und Linux-Anbieter liefern so etwas nach. Verlassen sollten Sie sich darauf nicht. Für alles vor 7.4 gibt es gar nichts mehr.

Der Weg ist der Wechsel auf eine aktuelle Reihe. Bei den meisten Hostern ist das ein Auswahlfeld im Kundenmenü, der Klick ist schnell gemacht. Das Risiko liegt woanders: Alte Plugins und Themes, die seit Jahren kein Update bekommen haben, laufen auf neuem PHP manchmal nicht mehr. Dann zeigt die Seite einen weißen Bildschirm oder eine Fehlermeldung. Deshalb in dieser Reihenfolge:

1. Eine vollständige Sicherung ziehen, Dateien und Datenbank. Viele Hoster bieten das im Kundenmenü an.
2. WordPress, Theme und Plugins aktualisieren. Was nicht mehr gepflegt wird, ersetzen oder entfernen.
3. Erst dann die PHP-Version umstellen und die Seite durchklicken: Startseite, Kontaktformular, die Kasse, falls es einen Shop gibt.
4. Klemmt etwas, lässt sich die Version im selben Menü zurückstellen. Das ist aber ein Aufschub für Stunden, nicht für Wochen, denn die alte Version bleibt offen.

Welche Version? Mindestens 8.3, besser 8.4. Die 8.2 ist zwar korrigiert, bekommt aber ab dem 31. Dezember 2026 keine Sicherheitsupdates mehr. Wer ohnehin umstellt, spart sich so den zweiten Umzug in zehn Wochen.

Nach dem Update: nachsehen, ob jemand drin war

Das Update schließt die Tür. Wer vorher hereingekommen ist, bleibt davon unberührt. Nachsehen sollte man deshalb für die Zeit ab dem 17. Oktober, dem Tag des ersten beobachteten Angriffsversuchs, und nicht erst ab dem Update. Bei einer WordPress-Seite können Sie einiges selbst prüfen:

• Unter Benutzer: Gibt es Administratoren, die Sie nicht kennen?
• Unter Plugins: Steht dort etwas, das niemand von Ihnen installiert hat?
• Leitet die Seite Besucher auf fremde Adressen um? Das passiert oft nur auf dem Handy oder nur, wer aus der Google-Suche kommt.
• Zeigt Google bei der Suche nach Ihrer Domain Seiten, die es bei Ihnen nicht gibt? Spam auf Englisch oder Japanisch ist der Klassiker.

Allerdings hinterlässt ein geschickter Angreifer nichts davon. Unauffällig heißt also nicht sauber. Wer es genau wissen will, lässt die Dateien auf dem Server mit einer Sicherung von vor dem 17. Oktober vergleichen oder mit den Originalpaketen von WordPress und den Plugins.

Danach, und wirklich erst danach, die Passwörter wechseln. Wer PHP auf Ihrem Server ausführen konnte, kam an alles, was dort gespeichert ist: das Datenbank-Passwort aus der Konfigurationsdatei, die Zugänge der WordPress-Administratoren, den FTP- oder SFTP-Zugang und die Schlüssel, die in Plugins hinterlegt sind (Mailversand, Zahlungsanbieter, Schnittstellen zur Warenwirtschaft). Wer vor dem Update wechselt, liefert einem Angreifer, der noch drin ist, die neuen Passwörter gleich mit.

Und noch etwas, das leicht untergeht: Löschen Sie jetzt keine Sicherung von vor dem 17. Oktober. Viele Sicherungen rotieren und werfen nach 14 oder 30 Tagen die ältesten weg. Fällt in drei Wochen auf, dass doch jemand drin war, ist genau diese Kopie die, die mit großer Wahrscheinlichkeit sauber ist. Wie eine Sicherung aufgebaut sein sollte, steht im Ratgeber zur 3-2-1-Regel.

Eigener Server, Nextcloud oder Verwaltungsoberfläche

Wer PHP selbst betreibt, auf einem gemieteten vServer, einem Server im Haus oder für eine eigene Nextcloud, ist sein eigener Hoster. Die Aufgabe lautet dann: Pakete aktualisieren, PHP-FPM oder Apache neu starten und prüfen, ob die korrigierte Fassung wirklich läuft. Die großen Linux-Distributionen haben die Korrekturen vorab bekommen; ob Ihr Paket sie enthält, steht in der Sicherheitsmeldung Ihrer Distribution. Die Versionsnummer allein sagt es nicht (siehe oben).

Läuft PHP in einem Container, steckt es im Abbild. Ein Neustart reicht dann nicht, das Abbild muss neu gezogen oder neu gebaut werden. Verwaltungsoberflächen wie Plesk oder cPanel und manche Geräte bringen ein eigenes PHP mit, dort kommt das Update vom Hersteller.

Bis das Update läuft, nennt das PHP-Projekt Einstellungen, die das Risiko senken, unter anderem:

Die vollständige Liste steht in der Sicherheitsmeldung auf php.net. Das PHP-Projekt sagt selbst dazu: Vollständig schützt nur das Update.

Was Sie selbst machen können

Das Nachsehen und das Nachfragen schaffen die meisten selbst, und dafür braucht niemand eine Rechnung von uns. Zu uns kommt man meist in zwei Fällen. Die Seite läuft noch auf PHP 7.4 oder 8.1, und der Wechsel bricht Plugins. Oder niemand hat mehr die Zugänge zum Hoster (häufiger, als man denkt, gerade wenn die Seite vor Jahren jemand anders gebaut hat). Gibt es Anzeichen, dass jemand drin war, sowieso. Was eine Stunde kostet, steht auf der Preisseite.

Häufige Fragen