PHP2Shell: Was Shopware-Shopbetreiber zu CVE-2026-109618 und CVE-2026-109619 tun müssen

PHP hat heute Notfall-Releases veröffentlicht: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie beheben zwei Fehler in der PHP-Engine, über die ein Angreifer ohne Login Code auf dem Server ausführen kann. Die Forscher, die sie gefunden haben, nennen das Paar PHP2Shell. PHP selbst benutzt den Namen nicht, alle anderen schon, also bleibe ich dabei.

Wenn du einen Shopware-Shop betreibst, lautet die Kurzfassung: Dein Shop-Code spielt hier keine Rolle. Laut Huntress und den PHP-Advisories reicht eine einzige Anfrage ohne Login, um den Angriff auszulösen, bevor überhaupt Anwendungscode läuft. Ein Update von Shopware oder einem Plugin bringt nichts. Ein Update von PHP schon.

Stand: 21. Oktober 2026, abends. Die Lage ändert sich schnell, und mehrere Quellen widersprechen sich noch. Wo das so ist, sage ich es.

Was passiert ist

Forscher von Calif, Wiz und OpenAI haben die Fehler gefunden und gemeldet. Calif schickte PHP die erste Meldung am 11. August und am 14. August einen funktionierenden RCE-Proof-of-Concept, Wiz meldete am 24. August. Wiz sagt, KI-Modelle (genannt werden Gemini 4 Argon und GPT-5.6 Sol) hätten beim Finden der Lücke und beim Bau des Exploits geholfen. Am 20. Oktober gelangten Details an die Öffentlichkeit. Laut Huntress begann es mit einem Beitrag auf Hacker News, der gelöscht wurde, aber nicht bevor Screenshots die Runde machten. PHP veröffentlichte am selben Tag eine Vorankündigung und lieferte den Fix am 21. Oktober um 14:00 UTC aus, einen Tag früher als das ursprüngliche Embargo.

Beide CVEs haben einen CVSS-v4.0-Wert von 9.2. (Im Leak stand 10.0. Diese Zahl kam nicht von PHP.)

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), “RCE via OOM corruption”. Wenn PHP beim Aufbau einer Anfrage der Speicher ausgeht, kann es abbrechen, während ein Teil der Anfragedaten noch nicht initialisiert ist. Das Herunterfahren am Ende der Anfrage liest diese ungültigen Daten dann.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), “RCE via stale global state”. Zustand, der zu einer Anfrage gehört, überlebt die Freigabe seines Speichers, und eine spätere Anfrage auf demselben Worker benutzt ihn, bevor PHP ihn zurücksetzt. Das Advisory bestätigt zwei Wege: Session Upload Progress und unter PHP 8.5 die Backtraces bei Fatal Errors.

Wiz beschreibt alle als Speichersicherheitsfehler im Umgang von PHP mit fatalen Fehlern während einer Anfrage, besonders bei Out-of-Memory-Fehlern. Außerdem lasse sich darüber Prozessspeicher auslesen, auch ohne Codeausführung, “including passwords, tokens, and API keys”.

Wer betroffen ist

Das PHP-Advisory nennt “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed” und sieht das höchste Risiko bei mod_php. Laut Calif reicht der älteste betroffene Codepfad bis PHP 5.4.0 zurück und ist in der Standardkonfiguration ausnutzbar. Wiz schreibt, dass schon eine schlichte “Hello World”-Anwendung auf einer betroffenen PHP-Version verwundbar sein kann.

Bei PHP-FPM sind die Quellen weniger eindeutig. Das GHSA zum OOM-Fehler hält FPM nach Quellcodeanalyse für anfällig, schreibt aber auch: “no complete FPM exploit has been demonstrated”. Der Stale-State-Fehler wurde gegen mod_php und FPM validiert, und Califs Demo-Video zeigt den Exploit gegen nginx mit PHP-FPM.

Calif hat Pre-Auth-RCE gegen Magento 2.4.9 und weitere PHP-Anwendungen bestätigt, Sansec nennt darunter WordPress, Drupal, Joomla, Nextcloud, Laravel 13.11 und Symfony 8.1. Shopware steht nicht auf der Liste. Sansecs Einschätzung: “The flaws are in the PHP engine, so Magento, Shopware and WooCommerce stores are exposed even when their own code is clean.”

Worauf du aktualisieren musst

Branch	Behoben in
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

PHP 8.1 und älter bekommen keine offiziellen Releases. Das PHP-Security-Team hat minimale Quellcode-Backports für 7.4, 8.0 und 8.1 als Branches in php-src veröffentlicht, aber das ist Quellcode, kein Paket zum Installieren. Shopware 6.5 läuft auf PHP 8.1, ein 6.5-Shop auf 8.1 bekommt von PHP also keinen paketierten Fix. Und 8.2 erreicht am 31. Dezember 2026 selbst das Ende des Supports.

Wie du an das Update kommst, hängt davon ab, woher dein PHP stammt:

