PHP2Shell: Zwei kritische PHP-Lücken und Ihre Kundenprojekte

Was passiert ist

Am 20. Oktober 2026 kündigte das PHP-Projekt für den folgenden Tag, 14:00 UTC, eine Sicherheitsveröffentlichung an: zwei kritische Lücken, vom Projekt mit CVSS v4.0 9,2 bewertet. Es behielt sich vor, früher zu veröffentlichen, sollten Details öffentlich werden oder Angriffe beobachtet werden. Nach Angaben der Sicherheitsfirma watchTowr kursierten am selben Tag Details in sozialen Medien; der ursprünglich geplante Termin sei der 22. Oktober gewesen. Am 21. Oktober erschienen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 zusammen mit dem Sicherheitshinweis des Projekts. Linux-Distributionen und LTS-Anbieter hatten die Korrekturen vorab erhalten.

Der erste Fehler, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), liegt in der Behandlung von Speichermangel. Geht PHP während einer Anfrage der Speicher aus, kann die Verarbeitung an einer Stelle abbrechen, an der die internen Daten der Anfrage erst zum Teil angelegt sind. Das Aufräumen am Ende der Anfrage behandelt diese unvollständigen Daten dann wie gültige.

Der zweite, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), betrifft veralteten Zustand. Interne Daten, die zu einer Anfrage gehören, können weiterleben, nachdem ihr Speicher freigegeben wurde. Eine spätere Anfrage, die derselbe Worker bedient, kann diesen Zustand verwenden, bevor die reguläre Initialisierung ihn zurücksetzt. Beides sind Fehler im PHP-Kern, nicht in einer Anwendung, einem Theme oder einem Plugin. Eine Anwendung kann sich dagegen nicht selbst schützen; der Interpreter muss aktualisiert werden.

watchTowr berichtet, seit dem 21. Oktober Ausnutzungsversuche in seinem Honeypot-Netz zu beobachten. In den Katalog bekannter ausgenutzter Lücken der US-Behörde CISA waren beide CVEs nach Angaben von watchTowr zu diesem Zeitpunkt noch nicht aufgenommen. Rechnen Sie dennoch damit, dass ungepatchte Server gesucht werden: Die Lücke betrifft jede Website, die PHP ausführt, und der Angriff braucht keine Anmeldung.

Am 23. Oktober folgte ein zweiter Hinweis des Projekts. Die Einstellung session.upload_progress.enabled=0 soll bis zur nächsten regulären Fehlerkorrektur gesetzt bleiben, um einen weiteren Weg zur Codeausführung zu schließen, den das Projekt als unwahrscheinlich einstuft. Er tritt nur bei einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode auf; das Projekt behandelt ihn im regulären Zyklus und kündigt einen vollständigen Hinweis zu CVE-2026-115560 mit der nächsten Veröffentlichung an.

Wer betroffen ist

Das Projekt nennt als betroffen alle PHP-Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht es bei mod_php. Dort liegt ein Exploit vor, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, bevor Anwendungscode läuft. WordPress, ein Plugin oder eine Firewall innerhalb der Anwendung bekommen davon nichts mit, weil sie zu diesem Zeitpunkt noch nicht gestartet sind.

PHP 8.1 und älter erhalten vom Projekt keine Updates mehr. Für 7.4, 8.0 und 8.1 hat das Sicherheitsteam minimale Backports im Quellcode bereitgestellt, für alle, die PHP selbst bauen oder keinen LTS-Anbieter haben. Distributionen und LTS-Anbieter liefern Korrekturen in ihren eigenen Paketen; die Versionsnummer bleibt dort oft alt, die Korrektur steht im Changelog des Pakets.

Für Agenturen ist die Liste der betroffenen Software kurz: alles, was auf PHP läuft. WordPress und WooCommerce, Shopware, TYPO3, Drupal, Laravel, Symfony, Nextcloud, Matomo: Sie alle führen PHP aus und sind so lange verwundbar, wie der Interpreter darunter alt ist. Wer Kundenseiten bei einem Managed Hoster betreibt, hängt an dessen Update. Wer eigene Server oder vServer betreibt, ist selbst an der Reihe. Die schwierigsten Fälle sind Altprojekte, die wegen eines Plugins oder Themes auf PHP 7.4 festhängen.

Der Workaround und seine Grenzen

Wo das Update warten muss, nennt das Projekt einen Workaround: session.upload_progress.enabled=0 setzen und jeden Worker neu starten. Die Einstellung muss greifen, bevor PHP die Anfrage auswertet: in der php.ini, im FPM-Pool oder in der Serverkonfiguration. Ein ini_set() im Anwendungscode oder eine .user.ini unter FPM reichen nicht aus.

; php.ini oder FPM-Pool, danach alle Worker neu starten
session.upload_progress.enabled=0

Die Funktion verfolgt den Fortschritt von Datei-Uploads in der Session. Viele Anwendungen nutzen sie nicht; dann kostet die Abschaltung nichts. Das Projekt schränkt den Wert dennoch ein: Der Workaround blockiert die bestätigten Wege über die Session, aber keine anderen Varianten. Und weiter: "There are no complete mitigations, updating is the only safe choice." Behandeln Sie ihn als Überbrückung für Stunden oder Tage, nicht als Lösung.

