Kritische PHP-Sicherheitslücke php2shell: Was jetzt zu tun ist

Laut der offiziellen PHP-Ankündigung vom 21. Oktober 2026 beheben die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 zwei kritische Lücken, die ohne Authentifizierung die Ausführung von Code aus der Ferne erlauben können. Beide erhielten auf der Skala CVSS v4.0 den Wert 9,2, eine Standardbewertung dafür, wie gefährlich eine Lücke eingestuft wird. Remote-Code-Ausführung bedeutet, dass ein Angreifer auf dem Server Befehle mit den Rechten des Web-Worker-Kontos ausführen kann.

Betroffen ist jede PHP-Installation, die Webanfragen bedient: PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed. Amazon Threat Intelligence schrieb am 21. Oktober, das Honeypot-Netzwerk habe den ersten Ausnutzungsversuch am 17. Oktober gesehen, vier Tage vor der Veröffentlichung. SecurityWeek berichtet, watchTowr sage, die derzeit kursierenden Proofs of Concept hätten die Codeausführung noch nicht erreicht. Es gibt also Versuche, belastbare Erfolgsnachweise sind dünn, und das ist kein Grund zu warten.

Läuft Ihre Website mit PHP, gehen Sie von einer Betroffenheit aus. Laut Anadolu Agency schätzt das FBI, dass PHP auf etwa 70 % der Websites eingesetzt wird, und laut CISA kann PHP in andere Software eingebettet und für Sie unsichtbar sein. Unser Tool zur Technologie-Erkennung gibt von außen einen ersten Eindruck davon, womit Ihre Website läuft, doch erwarten Sie von ihm keine verbindliche Aussage zur Version.

Für die genaue Version folgen Sie dem Weg von WordPress.org: Öffnen Sie im WordPress-Dashboard Werkzeuge, Website-Zustand, Info, Server. Hosting-Oberflächen zeigen die PHP-Version meist ebenfalls an, und bei Websites ohne WordPress müssen Ihr Entwickler oder Ihr Anbieter sie nennen. Liegt Ihre Version unter der Nummer Ihrer Reihe (8.2.35, 8.3.36, 8.4.27 oder 8.5.12), sind Sie laut den GitHub-Advisories betroffen.

Beim Shared Hosting verwaltet der Anbieter den Server, Ihre Aufgabe ist daher die schriftliche Nachfrage: Wurde PHP für diese Lücken aktualisiert, und auf welcher Version bin ich? Laut WordPress.org änderte sich die Lage bei den Anbietern stündlich: Manche hatten gepatcht, manche gaben an, durch eine WAF geschützt zu sein, manche arbeiteten noch daran. Eine WAF ist eine Firewall, die eingehende Anfragen filtert. Lautet die Antwort „Wir sind geschützt“, fragen Sie, auf welche Version umgestellt wurde.

Laut den Versionshinweisen von cPanel behebt EasyApache 4 25.91 beide Lücken von ea-php74 bis ea-php85, und 25.92 baut die Pakete ea-php74, ea-php80 und ea-php81 neu. Solche Pakete kommen in der Regel per automatischem Update, doch das ist unsere Einschätzung; der Serveradministrator sollte die Versionen in WHM bestätigen. Nutzen Sie Plesk, gilt dieselbe Frage: Lassen Sie sich von Ihrem Anbieter Paketnamen und Versionsnummer nennen. Betreiben Sie einen eigenen Server, patchen laut der Wissensdatenbank von Laravel Forge automatische Sicherheitsupdates PHP nicht; PHP muss auf jedem Server gesondert aktualisiert werden. Das PHP-Projekt weist zudem darauf hin, dass Linux-Distributionen den Patch vorab erhalten haben, und rät: „Prüfen Sie die Pakete Ihres Anbieters“.

PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Das Sicherheitsteam hat minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereitgestellt, und einige Distributionen portieren ebenfalls zurück, doch diese sind möglicherweise nicht in das Paket Ihres Hosters gelangt. WordPress.org erinnert außerdem daran, dass PHP vor 8.2 keine Sicherheitsupdates mehr bekommt. Laut VulnCheck wurden mehr als 2,6 Millionen aus dem Internet erreichbare PHP-Server gezählt, mindestens 1 Million davon läuft auf Versionen, die ihr Supportende erreicht haben.

CISA empfiehlt, Systeme vom Netz zu nehmen, die sich nicht aktualisieren lassen oder mit 8.1 oder älter laufen. WordPress.org verweist auf das britische NCSC und rät, den Server bis zum Upgrade offline zu nehmen, wenn Sie ihn selbst verwalten. Bringt Ihre Website kein Geld ein, etwa als reine Visitenkarte, ist das eine realistische Option. PHP 8.2 erreicht sein Supportende am 31. Dezember 2026; der Wechsel auf 8.2.35 verschafft Ihnen also nur kurz Luft, planen Sie Ihren Versionspfad deshalb jetzt.

