PHP2Shell: Kritische PHP-Sicherheitslücke – jetzt updaten

Am 21. Oktober 2026 hat das PHP-Projekt Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht: CVE-2026-109618 und CVE-2026-109619. Unter dem Namen „PHP2Shell“ sorgen sie weltweit für Alarm, denn beide Lücken können unter bestimmten Bedingungen Remote Code Execution ohne Anmeldung ermöglichen. Betroffen sind praktisch alle Server, auf denen PHP Web-Anfragen verarbeitet, also auch typische WordPress-, Shopware-, Laravel-, Drupal- oder Magento-Installationen.

Besonders kritisch: Details zu den Lücken sind bereits am 20. Oktober vor der koordinierten Veröffentlichung durchgesickert. Sicherheitsanbieter wie Cloudflare und Patchstack berichteten schon vor dem offiziellen Patch über erste Angriffe und Scans. In diesem Beitrag fassen wir zusammen, wer betroffen ist, welche Versionen die Lücke schließen und was Sie jetzt konkret tun sollten.

Das Wichtigste in Kürze

• Was: Zwei kritische Schwachstellen im PHP-Kern (CVSS v4.0: jeweils 9.2), die zu Speicherkorruption und im schlimmsten Fall zu Remote Code Execution führen können.
• Wer: Alle PHP-Versionen von 5.4 bis 8.5.11, die Web-Anfragen verarbeiten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.
• Fix: Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, oder das gepatchte Paket Ihres Linux-Distributors bzw. Hosters.
• Kein Fix: Für PHP 8.1 und älter veröffentlicht das PHP-Projekt keine Updates mehr.
• Dringlichkeit: Sehr hoch, weil die Details vorab geleakt wurden und bereits gezielt nach verwundbaren Servern gesucht wird.

Was steckt hinter PHP2Shell?

Die beiden Schwachstellen wurden laut Google Cloud gemeinsam mit Wiz Research offengelegt. Sie betreffen die Art, wie PHP intern mit dem Speicher einer Anfrage umgeht:

CVE-2026-109618: Speicherkorruption durch Out-of-Memory-Fehler

Wenn PHP während einer Anfrage an das Speicherlimit stößt, kann die Verarbeitung an einer Stelle abbrechen, an der Anfragedaten erst teilweise initialisiert sind. Beim anschließenden Aufräumen werden diese ungültigen Daten unter Umständen als gültig behandelt. Ein Angreifer kann das gezielt auslösen und so Speicher manipulieren.

CVE-2026-109619: Veralteter Zustand zwischen Anfragen

Bestimmte interne Daten einer Anfrage können überleben, obwohl ihr Speicher bereits freigegeben wurde. Verarbeitet derselbe Worker-Prozess danach eine weitere Anfrage, kann er auf diesen veralteten Zustand zugreifen, bevor er zurückgesetzt wird. Das ist ein klassisches Einfallstor für sogenannte Use-after-free-Angriffe.

Laut PHP-Sicherheitsteam ist das Risiko bei mod_php am höchsten, weil ein Angriff dort ablaufen kann, bevor überhaupt Anwendungscode ausgeführt wird. Nach Angaben von Wiz Research genügt schon eine einfache „Hello World“-Anwendung auf einer verwundbaren PHP-Version für einen erfolgreichen Angriff. Zudem kann Arbeitsspeicher ausgelesen werden, was Passwörter, Tokens oder API-Schlüssel offenlegen kann, auch ohne vollständige Codeausführung.

Welche PHP-Versionen sind betroffen und welche sind sicher?

PHP-Zweig	Verwundbar bis	Sichere Version	Status
PHP 8.5	8.5.11	8.5.12	Patch verfügbar
PHP 8.4	8.4.26	8.4.27	Patch verfügbar
PHP 8.3	8.3.35	8.3.36	Patch verfügbar
PHP 8.2	8.2.34	8.2.35	Patch verfügbar, Support endet am 31.12.2026
PHP 8.1 und älter	alle	–	End of Life, kein offizieller Patch

Einige Linux-Distributionen und Anbieter von Langzeit-Support liefern auch für ältere Zweige zurückportierte Fixes aus. Verlassen Sie sich darauf aber nur, wenn Ihr Anbieter das ausdrücklich bestätigt. Die sauberste Lösung ist ein Upgrade auf einen unterstützten PHP-Zweig.

Sofortmaßnahmen: Das sollten Sie jetzt tun

1. PHP-Version prüfen

Prüfen Sie auf jedem Server und in jedem Container, welche PHP-Version tatsächlich läuft. Auf der Kommandozeile genügt:

php -v

Achtung: Die CLI-Version kann von der Version abweichen, die Ihr Webserver nutzt. Prüfen Sie im Zweifel über phpinfo() in einer geschützten Datei oder im Control Panel Ihres Hosters. Vergessen Sie auch Docker-Images, Staging-Systeme und Appliances nicht, in denen PHP mitgeliefert wird.

2. Sofort updaten

Installieren Sie die gepatchte Version Ihres PHP-Zweigs bzw. das Sicherheitsupdate Ihrer Distribution und starten Sie PHP-FPM bzw. den Webserver anschließend neu. Bei Containern müssen Images neu gebaut und ausgerollt werden. Ein reines Update des Basis-Images genügt nicht, solange alte Container weiterlaufen.

3. Wenn ein Update nicht sofort möglich ist

Das PHP-Projekt nennt einige Übergangsmaßnahmen, die bestimmte Angriffswege erschweren. Wichtig: Laut PHP machen diese Maßnahmen eine Installation nicht sicher. Sie verschaffen nur Zeit bis zum Update.

; php.ini – nur als Übergangslösung bis zum Update
session.upload_progress.enabled = Off