Cloudflare hat am 21. Oktober Regeln für seine WAF ausgerollt und benennt deren Grenze gleich mit: Kunden, die den Namen session.upload_progress.name geändert haben, deckt die Regel nicht ab. Das ist die Grenze jeder WAF-Regel. Sie erkennt ein bekanntes Muster in der Anfrage, nicht den Fehler im Interpreter; eine Variante mit anderem Muster kommt durch. Eine WAF-Regel ist ein Pflaster, kein Patch. Sie kauft Zeit bis zum Update und ersetzt es nicht. Was eine WAF leistet und wo sie endet, steht im Beitrag Was ist eine WAF?.

Was Sie jetzt prüfen

1. Inventar. Eine Liste jeder Kundeninstallation mit PHP-Zweig, Betriebsart (FPM, mod_php, CGI), Hoster und der Person, die aktualisiert. Bei Managed Hosting zählt die Mitteilung des Hosters, bei Shared Hosting die PHP-Version im Kundenmenü, bei eigenen Servern php -v und die Konfiguration des Webservers.
2. Aktualisieren. Eigene Server auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12, oder auf das Paket der Distribution, dessen Changelog die beiden CVEs nennt. Beim Hoster nachfragen und die Antwort festhalten. Für 7.4, 8.0 und 8.1 den Backport des Anbieters einspielen oder den Umstieg planen.
3. Überbrücken. Wo das Update nicht sofort geht: Workaround setzen, Worker neu starten und mit phpinfo() oder php -i prüfen, dass die Einstellung wirkt.
4. Logs lesen. Seit dem 20. Oktober, dem Tag, an dem Details kursierten: Abstürze von Workern, ungewöhnliche Meldungen zu Speichermangel, neue oder geänderte Dateien in beschreibbaren Verzeichnissen, unbekannte Cronjobs oder Administratorkonten. Ein Angriff auf den Interpreter hinterlässt in der Anwendung wenig Spuren; sehen Sie auf Serverebene nach.
5. Zugangsdaten tauschen, wo Zweifel bleiben. Einen Server, der ungepatcht erreichbar war und Auffälligkeiten zeigt, behandeln Sie als kompromittiert: Datenbankpasswort, Salts und Schlüssel in wp-config.php oder .env, API-Schlüssel von Zahlungs- und Mailanbietern erneuern.
6. Kunden informieren. Eine kurze Nachricht: was betroffen war, was wann getan wurde, was noch offen ist. Wer das in einem Wartungsvertrag geregelt hat, hat es jetzt leichter; was dazugehört, steht im Beitrag Kundenanwendungen betreuen: Wartung und Kosten planen.

Was das für Kunden von obhut heißt

obhut liefert Websites als statische Dateien aus: HTML, CSS, JavaScript, Bilder und Schriften, verteilt über den Edge. Einen PHP-Interpreter gibt es bei obhut nicht. Eine Website, die Sie als statische Dateien bei obhut veröffentlicht haben, ist von PHP2Shell nicht betroffen; dort gibt es nichts zu patchen.

Anders liegt der Fall, wenn eine WordPress- oder andere PHP-Anwendung hinter dem Proxy oder einem Tunnel von obhut läuft. Dann sitzt obhut vor der Anwendung, PHP läuft aber weiter an ihrem Origin, und dort gehört das Update hin. Der Edge ändert nichts am Interpreter dahinter.

Die WAF von obhut führt virtuelle Patches aus, die aus dem Regelsatz des CrowdSec-Hubs stammen, einmal in einen eigenen Regelsatz übernommen wurden und am Edge vor dem Origin ausgewertet werden. Eine Regel für PHP2Shell enthält dieser Satz zum Zeitpunkt dieses Beitrags nicht. Und auch wenn sie käme, gälte, was oben steht: ein Pflaster, kein Patch. Das Update am Origin bleibt der Weg.

Wer die öffentliche Angriffsfläche einer Website dauerhaft verkleinern will, kann sie als statische Dateien exportieren und bei obhut ausliefern. Der Interpreter läuft dann nur noch dort, wo redigiert wird, und muss nicht öffentlich erreichbar sein. Was eine statische Website vor der Veröffentlichung braucht, steht im Beitrag Vibe-Coding-Website veröffentlichen: Launch-Check; wie obhut sie ausliefert, auf der Seite zum Hosting für Agenturen.

Häufige Fragen

Ist eine WordPress-Seite betroffen, wenn alle Plugins und Themes aktuell sind?

Ja, solange PHP darunter alt ist. Die Fehler liegen im Interpreter; bei mod_php greift der Exploit, bevor WordPress geladen ist. Plugin-Updates ändern daran nichts. Entscheidend ist die PHP-Version, die der Hoster oder Ihr Server ausführt.

Reicht der Workaround, wenn das Update dauert?

Nein. Das Projekt schreibt, dass er die bestätigten Wege über die Session blockiert, aber nicht andere Varianten, und dass es keine vollständige Abschwächung gibt. Er überbrückt, das Update schließt.

Mein Hoster sagt, er habe aktualisiert. Wie prüfe ich das?

phpinfo() oder php -v zeigt die Version. Steht dort 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder eine neuere Nummer, ist das Update da. Bei Distributionspaketen bleibt die Nummer oft alt; dann zählt der Eintrag zu CVE-2026-109618 und CVE-2026-109619 im Changelog des Pakets.

Was ist mit Projekten auf PHP 7.4?

Das Projekt veröffentlicht für 7.4 keine Version mehr. Sein Sicherheitsteam hat minimale Backports im Quellcode bereitgestellt, für alle, die PHP selbst bauen; Distributionen und LTS-Anbieter liefern Pakete. Wer beides nicht hat, dem bleibt der Umstieg. Planen Sie ihn jetzt, nicht erst beim nächsten Vorfall.