Die PHP-Ankündigung ist eindeutig: Nur das Update ist eine vollständige Lösung; Übergangsmaßnahmen verringern die Angriffsfläche für bestimmte Wege, machen eine Installation aber nicht sicher. Das GitHub-Advisory nennt den Wechsel auf die gepatchte Version ebenfalls die einzige vollständige Maßnahme. Die zweite Lücke setzt voraus, dass zwei Anfragen beim selben Worker landen; mehrere Worker und das Recycling von Workern senken die Erfolgsquote, beseitigen das Risiko aber nicht, und eine vollständige Abhilfe per Konfiguration gibt es nicht. CISA schlägt vorübergehend eine WAF vor, und das Wort vorübergehend ist hier wichtig.

Die folgenden Maßnahmen nennt die PHP-Ankündigung, und sie sollte Ihr Serveradministrator umsetzen, nicht Sie. Die Ankündigung führt außerdem auf, vom Angreifer auslösbare fatale Fehler und Zeitüberschreitungen zu beheben und ungültige oder veraltete INI-Einstellungen zu entfernen, die pro Anfrage gesetzt werden. Laut Codeable nutzt WordPress session.upload_progress nicht; fragen Sie dennoch nach anderen Anwendungen auf dem Server.

• memory_limit=-1, so gesetzt, dass die Anwendung es nicht überschreiben kann (über php_admin_value)
• Ein niedriges post_max_size: 8M ohne Datei-Uploads, 32M mit Uploads, wobei upload_max_filesize darunter liegen muss
• session.upload_progress.enabled=0 und ein Neustart aller Worker, gesetzt in der php.ini oder der Pool-Konfiguration, nicht über ini_set oder .user.ini
• fatal_error_backtraces=0 unter PHP 8.5
• RLIMIT_AS und RLIMIT_DATA nicht verwenden, da sie die Lücke auslösen können

Amazon Threat Intelligence rät, die Untersuchung mindestens ab dem 17. Oktober zu beginnen, denn an diesem Tag wurde der erste Versuch beobachtet. Die Indikatoren sind POST-Anfragen an Formular-Uploads, die die Zeichenfolge PHP_SESSION_UPLOAD_PROGRESS enthalten, verdächtige Einträge in den Webserver-Logs sowie unerwartete Prozessaktivität oder Dateiänderungen. Bitten Sie Ihren Anbieter oder Administrator, nach diesen Spuren zu suchen. CISA empfiehlt zudem, PHP-Worker-Prozesse zu überwachen, die eine Shell starten oder Werkzeuge herunterladen. Unser Tool zur Sicherheitsprüfung untersucht die von außen sichtbaren Grundeinstellungen; es ersetzt weder die Server-Logs noch die Dateien auf dem Server.

Das zweite Thema sind langlaufende Prozesse. Laut der Wissensdatenbank von Laravel Forge startet ein Update PHP-FPM neu, doch Queue-Worker, Horizon und Octane, die von der Kommandozeile gestartet wurden, laufen mit dem alten PHP weiter, bis sie neu gestartet werden. Zur Kontrolle führen Sie auf dem Server php8.4 -v und php-fpm8.4 -v aus (sofern Sie 8.4 nutzen). Laut Qualys kann die von php -v gemeldete Version von der Installation abweichen, die Webanfragen bedient. Haben Sie als Notbehelf memory_limit=-1 gesetzt, stellen Sie wieder einen endlichen Wert ein. Finden Sie Spuren oder sind Sie sich nicht sicher, besprechen Sie mit Ihrem Administrator den Wechsel von Datenbankpasswörtern, API-Schlüsseln und Admin-Passwörtern; das ist ein allgemeiner Hygienegrundsatz und steht so nicht in den Quellen.

Drei Fehler fallen auf. Sie zu vermeiden, ist für die meisten Unternehmen ebenso wichtig wie das Update selbst.

Amazon schreibt, ein Patch-Fenster von 7 oder 30 Tagen setze eine Verzögerung voraus, die es nicht mehr gibt; gemessen werden müsse in Stunden. Die PHP Foundation wiederum erklärte, die Korrektur sei seit August vorbereitet worden, am 20. Oktober seien die CVE-Kennungen mit falschen Angaben durchgesickert, und die Veröffentlichung sei um einen Tag vorgezogen worden. Die Lehre ist schlicht: Halten Sie schriftlich fest, wem die Software unter Ihrer Website gehört, wer sie aktualisiert und wen Sie anrufen, und binden Sie Versionen am Ende ihres Supportzeitraums an einen Kalender.

• Ein Update von Plugin, Theme oder WordPress für ausreichend halten: Laut WordPress.org ist für diese Probleme kein WordPress-Update nötig oder geplant, und ein Update von Plugin oder Theme schützt nicht
• Sich auf die Ausgabe von php -v verlassen: Die Version auf der Kommandozeile kann von der Installation abweichen, die Webanfragen bedient
• Eine WAF als Lösung ansehen: CISA führt sie als vorübergehende Maßnahme, und wenn ein Anbieter sagt, er schütze mit einer WAF, belegt das nicht, dass die Version aktuell ist