PHP-Sicherheitslücken „php2shell“: Was Website-Betreiber jetzt tun müssen

Kurz gesagt: Die Lücken CVE-2026-109618 und CVE-2026-109619 betreffen alle PHP-Installationen, die Webanfragen verarbeiten. Abgesichert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Prüfen Sie Ihre PHP-Version und aktualisieren Sie umgehend, oder lassen Sie Ihren Hoster bestätigen, dass die Korrekturen eingespielt sind. Konfigurationsänderungen verringern das Risiko nur, schließen die Lücken aber nicht.

Was ist passiert?

Das PHP-Projekt hat am 21. Oktober 2026 eine Sicherheitswarnung mit dem Titel „Critical remote code execution vulnerabilities, update now“ veröffentlicht. Behoben werden zwei Schwachstellen, die in Fachkreisen unter dem Namen „php2shell“ diskutiert werden. Beide sind als kritisch eingestuft, mit einem CVSS-4.0-Wert von 9,2 von 10.

• CVE-2026-109618 („RCE via OOM corruption“): Gerät PHP bei der Verarbeitung einer Anfrage an die Speichergrenze, kann es interne Daten in einem unvollständigen Zustand zurücklassen. Beim Aufräumen der Anfrage werden diese Daten trotzdem verwendet. Ausgelöst werden kann das zum Beispiel über speziell präparierte Formular- oder Datei-Uploads.
• CVE-2026-109619 („RCE via stale global state“): Interne Zustände einer Anfrage können erhalten bleiben, obwohl ihr Speicher schon freigegeben wurde. Eine spätere Anfrage, die vom selben PHP-Prozess bearbeitet wird, kann diese veralteten Daten nutzen.

In beiden Fällen kann ein Angreifer im ungünstigsten Fall eigenen Code auf dem Server ausführen, ohne Benutzerkonto und ohne Zutun eines Website-Besuchers. Sicherheitsforscher berichten bereits von Angriffsversuchen; wie verbreitet erfolgreiche Angriffe sind, wird unterschiedlich eingeschätzt.

Welche PHP-Versionen sind betroffen?

Betroffen sind alle unterstützten PHP-Versionen vor den Sicherheits-Releases vom 21. Oktober 2026 sowie ältere Versionen ohne entsprechende Korrektur:

Für PHP 8.1, 8.0 und 7.4 hat das PHP-Sicherheitsteam wegen der Schwere der Lücken ausnahmsweise minimale Quellcode-Korrekturen bereitgestellt. Die Versionsnummer ändert sich dabei nicht. Ob eine solche Installation abgesichert ist, kann daher nur Ihr Hoster oder Ihr Distributor bestätigen.

Wer ist betroffen?

Laut PHP-Projekt sind alle PHP-Installationen betroffen, die Webanfragen verarbeiten, egal ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. Das höchste Risiko sieht das PHP-Team bei Apache mit mod_php: Hier wurde ein Angriff demonstriert, der greift, bevor überhaupt Code Ihrer Website ausgeführt wird.

Wichtig: Die Lücken stecken in PHP selbst, nicht in Ihrem Content-Management-System. Auch eine perfekt gepflegte TYPO3- oder WordPress-Installation ist angreifbar, wenn das darunterliegende PHP nicht aktualisiert wurde. Ein Update des CMS allein hilft hier nicht.

Was sollten Sie jetzt tun?

1. PHP-Version herausfinden: Im Kundenmenü Ihres Hosters, in TYPO3 unter „Umgebung“ bzw. im Install-Tool, in WordPress unter „Werkzeuge → Website-Zustand“. Legen Sie keine öffentlich erreichbare phpinfo()-Datei ab.
2. Auf eine abgesicherte Version aktualisieren: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder neuer. Bei Shared Hosting oder Managed Servern übernimmt das der Hoster; lassen Sie sich die Aktualisierung schriftlich bestätigen.
3. Alle PHP-Prozesse neu starten: Ein Update wirkt erst, wenn PHP-FPM bzw. Apache neu gestartet wurden.
4. Alte PHP-Versionen ablösen: Läuft Ihre Website noch mit PHP 8.1 oder älter, ist jetzt der richtige Zeitpunkt für ein Upgrade. Das erfordert oft auch ein Update Ihres CMS. Mehr dazu auf der Seite TYPO3 Upgrade auf v14.
5. Auf Auffälligkeiten prüfen: Unbekannte Dateien im Webverzeichnis, neue Administrator-Konten, ungewöhnliche Weiterleitungen oder Spam-Versand können auf einen erfolgreichen Angriff hindeuten. Im Zweifel: Zugangsdaten ändern und die Installation von Fachleuten prüfen lassen.

Übergangslösungen, wenn ein Update nicht sofort möglich ist

Das PHP-Projekt betont ausdrücklich: Nur ein Update schließt die Lücken vollständig. Bis dahin verringern diese Einstellungen das Risiko für bekannte Angriffswege. Sie sollten nur von Fachleuten und nur serverseitig gesetzt werden (php.ini, FPM-Pool oder Server-Konfiguration, nicht per ini_set() oder .user.ini):

• Gegen CVE-2026-109618: memory_limit=-1 administrativ erzwingen, post_max_size niedrig halten (z. B. 8M ohne Datei-Uploads) und Anfragegrößen zusätzlich am Webserver oder Proxy begrenzen. Achtung: Das hebt PHP-eigene Speichergrenzen auf und verlagert das Risiko auf die Verfügbarkeit.
• Gegen CVE-2026-109619: session.upload_progress.enabled=0 setzen und alle PHP-Prozesse neu starten; unter PHP 8.5 zusätzlich fatal_error_backtraces=0. Veraltete oder ungültige PHP-Einstellungen, die Warnungen erzeugen, entfernen.

Das Ausblenden von Fehlermeldungen (error_reporting, display_errors) schützt laut PHP-Projekt nicht.

Nachtrag vom 23. Oktober 2026

Das PHP-Projekt empfiehlt zusätzlich, session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release zu setzen. Hintergrund ist ein weiterer, laut PHP-Team in der Praxis unwahrscheinlicher Angriffsweg (CVE-2026-115560), der nur bei einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode auftritt. Wer die Einstellung bereits gesetzt hat, muss nichts weiter tun.

Was bedeutet das für TYPO3- und WordPress-Websites?

Für die Sicherheit Ihrer Website zählt die PHP-Version auf dem Server. Problematisch wird es vor allem bei älteren Installationen: Alte TYPO3- oder WordPress-Versionen laufen oft nur mit alten PHP-Versionen, für die es keine offiziellen Korrekturen mehr gibt. Dann reicht ein PHP-Update allein nicht. Das CMS muss mit aktualisiert werden. Welche TYPO3-Version welche PHP-Versionen unterstützt, sehen Sie in der Live-Übersicht auf meiner TYPO3-Seite.

Langfristig schützt am besten eine laufende Wartung mit festen Update-Zyklen und ein Hosting, bei dem Sicherheitsupdates für PHP zeitnah eingespielt werden.

Quellen

• PHP-Projekt: Sicherheitswarnung und Release-Ankündigungen vom 21. und 23. Oktober 2026 auf php.net
• Sicherheitshinweis GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• Sicherheitshinweis GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)

Dieser Artikel gibt den Stand vom 25. Oktober 2026 wieder. Bei neuen Erkenntnissen aktualisiere ich ihn.