PHP-Sicherheitsupdate (php2shell)
php2shell ist der Name für zwei kritische PHP-Lücken, die am 21. Oktober 2026 veröffentlicht wurden (CVSS v4.0 9.2, ohne Authentifizierung). Sie betreffen jede Website, die Anfragen mit PHP beantwortet, ob WordPress, Drupal, Joomla, Magento, PrestaShop oder Laravel. Behoben sind sie in 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Haben Sie diese Schwachstelle? Wir aktualisieren PHP, setzen die vorübergehende Gegenmaßnahme dort um, wo das Update noch nicht möglich ist, und prüfen, ob es Spuren eines Einbruchs gibt.
$ php -vPHP 8.3.30 (cli)# 8.3.30 < 8.3.36: betroffen$ php-fpm8.3 -vPHP 8.3.30 (fpm-fcgi)# CLI und FPM können verschiedene Versionen haben$ php -i | grep upload_progress.enabledsession.upload_progress.enabled => On => On# Sofortmaßnahme: 0 in php.ini, FPM neu starten8.5.12 · 8.4.27 · 8.3.36 · 8.2.35php2shell: zwei kritische Lücken im Interpreter selbst
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt neue Versionen, die CVE-2026-109618 und CVE-2026-109619 beheben. Es zog die Veröffentlichung auf 14:00 UTC vor, weil am Vortag ein Beitrag auf Hacker News die Kennungen vor Ablauf des Embargos öffentlich gemacht hatte.
CVE-2026-109618 ist eine Speicherbeschädigung: Geht PHP mitten in der Vorbereitung der Anfragedaten der Speicher aus, behandelt die Aufräumroutine ungültige Daten als gültig. Eine manipulierte Multipart-Anfrage, die den Speicher erschöpft, reicht aus, auch wenn ihre Größe innerhalb der Limits zu liegen scheint. CVE-2026-109619 lässt bereits freigegebenen internen Zustand zwischen Anfragen bestehen, und eine spätere Anfrage im selben Worker verwendet ihn weiter. Huntress beschreibt das als Heap-Use-after-free ohne Authentifizierung, mit Speicherabfluss und Remotecodeausführung mit den Rechten des Web-Workers.
Die Lücke steckt in PHP. Ein Update des CMS oder der Plugins behebt sie deshalb nicht. Laut php.net sind alle Installationen betroffen, die Webanfragen beantworten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko mit mod_php, wo die Lücke laut Rapid7 ausnutzbar ist, bevor überhaupt Anwendungscode läuft. Wiz zeigte Remotecodeausführung ohne Authentifizierung gegen WordPress, Drupal und Joomla sowie einen Weg zum Speicherabfluss, über den Passwörter, Tokens, API-Keys und Zertifikate offengelegt werden könnten.
Stand 21. Oktober rechnete Rapid7 mit Angriffen, und mehrere Teams reproduzierten die Lücke; Huntress hatte bei seinen Kunden keine Ausnutzung beobachtet. Das britische NCSC und CERT-EU gaben am selben Tag Warnungen heraus. Laut W3Techs läuft PHP auf rund 69,7 % der Websites, deren serverseitige Sprache bekannt ist.
Quellen: php.net · Rapid7 · Huntress · NCSC · Infosecurity Magazine
Korrigierte PHP-Versionen
Wenn Ihr Server Webanfragen mit PHP beantwortet und die Version älter ist als die für seinen Zweig in dieser Tabelle, sind Sie betroffen. Linux-Distributionen mit erweitertem Support haben ihre Pakete früher ausgeliefert: Dort zählt das Advisory des Anbieters, nicht die Versionsnummer.
| Zweig | Behoben in | Hinweis |
|---|---|---|
| 8.5 | 8.5.12 | |
| 8.4 | 8.4.27 | |
| 8.3 | 8.3.36 | |
| 8.2 | 8.2.35 | Lebensende am 31.12.2026 |
| 8.1, 8.0, 7.4 | Keine offizielle Version | PHP hat minimale Backports im Quellcode für Selbstkompilierer veröffentlicht |
| 7.3 und älter | Keine Korrektur | Auf einen unterstützten Zweig wechseln |
Prüfen Sie das
- Ihre Website läuft mit WordPress, Drupal, Joomla, Magento, PrestaShop, Laravel oder einer anderen PHP-Anwendung, die aus dem Internet erreichbar ist.
-
php -voderphp-fpm -vzeigen eine niedrigere Nummer als die Ihres Zweigs in der Tabelle. - Sie nutzen Apache mit
mod_php: Das ist die riskanteste Konfiguration. - Sie nutzen das PHP Ihrer Linux-Distribution: Die Nummer kann gleich bleiben, obwohl das Paket gepatcht ist. Maßgeblich ist das Advisory des Anbieters.
- Sie sind auf Shared Hosting: Das Update macht der Anbieter, aber Sie sehen die Version im Panel oder mit
phpinfo()und können nach einem Termin fragen.
Wenn Sie heute nicht aktualisieren können
Das sind die vorübergehenden Gegenmaßnahmen, die das PHP-Projekt veröffentlicht hat. Sie verringern das Risiko, bis das Update steht, ersetzen es aber nicht.
- 01 Setzen Sie
session.upload_progress.enabled=0in derphp.inioder im PHP-FPM-Pool und starten Sie alle Worker neu. Mitini_set()oder.user.iniwirkt es nicht. - 02 Unter PHP 8.5 zusätzlich
fatal_error_backtraces=0. - 03 Begrenzen Sie im Webserver oder Proxy die Anfragegröße und die Zahl der Felder, Teile und Header.
- 04
post_max_size=8M, wenn die Website keine Datei-Uploads annimmt;32M, wenn doch. - 05 Wenn Sie nicht aktualisieren können, suchen Sie nach Kompromittierungsindikatoren und Hintertüren. Ist auch keine Gegenmaßnahme möglich, rät das NCSC, eine Trennung des Systems vom Netz zu erwägen.
Sieben Schritte, in dieser Reihenfolge
Wir wenden auf jedem Server dasselbe Verfahren an: zuerst klären, welche Version wo läuft, dann korrigieren und zum Schluss prüfen, ob vor dem Patch jemand eingedrungen ist.
Versionsinventar
Wir erfassen jeden Server, Container und jedes Hosting, auf dem PHP läuft, mit CLI- und FPM-Version, Betriebsart (FPM, mod_php, CGI) und Zuständigkeit. Die vergessene Website auf einem alten Server bleibt sonst ungepatcht.
Sofortmaßnahme
Wo das Update nicht sofort möglich ist, deaktivieren wir session.upload_progress in der php.ini oder im Pool, begrenzen Größe und Teile der Anfragen und starten die Worker neu.
Update
Wir wechseln auf die korrigierte Version Ihres Zweigs oder auf das gepatchte Paket Ihrer Distribution. Sind Sie noch auf 8.1 oder älter, erklären wir die beiden Wege: mit den Backports kompilieren oder auf einen unterstützten Zweig migrieren.
Prüfung
Wir prüfen die Version, die tatsächlich die Anfragen beantwortet, nicht nur die der Kommandozeile, und ob Website, Formulare und Uploads weiter funktionieren.
Suche nach Kompromittierungsindikatoren
Wir gehen Access- und Error-Logs durch, kürzlich geänderte Dateien im Web-Verzeichnis und neue Administratorkonten im CMS.
Rotation von Secrets, falls nötig
Gibt es Hinweise auf einen Zugriff oder war der Server dem Speicherabfluss ausgesetzt, ändern wir Datenbankpasswörter, API-Keys, Tokens und Zertifikate.
Beobachtung neuer Advisories
Wir halten fest, welche Version auf welchem Server läuft und welche Advisories zu verfolgen sind (PHP, Ihre Distribution, Ihr CMS), damit das nächste Update bei diesem Inventar ansetzt.
Was oft halb erledigt bleibt
Sie wissen nicht, welche PHP-Version Ihre Website nutzt?
Kostenlose Beratung →Das könnte Sie auch interessieren
Häufige Fragen zu php2shell
Was ist php2shell?
Ist mein WordPress betroffen, obwohl die Plugins aktuell sind?
Reicht es, session.upload_progress zu deaktivieren?
Ich bin noch auf PHP 7.4 oder 8.0. Was tun?
Und wenn ich Shared Hosting nutze?
Sagen Sie uns, wo Ihr PHP läuft
Wir beginnen mit dem Inventar: welche Version auf jedem Server läuft, was heute erledigt werden muss und was bis zu einem Wartungsfenster warten kann.
Erzählen Sie uns Ihre Herausforderung. Wir schlagen die Lösung vor.
Unverbindlich. Innerhalb von 24 Stunden erhalten Sie ein Angebot mit Umfang, Zeitplan und Budget. Ohne Kleingedrucktes.