• Distributionspakete. Linux-Distributionen und LTS-Anbieter haben die Patches vorab bekommen. Sie portieren Fixes in die Version, die sie ausliefern, die Versionsnummer kann also alt aussehen. The Hacker News empfiehlt, wie Debian, das Changelog des Pakets auf die CVE-Nummer zu prüfen statt der Version. Unter Debian oder Ubuntu geht das mit apt changelog <paket> | grep CVE-2026-109618, zum Beispiel für php8.3-fpm.
• Remis Repository (rpms.remirepo.net) hatte laut Sansec und Huntress am 21. Oktober noch keine aktualisierten Pakete.
• Docker-Images und Managed oder Shared Hosting. Du brauchst einen Build, der den Fix enthält. Frag deinen Hoster, wann er kommt, und prüf die Version danach selbst.

Egal auf welchem Weg: Danach PHP-FPM (oder Apache) neu starten und die Version an dem Prozess prüfen, der den Traffic bedient. The Hacker News weist darauf hin, dass php -i auf der Shell das CLI-Binary zeigt, nicht unbedingt das, was FPM ausführt. Eine phpinfo()-Seite, die du direkt danach wieder löschst, schafft Klarheit.

Wenn du heute nicht aktualisieren kannst

Nichts davon ersetzt das Update. Die PHP-Core-Entwickler waren da deutlich: “the only mitigation is patching / upgrading PHP” (Gina Peter Banyard), “ini settings won’t save you” (Joe Ferguson, Release Manager). Die GHSAs nennen trotzdem eine teilweise Härtung für Systeme, die nicht sofort aktualisiert werden können.

Gegen den Stale-State-Fehler: Session Upload Progress in der php.ini oder der FPM-Pool-Konfiguration abschalten und alle Worker neu starten. Laut Advisory ist die Funktion standardmäßig aktiv und braucht kein session_start(). Unter PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen. Das Advisory rät, sich dafür nicht auf ini_set() oder eine FPM-.user.ini zu verlassen.

; php.ini oder FPM-Pool (php_admin_value[...])
session.upload_progress.enabled = 0
; nur PHP 8.5
fatal_error_backtraces = 0

Gegen den OOM-Fehler schlägt PHP memory_limit=-1 vor, am besten als php_admin_value, und zu prüfen, dass keine Pool-, Verzeichnis- oder Anwendungseinstellung wieder ein endliches Limit setzt. Dazu kommen enge Größenlimits für Anfragen: post_max_size = 32M, wenn du Uploads brauchst, sonst 8M, und upload_max_filesize unter post_max_size. Denk daran, dass memory_limit=-1 die Speichergrenze pro Anfrage komplett aufhebt.

Cloudflare hat Notfallregeln in sein Managed Ruleset gepusht, laut CTO Dane Knecht für alle Kunden inklusive Free-Tarif. Cloudflare selbst nennt sie “a STOPGAP only”, und sie greifen nur für Traffic, der über Cloudflare läuft. Der Origin darf also nicht an Cloudflare vorbei erreichbar sein. Wer multipart/form-data am Webserver blockiert, schneidet einen vermuteten Angriffsweg ab, aber Sansec weist darauf hin, dass damit auch Datei-Uploads nicht mehr funktionieren.

Geht nichts davon, rät CERT-EU, aus dem Internet erreichbare Anwendungen bis zum Fix vom öffentlichen Netz zu isolieren, und das britische NCSC, ungepatchte Systeme vom Netz zu nehmen. Sansec merkt an, dass die Wartungsmodi von Magento und WordPress nicht helfen.

Bin ich schon betroffen?

Verlässliche Indicators of Compromise hat noch niemand veröffentlicht. Wiz rät, auf ungewöhnliche Multipart-Anfragen mit anschließenden Memory-Limit-Fehlern oder wiederholten HTTP-500-Antworten zu achten, auf auffällig große oder kaputte PHPSESSID-Cookies in Antworten und auf unerklärliche Neustarts von PHP-Workern. Huntress empfiehlt, auf verdächtige Kindprozesse von php-fpm, php-cgi, httpd oder apache2 zu schauen. Das GHSA warnt, dass fehlende Logeinträge kein Beweis für Sicherheit sind.

Bis heute Abend hat niemand einen erfolgreichen Einbruch bestätigt. Cloudflare sieht nach eigener Aussage erste Angriffe, watchTowr sagt, seine Honeypots hätten Ausnutzung beobachtet, und Huntress hatte bei seinen Partnern bis 10 Uhr ET nichts gesehen. Vor dem Release schrieb The Hacker News, der kursierende öffentliche Exploit-Code habe bisher nicht nachweislich funktioniert. Sansec rechnet mit Massenausnutzung, jetzt wo die Writeups öffentlich sind.

Wegen des Speicherlecks, das Wiz beschreibt, können Zugangsdaten den Server verlassen, ohne dass eine einzige Datei angefasst wird. War dein Shop ungeschützt und siehst du etwas aus der Liste oben, dann tausch nach dem Patch aus, worauf der PHP-Prozess Zugriff hatte: DATABASE_URL und APP_SECRET aus der .env bzw. .env.local sowie die API-Schlüssel deines Zahlungsanbieters und anderer Integrationen.

Quellen: PHP Security Advisory, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, Calif, Wiz, Sansec, Huntress, The Hacker News (vor dem Release), The Hacker News (nach dem Release), Help Net Security, Cloudflare Changelog, Shopware Update-Guide 6.5 auf 6.6.