• session.upload_progress.enabled deaktivieren.
• post_max_size so weit wie möglich reduzieren.
• Laut PHP-Hinweisen memory_limit=-1 über php_admin_value setzen. Das birgt eigene Risiken für die Serverstabilität und sollte nur mit Bedacht eingesetzt werden.
• Eine Web Application Firewall vorschalten. Cloudflare hat WAF-Regeln gegen bekannte Angriffsmuster ausgerollt. Diese helfen aber nur, wenn Ihr Server ausschließlich Traffic über Cloudflare annimmt.

Bei besonders kritischen Systemen, die sich nicht zeitnah patchen lassen, empfehlen sowohl Patchstack als auch das britische NCSC, sie vorübergehend in den Wartungsmodus zu versetzen oder vom Netz zu nehmen. Einige Betreiber haben genau das bereits getan.

4. Auf Anzeichen eines Angriffs prüfen

Mögliche Hinweise auf Angriffsversuche sind laut Patchstack:

• Multipart-Anfragen, auf die Speicherlimit-Fehler oder wiederholte HTTP-500-Antworten folgen,
• auffällig fehlerhafte PHPSESSID-Cookies,
• unerklärliche Neustarts von PHP-Worker-Prozessen.

Diese Anzeichen sind kein Beweis für einen Einbruch, sollten aber geprüft werden. Besteht der Verdacht auf eine Kompromittierung, behandeln Sie den Server als kompromittiert: Prüfen Sie ihn auf Backdoors und tauschen Sie alle Zugangsdaten, API-Schlüssel und Tokens aus, die auf dem System gespeichert sind.

Was bedeutet das für WordPress, Shopware und andere CMS?

Die Lücken liegen im PHP-Kern, nicht in einem bestimmten CMS. Ein Update von WordPress, Shopware oder Plugins allein schließt die Lücke deshalb nicht. Entscheidend ist die PHP-Version auf dem Server. Wiz Research hat erfolgreiche Angriffe auf aktuelle Container-Images von WordPress, Drupal und Joomla demonstriert.

Seien Sie vorsichtig bei inoffiziellen „Fix-Plugins“ oder kopierten Code-Schnipseln, die angeblich vor PHP2Shell schützen. Solche Lösungen können die Lücke nicht schließen und bringen im schlimmsten Fall neuen Schadcode mit. Wenn Ihre Website bei einem Hoster liegt, fragen Sie dort aktiv nach, ob und wann die gepatchte PHP-Version eingespielt wurde.

Lehren aus PHP2Shell: Warum Patch-Management Pflicht ist

PHP2Shell zeigt, wie schnell sich das Zeitfenster für Angreifer öffnet: Zwischen dem Leak der Details und den ersten Scans lagen nur Stunden. Unternehmen, die ihre Systeme kennen und Updates routiniert einspielen, sind hier klar im Vorteil. Drei Punkte sind entscheidend:

• Inventar: Sie müssen wissen, wo PHP überall läuft, inklusive Container, Testsysteme und Drittprodukte.
• Unterstützte Versionen: End-of-Life-Software wie PHP 8.1 erhält bei Vorfällen wie diesem keinen Patch. Planen Sie Upgrades rechtzeitig. PHP 8.2 erreicht bereits am 31. Dezember 2026 sein Supportende.
• Geregelter Prozess: Ein festes Patch-Management mit klaren Zuständigkeiten sorgt dafür, dass kritische Updates innerhalb von Stunden statt Wochen eingespielt werden.

FAQ zur PHP-Sicherheitslücke PHP2Shell

Bin ich betroffen, wenn meine Website mit WordPress läuft?

Ja, sofern auf dem Server eine verwundbare PHP-Version (5.4 bis 8.5.11) läuft. Maßgeblich ist die PHP-Version, nicht die WordPress-Version.

Reicht es, die php.ini anzupassen?

Nein. Die vom PHP-Projekt genannten Einstellungen reduzieren lediglich einzelne Angriffswege. Nur ein Update auf eine gepatchte Version schließt die Lücke vollständig.

Was mache ich mit PHP 7.4, 8.0 oder 8.1?

Für diese Versionen gibt es vom PHP-Projekt keinen offiziellen Patch. Prüfen Sie, ob Ihr Distributor oder LTS-Anbieter einen Backport bereitstellt, und planen Sie das Upgrade auf PHP 8.3 oder neuer mit hoher Priorität.

Wird die Lücke bereits ausgenutzt?

Cloudflare und mehrere Hosting-Partner von Patchstack meldeten frühe Angriffe. Gleichzeitig sahen andere Telemetriedaten am 21. Oktober vor allem Scans ohne bestätigte Einbrüche. Da die Details öffentlich sind, ist mit einer schnellen Zunahme echter Angriffe zu rechnen.

Unterstützung durch Webect

Sie sind unsicher, welche PHP-Versionen in Ihrer Infrastruktur laufen, oder können das Update nicht selbst einspielen? Unser Team prüft Ihre Server, Container und Hosting-Umgebungen, spielt die Patches ein und kontrolliert Ihre Systeme auf Auffälligkeiten. Mehr zu unseren Leistungen rund um IT-Security, Managed Hosting und PHP-Entwicklung finden Sie auf unserer Website. Für einen schnellen Check kontaktieren Sie uns direkt.

Quellen

• PHP.net: Ankündigung der Security-Releases vom 21.10.2026
• PHP Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC (UK): Critical security issue affecting PHP
• Patchstack: PHP vulnerable to critical RCE
• Google Cloud: Responding to core PHP vulnerabilities

Stand: 21. Oktober 2026. Die Lage entwickelt sich dynamisch. Wir aktualisieren diesen Beitrag, sobald neue Erkenntnisse vorliegen.