PHP-Sicherheitslücke PHP2Shell: Was Website-Betreiber jetzt tun sollten

Was ist passiert?

Am 21. Oktober 2026 um 16 Uhr deutscher Zeit hat das PHP-Projekt Sicherheitsupdates für alle noch unterstützten PHP-Zweige veröffentlicht. Sie beheben zwei Fehler, die unter dem Namen PHP2Shell bekannt geworden sind: CVE-2026-109618 und CVE-2026-109619. Beide sind mit 9,2 von 10 Punkten bewertet und ermöglichen laut PHP-Projekt, dass ein Unbekannter aus der Ferne Programmcode auf dem Server ausführt, ohne sich anzumelden.

Eigentlich war die Veröffentlichung für den 22. Oktober geplant. Wegen eines Lecks wurde sie einen Tag vorgezogen. Nach Angaben von Amazon gab es bereits am 17. Oktober einen ersten Angriffsversuch. Am 20. Oktober wurden die Lücken öffentlich bekannt, kurz darauf kursierten Exploit-Codes, und nach dem Patch zählte Cloudflare nach eigenen Angaben Millionen Zugriffsversuche. Die Sicherheitsfirma watchTowr schreibt allerdings, dass keiner der öffentlichen Exploits bisher Code ausführen kann: Sie funktionieren nicht, messen nur Zeitunterschiede oder bringen den Zielserver zum Absturz. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft die Lage mit „Kritikalität 3 / Orange“ ein. Die US-Behörde CISA schreibt, dass sie zum Zeitpunkt ihrer Meldung keine Ausnutzung beobachtet hatte.

Mein Fazit: Kein Grund zur Panik, aber auch keiner zum Abwarten. Dass die Angriffe heute oft noch scheitern, hilft dir nicht, wenn morgen ein funktionierender Exploit kursiert.

Was die Lücken bedeuten

Der Fehler steckt in PHP selbst und nicht in deiner Website. Die Entdecker konnten ihn sogar gegen ein einfaches „Hello World“-Programm auf einer verwundbaren PHP-Version demonstrieren. Deine Seite kann also sauber programmiert sein und ist trotzdem betroffen.

• CVE-2026-109618 betrifft den Umgang mit knappem Arbeitsspeicher. Geht PHP mitten in einer Anfrage der Speicher aus, kann es mit halb vorbereiteten Daten weiterarbeiten und beim Aufräumen Ungültiges als gültig behandeln.
• CVE-2026-109619 betrifft Reste aus einer früheren Anfrage. Ein Zustand überlebt, obwohl der Speicher dahinter schon freigegeben wurde, und eine spätere Anfrage am selben Worker kann darauf zugreifen.

Betroffen sind laut PHP-Projekt alle PHP-Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das Risiko schätzt das Projekt bei mod_php am höchsten ein. Die Sicherheitslücken stecken nach Angaben des PHP-Teams in allen PHP-Versionen seit PHP 5. Docker-Images mit PHP und Geräte-Firmware mit PHP brauchen ebenfalls ein neues Paket vom Hersteller.

Bin ich betroffen?

Wenn deine Website mit PHP läuft, ja, solange der Server noch nicht aktualisiert wurde. Das gilt für WordPress, Joomla, TYPO3, Shopware, Drupal und für jede selbst geschriebene PHP-Anwendung. Websites, die statisch ausgeliefert werden oder mit anderen Techniken wie Node.js laufen, sind von dieser PHP-Lücke nicht betroffen.

Die PHP-Version findest du in WordPress unter Werkzeuge → Website-Zustand → Info → Server. Bei vielen Hostern steht sie auch im Kundenmenü. Das hier ist die Tabelle zum Abgleichen:

Auf Version 8.1 und älter gibt es vom PHP-Projekt keine offizielle Version mehr. Es gibt nur Quelltext-Korrekturen für 7.4, 8.0 und 8.1 für alle, die selbst bauen, und manche Linux-Distributionen und Hoster liefern die Korrektur selbst nach. Wenn du dazu nichts von deinem Hoster hörst: nachfragen oder umziehen.

Was du in welcher Reihenfolge tun solltest

1. Hoster prüfen. Viele Anbieter patchen selbst oder haben Schutzregeln (WAF) vorgeschaltet. Schau in die Wartungsmeldungen oder frag nach, ob und wann die Korrektur eingespielt wird. Wer sein Hosting selbst verwaltet, kommt am eigenen Handeln nicht vorbei.
2. PHP aktualisieren auf mindestens 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wer ohnehin wechseln muss, geht lieber gleich auf 8.4 oder 8.5, weil 8.2 am 31. Dezember 2026 aus dem Sicherheitssupport fällt.
3. Alle PHP-Prozesse neu starten. Ohne Neustart läuft die alte Version weiter im Speicher. Bei Managed-Hosting übernimmt das der Anbieter, bei eigenem Server (PHP-FPM, Apache) musst du es anstoßen.
4. Die Seite testen. Startseite, Kontaktformular, Login, Shop und Bezahlvorgang. Ältere Plugins und Themes laufen auf neuen PHP-Versionen manchmal nicht mehr sauber. Mach vorher ein Backup.
5. Zugangsdaten erneuern, wenn die Seite in den letzten Tagen offen erreichbar war: WordPress-Administratoren, Datenbank, FTP/SSH und API-Schlüssel. Das ist Vorsicht, kein Beweis für einen Einbruch.
6. Auf Auffälligkeiten achten. Unbekannte PHP-Dateien, neue Administratoren, fremde Cron-Jobs. Die CISA nennt als Warnsignal PHP-Prozesse, die Shells starten oder Programme herunterladen.

