Kritische PHP-Sicherheitslücke „PHP2Shell“ (CVE-2026-109618 / CVE-2026-109619): Unsere Server sind gepatcht – das müssen Sie jetzt wissen

Stand: 22. Oktober 2026

Kurzfassung

• Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken (CVSS 9,2 von 10) veröffentlicht, die Codeausführung aus der Ferne ohne Anmeldung ermöglichen. Sie werden unter dem Namen PHP2Shell zusammengefasst.
• Betroffen ist die PHP-Laufzeit selbst, nicht eine einzelne Anwendung. Auch eine einfache „Hello World“-Seite kann betroffen sein. WordPress, Shopware, Magento, Joomla, Laravel, TYPO3 und Nextcloud nutzen PHP.
• Die Lücken sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Für die nicht mehr unterstützten Versionen 8.1, 8.0 und 7.4 gibt es Backports, also auf ältere Versionen übertragene Sicherheitskorrekturen.
• Alle Hosting-Server von WEB-SHOP-HOSTING wurden am 21. Oktober 2026 aktualisiert. Alle bei uns eingesetzten PHP-Versionen von 8.0 bis 8.5 sind gepatcht, alle PHP-FPM-Dienste wurden neu gestartet. Für dieses Sicherheitsupdate müssen Sie nichts tun.
• Wer eigene Server betreibt (vServer, Root-Server, Docker), sollte umgehend aktualisieren. Konfigurationsänderungen allein reichen nicht aus.

Was ist passiert?

Am 20. Oktober kündigte das PHP-Projekt eine „kritische Sicherheitsveröffentlichung“ an. Am 21. Oktober um 14:00 UTC erschienen die Patches zusammen mit der Sicherheitsmeldung. Entdeckt und gemeldet wurden die Lücken von Forschern bei Wiz, Calif und OpenAI.

Es handelt sich um zwei Fehler im PHP-Kern:

1. CVE-2026-109618 – RCE über Speicherkorruption bei Out-of-Memory (GHSA-w8hw-w9fx-j79w). Erreicht PHP während der Anfrageverarbeitung eine Speichergrenze, kann die Verarbeitung an einer Stelle unterbrochen werden, an der interne Daten nur teilweise initialisiert sind. Die anschließende Aufräumroutine behandelt diese ungültigen Daten als gültig.
2. CVE-2026-109619 – RCE über veralteten globalen Zustand (GHSA-6wmf-4rv5-p3rp). Der interne Zustand einer Anfrage kann erhalten bleiben, nachdem der zugehörige Speicher freigegeben wurde. Eine spätere Anfrage desselben Worker-Prozesses kann diesen veralteten Zustand verwenden, bevor die reguläre Initialisierung ihn zurücksetzt.

Beide Lücken ermöglichen Angreifern, ohne Zugangsdaten Code auf dem Server auszuführen. Zusätzlich lässt sich Speicher des PHP-Workers auslesen. Darin können Passwörter, Session-Tokens, API-Schlüssel und Zertifikate aus anderen Anfragen liegen.

Das PHP-Projekt stuft das Risiko bei Apache mod_php am höchsten ein: Hier wurde ein Exploit demonstriert, bei dem eine einzige nicht authentifizierte Anfrage den Angriff auslöst, bevor Anwendungscode ausgeführt wird. PHP-FPM, das wir einsetzen, verhält sich anders, weil der Worker bei frühen Fehlern beendet wird. Dennoch ist PHP-FPM laut PHP-Team für eine der beiden Lücken anfällig; für die zweite wurde Codeausführung unter PHP-FPM nachgewiesen.

Cloudflare meldete bereits am 21. Oktober erste Exploit-Versuche im Netz und stellte zusätzliche Regeln für seine Web Application Firewall (WAF) bereit.

Welche PHP-Versionen sind betroffen?

PHP 8.1 und älter erhalten vom PHP-Projekt keine regulären Updates mehr. PHP 8.2 erreicht am 31. Dezember 2026 das Ende des Unterstützungszeitraums (End of Life).

Status bei WEB-SHOP-HOSTING

Plesk hat die Patches am 21. Oktober für alle Versionen einschließlich der EOL-Zweige bereitgestellt. Unsere Server haben sie noch am selben Tag automatisch eingespielt. Für Kunden unseres Shared Hostings, SSD-Webhostings, CMS-Hostings, Shop-Hostings und Nextcloud-Hostings besteht hinsichtlich dieses Sicherheitsupdates kein Handlungsbedarf.

Was Sie trotzdem tun sollten

1. Prüfen Sie Ihre PHP-Version in Plesk unter Websites & Domains → PHP-Einstellungen. Wer noch PHP 8.0 oder 8.1 verwendet, ist bei uns zwar gepatcht, sollte aber auf PHP 8.3 oder 8.4 wechseln. Diese Zweige erhalten weiterhin reguläre Sicherheitsupdates.
2. Halten Sie Ihre Anwendung aktuell. Ein WordPress- oder Shop-Update ersetzt nicht das PHP-Update auf dem Server. Umgekehrt schützt ein PHP-Update nicht vor Sicherheitslücken in Plugins und Themes. Das WP Toolkit in Plesk zeigt ausstehende Updates an.
3. Erwägen Sie vorsorglich den Austausch sensibler Zugangsdaten, insbesondere von API-Schlüsseln und Tokens, die in PHP-Anwendungen verarbeitet werden. Ein bestätigter Angriff auf unsere Systeme liegt nicht vor; dies ist eine Vorsichtsmaßnahme.
4. Betreiben Sie einen eigenen Server? Beachten Sie die Hinweise im nächsten Abschnitt.

