php2shell: die kritische PHP-Sicherheitslücke und was heute zu tun ist

Am 21. Oktober 2026 hat das PHP-Projekt Patches für zwei kritische Sicherheitslücken veröffentlicht, CVE-2026-109618 und CVE-2026-109619, bekannt als php2shell. Ein Angreifer ohne Benutzerkonto und Passwort kann mit präparierten HTTP-Anfragen Serverspeicher auslesen und Code mit den Rechten des Webprozesses ausführen. Läuft Ihre Website auf WordPress, PrestaShop, Drupal, Joomla, Magento oder Laravel, läuft sie auf PHP und ist betroffen.

Die korrigierten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Läuft auf Ihrem Server eine ältere Version, steht das Update heute an.

Was passiert ist, ohne Fachjargon

Es handelt sich um zwei Fehler in der Art, wie PHP beim Bearbeiten einer Webanfrage mit Speicher umgeht.

• CVE-2026-109618 (Speicher läuft mitten in der Anfrage aus). Geht PHP der Speicher aus, während es die Anfragedaten aufbaut, behandelt die anschließende Bereinigung ungültige Daten als gültig. Ein Angreifer löst das mit multipart-Anfragen aus (wie sie Formulare mit Datei-Upload senden), die so gebaut sind, dass sie den Speicher erschöpfen, obwohl ihre Größe innerhalb der Limits wirkt. Advisory: GHSA-w8hw-w9fx-j79w.
• CVE-2026-109619 (Zustand überlebt zwischen Anfragen). Ein fataler Fehler, etwa Speichermangel oder ein Timeout, unterbricht die Bereinigung. Ein Teil des internen Zustands ist freigegeben, aber noch erreichbar, und die nächste Anfrage im selben Prozess verwendet ihn. Huntress beschreibt das als unauthentifizierten Heap-Use-after-free mit Speicherleck und Remote Code Execution. Advisory: GHSA-6wmf-4rv5-p3rp.

Beide haben einen CVSS-v4.0-Wert von 9.2 von 10 (kritisch). Der vor der Veröffentlichung geleakte Beitrag nannte 10.0; offiziell sind es 9.2.

Das Speicherleck hat eine praktische Folge: Was der PHP-Prozess geladen hat (Datenbankpasswörter, Tokens, API-Schlüssel, Zertifikate), kann bei dem landen, der die Lücke ausnutzt. Wiz hat Remote Code Execution ohne Authentifizierung gegen WordPress, Drupal und Joomla demonstriert, dazu diesen Weg für das Speicherleck.

Wer betroffen ist

Laut php.net jede PHP-Installation, die Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko mit mod_php: Laut Rapid7 lässt sich die Lücke dort ausnutzen, bevor überhaupt Anwendungscode läuft. Kein WordPress-Sicherheitsplugin hält das auf.

Nach Versionen:

PHP läuft auf 69,7 % der Websites, deren serverseitige Sprache bekannt ist, laut W3Techs, zitiert von Infosecurity Magazine. Wurde Ihre Website mit einem WordPress-Template gebaut und seit der Übergabe nicht mehr angefasst, läuft sie höchstwahrscheinlich noch auf einer ungepatchten PHP-Version.

So prüfen Sie Ihre PHP-Version

Drei Wege, vom einfachsten zum zuverlässigsten:

1. Hosting-Panel. In cPanel, Plesk oder dem Panel Ihres Anbieters gibt es meist einen Bereich “PHP-Version” oder “PHP Selector”. WordPress zeigt sie auch unter Werkzeuge → Website-Zustand → Bericht → Server.
2. php -v per SSH. Vorsicht: Das zeigt die Version der Kommandozeile, die nicht unbedingt die ist, die die Website ausliefert. Auf Servern mit mehreren installierten Versionen weichen sie oft ab.
3. phpinfo(). Eine Datei info.php mit <?php phpinfo(); im Web-Root zeigt die Version und die SAPI, die tatsächlich die Anfragen bedient (die Zeile “Server API” verrät, ob es FPM, Apache 2.0 Handler, also mod_php, CGI oder LiteSpeed ist). Löschen Sie die Datei, sobald Sie nachgesehen haben: Sie zeigt jedem die Serverkonfiguration.

Nutzen Sie die Pakete Ihrer Linux-Distribution (Debian, Ubuntu, RHEL und Derivate), stimmt die Versionsnummer womöglich nicht mit der Tabelle überein, obwohl der Patch eingespielt ist: LTS-Distributionen haben die Patches früher erhalten und liefern sie unter eigener Nummerierung aus. Prüfen Sie das Security Advisory Ihrer Distribution für das PHP-Paket.

Shared Hosting oder VPS. Beim Shared Hosting kontrolliert der Anbieter das PHP-Binary und die globale php.ini: Sie wählen im Panel den Zweig, den Patch spielt der Anbieter ein. Fragen Sie schriftlich nach, ob er bereits auf die korrigierten Versionen aktualisiert hat. Auf einem VPS oder dedizierten Server machen Sie das selbst, oder wer Ihre Wartung übernimmt.

Was jetzt zu tun ist

1. Aktualisieren

Wechseln Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, oder installieren Sie das gepatchte Paket Ihrer Distribution. Danach alle PHP-Prozesse neu starten (den Dienst php-fpm, Apache bei mod_php, LiteSpeed). Solange die alten Prozesse laufen, läuft auch der verwundbare Code.

Auf 8.2 deckt Sie der Patch jetzt ab, aber dieser Zweig bekommt ab dem 31. Dezember 2026 keine Korrekturen mehr. Planen Sie den Wechsel auf 8.3 oder neuer schon jetzt.

2. Wenn Sie auf PHP 8.1 oder älter sind