Und WordPress?

WordPress.org stellt klar: Die Lücken sind nicht WordPress-spezifisch, und es ist kein WordPress-Update nötig oder geplant. Wer hier nur auf „Update“ im Dashboard klickt, schließt sie also nicht. Das PHP-Update auf dem Server ist der entscheidende Schritt.

Davon unabhängig lohnt der Blick aufs Dashboard: Am 6. Oktober hat WordPress mit Version 7.1.3 eine Sicherheits- und Wartungsversion mit sieben Sicherheitskorrekturen veröffentlicht und empfiehlt, sie sofort einzuspielen. Und wenn du PHP wechselst, muss die WordPress-Version dazu passen. Das Hosting-Handbuch von WordPress.org führt WordPress 7.0 und 7.1 mit PHP 8.2 bis 8.5 auf, WordPress 6.9 mit PHP 8.1 bis 8.5. Plugins und Themes solltest du vorher auf ihre Eignung prüfen.

Wenn du nicht sofort aktualisieren kannst

Die Empfehlung ist eindeutig: aktualisieren. Das PHP-Projekt sagt selbst, dass es keine vollständige Schutzmaßnahme außer dem Update gibt. Für den Fall, dass es nicht sofort geht, nennt es Einstellungen, die einzelne Angriffswege erschweren, ohne eine Installation sicher zu machen. Das ist ein Werkzeug für Administratoren und kein Ersatz:

• memory_limit=-1, nach Möglichkeit so gesetzt, dass Anwendungen es nicht überschreiben können (CVE-2026-109618).
• Ein niedriges post_max_size, etwa 8 MB ohne Datei-Uploads und 32 MB mit (CVE-2026-109618).
• session.upload_progress.enabled=0 und danach alle Worker neu starten (CVE-2026-109619).

Dazu kommen Schutzregeln einer Web Application Firewall. Cloudflare hat solche Regeln veröffentlicht, auch für die kostenlose Variante, bezeichnet sie aber selbst als vorübergehenden Flicken. Wer nicht sofort aktualisieren kann oder noch PHP 8.1 oder älter nutzt, soll laut CISA das System vom Netz nehmen, bis die Korrektur da ist.

Was ein Update nicht beantwortet

Das Update schließt die Lücke ab dem Moment, in dem es läuft. Es sagt nichts darüber, ob jemand in den Tagen davor schon auf deinem Server war. Das BSI schreibt, dass es noch keine verbindlichen Erkennungsmerkmale gibt. Ich kann deine Seite auf die offensichtlichen Spuren durchsehen, also unbekannte Dateien, Benutzer und Aufgaben. Eine forensische Untersuchung ist das nicht, und ich sage dir offen, wenn mehr nötig ist.

Wenn du Hilfe möchtest

Du musst das nicht selbst machen. Ich prüfe deine PHP-Version, aktualisiere PHP und WordPress, teste die Seite, erneuere Zugangsdaten und sehe nach Auffälligkeiten. Vorher bekommst du ein schriftliches Angebot mit festem Preis. Und wenn dein Hoster alles schon erledigt hat, sage ich dir das ehrlich im Erstgespräch.

Quellen, Stand 22. Oktober 2026

Dieser Artikel fasst die Veröffentlichungen unten zusammen. Die Lage entwickelt sich noch. Im Zweifel gilt die Meldung des PHP-Projekts.

• PHP-Projekt: Security advisory (php.net)Fixversionen, betroffene Server-Varianten, Zwischenlösungen
• WordPress.org: Critical PHP Security ReleaseEinordnung für WordPress, PHP-Version in Website-Zustand prüfen
• BSI: Cybersicherheitswarnung zu PHPKritikalität 3 / Orange, Hinweise zu WAF und Containern
• CISA: Critical Vulnerabilities in PHP Require Immediate PatchingEmpfehlung der US-Behörde, auch zu PHP 8.1 und älter
• heise online: php2shell – Kritische Sicherheitslücken in PHPTechnische Einordnung auf Deutsch
• SecurityWeek: PHP2Shell Exploitation Started Days Before PatchesBeobachtete Angriffsversuche (Amazon, Cloudflare, watchTowr)
• php.net: Supported VersionsSupport-Enden der PHP-Versionen