Anleitung für Betreiber eigener Server (vServer, Root-Server, Docker)

Nur eine gepatchte PHP-Laufzeit behebt diese Sicherheitslücken vollständig. Das PHP-Projekt selbst sagt: „ini settings won't save you.“

• Debian / Ubuntu: Führen Sie mit Administratorrechten apt update && apt upgrade aus. Prüfen Sie anhand der Hinweise Ihres Paketlieferanten, ob die verwendeten Paketquellen bereits korrigierte PHP-Pakete bereitstellen und diese tatsächlich installiert wurden. php -v zeigt die CLI-Version an. Starten Sie anschließend die betroffenen PHP-FPM-Dienste mit systemctl restart php8.x-fpm neu; php8.x-fpm steht hier als Platzhalter für den tatsächlichen Dienstnamen. Bei Apache mit mod_php verwenden Sie systemctl restart apache2.
• Plesk: Aktualisieren Sie die PHP-Komponenten unter Tools & Einstellungen → Updates. Alternativ können Sie mit plesk installer install-all-updates in der Shell alle verfügbaren Plesk-Updates einspielen. Plesk liefert auch Backports für 7.4/8.0/8.1.
• Docker: Bauen Sie das Image auf Basis von php:8.4.27-fpm beziehungsweise der entsprechenden FPM-Tags für 8.3.36 oder 8.2.35 neu und erstellen Sie die Container mit dem aktualisierten Image neu.
• Danach immer: Starten Sie alle betroffenen PHP-Prozesse neu – je nach Betriebsart PHP-FPM, Apache mit mod_php, FrankenPHP, LiteSpeed sowie gegebenenfalls Octane/RoadRunner-Worker. Bereits laufende Prozesse müssen die aktualisierte Laufzeit verwenden.

Wenn ein sofortiges Update unmöglich ist (vorübergehende Maßnahmen zur Risikoreduzierung, kein Ersatz für das Update):

• Prüfen Sie den Einsatz von memory_limit = -1 sorgfältig anhand der Herstellerhinweise und Ihrer Ressourcenbegrenzungen. Wenn Sie diese Einstellung verwenden, setzen Sie sie per php_admin_value im FPM-Pool beziehungsweise bei mod_php in der Apache-Konfiguration, damit Anwendungen sie nicht überschreiben können. Halten Sie post_max_size klein, beispielsweise 8M ohne Uploads oder 32M mit Uploads; upload_max_filesize sollte darunter liegen.
• Setzen Sie session.upload_progress.enabled = 0 zentral in der php.ini beziehungsweise der FPM-Pool-Konfiguration und starten Sie alle Worker neu. Verwenden Sie für diese serverweite Maßnahme nicht ini_set() oder eine dezentrale .user.ini.
• Setzen Sie unter PHP 8.5 zusätzlich fatal_error_backtraces = 0.
• Beschränken Sie den Zugang zu öffentlich erreichbaren PHP-Diensten oder schalten Sie eine WAF vor. Cloudflare hat dafür neue Managed Rules bereitgestellt.

Häufige Fragen

Bin ich betroffen, wenn meine Website nur statisch ist?
Eine rein statische Website ohne über das Web erreichbare PHP-Verarbeitung ist von diesen PHP-Lücken nicht betroffen. Ist PHP erreichbar – etwa über ein einzelnes Kontaktformular –, müssen Sie den Patchstand der Laufzeit prüfen.

Mein WordPress ist aktuell. Reicht das?
Nein. WordPress läuft auf PHP. Die Sicherheitslücken liegen in der PHP-Laufzeit, die vom Hosting-Server bereitgestellt wird. Bei uns ist das erforderliche PHP-Update bereits installiert.

Reicht es, session.upload_progress.enabled=0 zu setzen?
Nein. Diese Einstellung kursierte am 21. Oktober als vorübergehende Schutzmaßnahme. Die Sicherheitsfirma, die sie vorgeschlagen hatte, relativierte ihre Empfehlung noch am selben Tag. Das PHP-Team bestätigt: Nur das Update behebt die Sicherheitslücken vollständig.

Wurde bei WEB-SHOP-HOSTING etwas kompromittiert?
Es gibt keinen Hinweis darauf. Die Patches wurden am Tag der Veröffentlichung eingespielt. Wir prüfen die Protokolle weiterhin.

Ich nutze PHP 7.4 oder 8.0 auf meinem Server. Was jetzt?
Diese Versionen haben ihr End of Life erreicht. Es gibt Backports – vom PHP-Projekt als Quelltext und von Plesk als Pakete. Langfristig sollten Sie auf einen unterstützten PHP-Zweig wie PHP 8.3 oder 8.4 wechseln. Wenn Ihre Anwendung das derzeit nicht erlaubt, sprechen Sie uns an.

Woher weiß ich, welche PHP-Version mein Hosting nutzt?
In Plesk unter Websites & Domains → PHP. Alternativ können Sie vorübergehend eine zugriffsgeschützte Datei info.php mit dem Inhalt <?php phpinfo(); anlegen. Löschen Sie die Datei unmittelbar nach der Prüfung.

Quellen

• PHP-Projekt: Security Advisory vom 21.10.2026 – php.net
• GitHub Security Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp
• Plesk Change Log, PHP Updates 21. Oktober 2026
• The Hacker News, 21.10.2026: „PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge“
• The Hacker News, 21.10.2026: „PHP2Shell: What Actually Protects You Before the 14:00 UTC PHP RCE Patch, and What Doesn't“

Bei Fragen erreichen Sie uns über den Support.