Für 8.1, 8.0 und 7.4 veröffentlicht das PHP-Projekt keine Versionen mehr. Es hat minimale Backports im Quellcode bereitgestellt, in Branches auf seinem GitHub, für alle, die PHP selbst kompilieren. Wenn das nicht auf Sie zutrifft, bleiben zwei Wege: ein Anbieter oder eine Distribution, die diese Version weiter unterstützt, oder die Migration der Anwendung auf 8.3 oder neuer. Eine Migration kann Plugins oder alten Code brechen, deshalb wird sie auf einer Kopie getestet, bevor die Produktion angefasst wird.

3. Temporäre Mitigationen bis zum Update

Das sind die vom PHP-Projekt veröffentlichten. Sie verringern das Risiko, ersetzen aber nicht das Update:

• session.upload_progress.enabled = 0 in der php.ini oder in der Konfiguration des PHP-FPM-Pools setzen und alle Worker neu starten. Über ini_set() oder eine .user.ini wirkt es nicht.
• Unter PHP 8.5 zusätzlich: fatal_error_backtraces = 0.
• Gegen Speichererschöpfung: im Webserver oder Proxy die Anfragegröße und die Anzahl von Feldern, Teilen und Headern begrenzen. Ohne Datei-Uploads post_max_size = 8M, mit Uploads 32M.

Beim Shared Hosting haben Sie vermutlich keinen Zugriff auf php.ini oder den Pool: Dann ist auch die Mitigation Sache des Anbieters.

Wenn Sie nicht aktualisieren können oder einen Angriff vermuten

Das britische NCSC rät: Wer nicht aktualisieren kann, sollte nach Anzeichen einer Kompromittierung und Hintertüren suchen, und wer auch die Mitigationen nicht umsetzen kann, sollte erwägen, das System vom Netz zu nehmen. Eine Website, die einen Tag offline ist, kostet weniger als eine, die Malware verteilt oder Kundendaten preisgibt.

Worauf Sie bei einer PHP-Website achten sollten:

• Neue oder geänderte .php-Dateien in Ordnern, in die sie nicht gehören, etwa wp-content/uploads oder Cache-Verzeichnisse.
• Administratorkonten, die niemand angelegt hat.
• Geplante Aufgaben (Cron) oder Prozesse, die Sie nicht kennen.
• Fatale Fehler wegen Speichermangel oder Timeout in den PHP-Logs ab dem 20. Oktober, vor allem bei multipart-POST-Anfragen.

Finden Sie etwas, oder war Ihr Server ungepatcht erreichbar, rotieren Sie die Secrets, die der PHP-Prozess im Speicher hatte: Datenbankpasswort, API-Schlüssel (Zahlungsanbieter, E-Mail, CRM), Tokens und, falls derselbe Prozess das TLS-Zertifikat ausliefert, auch dessen Schlüssel. Wegen des Speicherlecks macht ein Update nicht rückgängig, was bereits abgeflossen ist. Zeigt die Website schon Spuren eines Einbruchs, steht unter Website gehackt, was in der ersten Stunde zu tun ist.

Chronologie

• 20. Oktober: Ein Beitrag auf Hacker News veröffentlicht die CVE-Nummern vor Ende des Embargos.
• 21. Oktober, 14:00 UTC: Das PHP-Projekt zieht die Veröffentlichung der Patches vor.
• 21. Oktober: Das NCSC (Großbritannien) und CERT-EU geben Warnungen heraus. Rapid7 erwartet Ausnutzung und meldet, dass mehrere Teams die Lücke reproduzieren.
• 21. Oktober, 16:30 US-Ostküstenzeit: Huntress meldet keine beobachtete Ausnutzung bei seinen Kunden.

Dass am 21. Oktober keine Ausnutzung beobachtet wurde, verschafft keinen Spielraum: Die CVE-Nummern sind öffentlich, und Teams reproduzieren die Lücke.

Die übrigen Warnungen dieser Woche (Node.js, NGINX, GitLab, Railway, LiteLLM und die Zertifikate von GoDaddy und eMudhra) stehen im Überblick zu den Sicherheitslücken im Oktober 2026.

Wenn wir das für Sie übernehmen sollen

Bei Soamee warten wir PHP-Anwendungen und Server von Kunden und können dieses Update für Sie übernehmen. Der Ablauf ist der in diesem Artikel beschriebene, angewendet auf Ihre Umgebung:

1. Bestandsaufnahme: welche Websites und Server Sie haben, welche PHP-Version und SAPI jeweils läuft und wer jeden Server kontrolliert (Sie oder der Hoster).
2. Sofortige Mitigation, wo das Update nicht am selben Tag möglich ist.
3. Update auf die korrigierte Version, oder ein Migrationsplan bei 8.1 und älter, vorher auf einer Kopie getestet.
4. Prüfung, dass die Website Anfragen mit der neuen Version bedient und keine alten Prozesse mehr laufen.
5. Suche nach Anzeichen einer Kompromittierung und Rotation der Secrets, falls nötig.

Kein Update garantiert, dass ein Server vor dem Patch nicht kompromittiert wurde; deshalb steht Punkt 5 auf der Liste. Wenn wir uns das ansehen sollen, schreiben Sie uns oder buchen Sie eine kostenlose Beratung. Suchen Sie laufende Wartung, finden Sie unsere Leistungen für Cloud und DevOps und Webentwicklung.

Quellen

• PHP: Ankündigung der korrigierten Versionen
• Rapid7: CVE-2026-109618 und CVE-2026-109619
• Huntress: php2shell, geleakte kritische PHP-Lücken
• NCSC: Critical security issue affecting PHP
• Infosecurity Magazine: Critical PHP vulnerabilities leaked