PHP-Sicherheitslücke PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Jetzt PHP updaten

Normalerweise betreffen Sicherheitslücken eine bestimmte Software: ein Shopsystem, ein Plugin, ein CMS. Diesmal ist es anders. Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619 stecken in PHP selbst – in der Laufzeitumgebung, auf der ein Großteil aller Onlineshops und Websites läuft. Das PHP-Projekt stuft beide als kritisch ein und schreibt in seiner Sicherheitsmeldung unmissverständlich, alle Nutzer sollten „sofort“ aktualisieren.

Brisant ist der Ablauf: Details zu den Lücken sind bereits am 20. Oktober vorzeitig durchgesickert, rund einen Tag vor dem offiziellen Patch. Laut Sansec meldete Cloudflare am Morgen des 21. Oktober erste Angriffe, watchTowr beobachtet Ausnutzungsversuche in seinem Honeypot-Netz. Wir fassen zusammen, was gesichert bekannt ist, wer betroffen ist und was du jetzt tun solltest.

Was ist PHP2Shell?

„PHP2Shell“ ist der Name, unter dem die Entdecker die beiden Lücken veröffentlicht haben. Gefunden wurden sie unabhängig voneinander von mehreren Teams, unter anderem vom Sicherheitsunternehmen Calif und von Wiz Research. Die gute Nachricht: Die Lücken wurden koordiniert gemeldet, die Patches sind da. Die schlechte: Kombiniert ergeben sie eine Angriffskette, mit der sich ein PHP-Server übernehmen lässt, ohne dass ein Benutzerkonto nötig ist.

Die Eckdaten laut den offiziellen PHP-Sicherheitshinweisen:

• Schweregrad: beide kritisch, CVSS v4.0 Base Score 9,2
• Angriff: über das Netzwerk, ohne Anmeldung und ohne Benutzerinteraktion
• Folge: Ausführung von Schadcode auf dem Server (Remote Code Execution) und laut Sicherheitsforschern auch das Auslesen von Speicherinhalten
• Betroffen: alle PHP-Versionen von 5.4 bis 8.5.11 – der fehlerhafte Code ist über zehn Jahre alt
• Behoben in: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21.10.2026
• Ausnutzung: erste Angriffe werden von Sicherheitsfirmen gemeldet; öffentliche technische Analysen sind verfügbar

CVE-2026-109618: Codeausführung durch Speicherfehler

Die erste Lücke betrifft den Umgang von PHP mit Speichermangel (Out of Memory). Geht PHP während einer Anfrage der Speicher aus, bricht es die Verarbeitung abrupt ab. Passiert das in einem ungünstigen Moment, sind interne Daten der Anfrage nur halb initialisiert. Beim anschließenden Aufräumen behandelt PHP diese ungültigen Daten trotzdem als gültig – und genau das lässt sich ausnutzen.

Ausgelöst wird der Fehler über speziell präparierte Formular-Uploads (sogenannte Multipart-Anfragen), die PHP verarbeitet, bevor überhaupt Code deiner Anwendung läuft. Das PHP-Projekt hat eine Codeausführung ohne Login gegen Apache mit mod_php in der Standardkonfiguration bestätigt. PHP-FPM, FrankenPHP und LSAPI gelten als in unterschiedlichem Maß anfällig. Laut Sansec kann die Lücke außerdem Speicherinhalte anderer Anfragen in einem Session-Cookie zurückliefern – ähnlich wie seinerzeit Heartbleed. Darin können Passwörter, Session-Token oder API-Schlüssel stecken.

CVE-2026-109619: Zugriff auf bereits freigegebenen Speicher

Die zweite Lücke betrifft Daten, die ein PHP-Prozess über mehrere Anfragen hinweg vorhält. Endet eine Anfrage mit einem schweren Fehler – etwa durch Speichermangel oder ein Zeitlimit –, wird dieser Zustand nicht sauber zurückgesetzt. Die nächste Anfrage, die derselbe Prozess bearbeitet, greift dann auf Speicher zu, der eigentlich schon freigegeben ist (ein sogenannter Use-after-free). Mit gezielt vorbereiteten Anfragen lässt sich auch das bis zur Codeausführung treiben.

Bestätigte Angriffswege laufen über die Funktion Session Upload Progress und über das in PHP 8.5 neue Feature fatal_error_backtraces. In Kombination mit CVE-2026-109618 entsteht so die Angriffskette, die der Lücke ihren Namen gibt.

Bin ich betroffen? Shopware, Magento, WordPress und Co.

Kurz gesagt: Wenn auf deinem Server eine PHP-Version vor den oben genannten Patch-Versionen läuft, ja. Weil der Fehler in der Laufzeitumgebung steckt, spielt es keine Rolle, wie sauber dein Shop programmiert ist oder ob alle Plugins aktuell sind. Sansec nennt ausdrücklich unter anderem Magento, WordPress, Drupal, Joomla, Nextcloud, phpMyAdmin, Laravel und Symfony als ohne Login angreifbar – und weist darauf hin, dass auch Shopware- und WooCommerce-Shops betroffen sind.

Für Shopbetreiber heißt das konkret:

• Shopware 6: betroffen, solange PHP nicht aktualisiert ist. Ein Shopware-Update allein hilft nicht – das Update muss auf Server-Ebene passieren.
• Shopware 5: besonders kritisch, weil ältere Installationen oft noch mit PHP 7.4, 8.0 oder 8.1 laufen. Für diese Versionen gibt es keinen Patch.
• Magento und Adobe Commerce: ebenfalls betroffen. Wer gerade erst die Magento-Lücke CVE-2026-103849 gepatcht hat, muss jetzt zusätzlich PHP aktualisieren. Das gilt genauso für Hyvä-Shops.
• WordPress, WooCommerce und eigene Anwendungen: betroffen, sobald PHP im Spiel ist – auch interne Tools, Staging-Systeme und Agentur-Demos.

PHP 8.1 und älter: Es gibt keinen Patch

PHP 8.1 hat sein Lebensende bereits erreicht, PHP 7 und 5 erst recht. Das PHP-Projekt liefert für diese Versionen keine Sicherheitsupdates mehr. Wer noch auf einer solchen Version läuft, hat nur zwei Möglichkeiten: auf eine unterstützte Version aktualisieren oder sich auf Backports seines Linux-Distributors bzw. Hosters verlassen, sofern diese angeboten werden.

Und auch PHP 8.2 hat nicht mehr viel Zeit: Laut PHP-Projekt erhält die Version nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr. Wer jetzt ohnehin anfassen muss, sollte das Upgrade auf PHP 8.3 oder 8.4 gleich mitplanen.

Sofort handeln: PHP-Version prüfen und aktualisieren

Das PHP-Projekt ist in diesem Punkt eindeutig: Es gibt keine vollständige Abhilfe per Konfiguration, das Update ist der einzige sichere Weg. Gehe so vor:

1. Alle PHP-Systeme erfassen

Mache eine Liste aller Server und Umgebungen, auf denen PHP läuft – nicht nur den Live-Shop. Gerade Staging-, Test- und Demo-Instanzen sind häufig öffentlich erreichbar, werden aber deutlich seltener gepflegt. Dazu kommen Container-Images, die PHP fest einbauen.

2. Die tatsächlich genutzte PHP-Version ermitteln

Achtung: Die PHP-Version auf der Kommandozeile ist nicht zwingend die, mit der dein Webserver arbeitet. Prüfe deshalb beide:

1php -v
2php-fpm -v
Copy

Je nach Distribution heißt der FPM-Befehl auch php-fpm8.3 oder ähnlich. Bei Managed Hosting findest du die Version meist im Kundenmenü. Sicher bist du nur bei 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer.

3. Update einspielen und alle PHP-Prozesse neu starten

• Eigener Server: Pakete deines Distributors bzw. des genutzten Paket-Repositories aktualisieren. Prüfe, ob dein Repository die gepatchte Version schon anbietet – nicht alle Quellen ziehen am selben Tag nach.
• Managed Hosting: Frage aktiv bei deinem Hoster nach, ob die gepatchten Versionen bereits ausgerollt sind, und stelle im Kundenmenü auf eine unterstützte PHP-Version um.

Dass es auch schnell geht, zeigt unser Hosting-Partner maxcluster: Das Team hat proaktiv reagiert und alle Systeme innerhalb einer Stunde nach Veröffentlichung der Patches aktualisiert. So sieht Managed Hosting aus, wenn es darauf ankommt.

• Docker und Container: Basis-Images aktualisieren, Images neu bauen und neu deployen. Ein laufender Container aktualisiert sich nicht von selbst.

Wichtig: Nach dem Update PHP-FPM bzw. Apache neu starten, damit wirklich alle Prozesse die neue Version nutzen. Prüfe anschließend erneut die Version.

4. Shop testen

Ein PHP-Patch-Release innerhalb derselben Versionslinie (z. B. 8.3.x auf 8.3.36) ist in der Regel unproblematisch. Teste trotzdem die kritischen Wege: Checkout, Login, Formulare, Uploads im Admin. Wer dagegen von PHP 8.1 oder älter auf eine neue Version springt, sollte das vorher auf Staging prüfen – hier können Plugins und Erweiterungen inkompatibel sein.

Wenn du nicht sofort patchen kannst: Notfall-Maßnahmen

Kann das Update nicht sofort eingespielt werden, lassen sich die bekannten Angriffswege vorübergehend eindämmen. Alle Maßnahmen sind unvollständig und ersetzen den Patch nicht – sie verschaffen dir nur Zeit.

Gefährdete PHP-Funktionen abschalten

Die folgenden Einstellungen gehören in die php.ini bzw. in die Konfiguration des FPM-Pools – nicht in .htaccess, .user.ini oder per ini_set(). Laut Sicherheitsforschern können per .htaccess oder PHP_VALUE gesetzte Werte sogar selbst einen Angriffsweg öffnen. Danach müssen alle PHP-Prozesse neu gestartet werden.

1; php.ini – danach alle PHP-Worker neu starten
2session.upload_progress.enabled = 0
3
4; nur PHP 8.5:
5fatal_error_backtraces = 0
Copy

Im FPM-Pool sieht das so aus:

1; z. B. /etc/php/8.4/fpm/pool.d/www.conf
2php_admin_flag[session.upload_progress.enabled] = off
3php_admin_flag[fatal_error_backtraces] = off
Copy

Multipart-Anfragen am Webserver blockieren

Alle bekannten Auslöser von CVE-2026-109618 sind Multipart-Anfragen. Wer sie am Webserver abweist, schließt den Hauptangriffsweg – bricht damit aber alle Datei-Uploads, etwa Produktbilder im Shop-Admin, und unter Umständen auch einzelne Formulare oder Checkout-Schritte. Teste nach der Änderung unbedingt eine Bestellung. Für nginx:

1# im http-Block
2map $http_content_type $block_multipart {
3    default       0;
4    "~*multipart" 1;
5}
6
7# in jedem server-Block, der an PHP weiterreicht
8if ($block_multipart) {
9    return 403;
10}
Copy

Für Apache 2.4:

1<If "req('Content-Type') =~ /multipart/i">
2    Require all denied
3</If>
Copy

Ein vorgeschalteter CDN- oder WAF-Filter hilft nur, wenn der Server direkte Zugriffe am CDN vorbei ablehnt.

Weitere Maßnahmen und was nicht hilft

Das PHP-Projekt nennt weitere Stellschrauben, etwa konservative Werte für post_max_size, Limits für Eingabevariablen und Uploads oder pm.max_requests = 1 in PHP-FPM, damit jeder Prozess nur eine Anfrage bearbeitet (kostet Performance). Das Abschalten des Speicherlimits mit memory_limit = -1 wird ebenfalls als Teilmaßnahme genannt, ist aber nur mit einem Speicherlimit auf Container- oder Systemebene vertretbar.

Nicht ausreichend sind dagegen: Fehlermeldungen auszublenden, file_uploads = Off zu setzen, Prüfungen in der Anwendung oder der Wartungsmodus von Shopware, Magento oder WordPress – denn PHP verarbeitet die gefährliche Anfrage, bevor die Anwendung überhaupt startet. Und Vorsicht beim „Abschalten“ von PHP am Webserver: Dann liefert er unter Umständen deine PHP-Dateien samt Zugangsdaten als Klartext aus.

Nach dem Update: Auf Spuren eines Angriffs prüfen

Weil die Lücken schon vor dem Patch bekannt wurden und erste Angriffe gemeldet sind, solltest du nach dem Update genauer hinschauen:

• Logs prüfen: ungewöhnlich viele Multipart-Anfragen an PHP-Endpunkte, gehäufte Speicherfehler („Allowed memory size exhausted“) oder abgestürzte PHP-Prozesse seit dem 20. Oktober
• Server prüfen: unbekannte PHP-Dateien im Webroot, neue Cronjobs, PHP-Prozesse, die Shells oder Download-Tools starten
• Shop prüfen: fremde Skripte auf Checkout- und Zahlungsseiten, unbekannte Admin-Konten oder Integrationen

Ein unauffälliges Log ist kein Beweis, dass nichts passiert ist. Da die Lücke laut Sicherheitsforschern auch Speicherinhalte preisgeben kann, empfehlen wir bei öffentlich erreichbaren Systemen, die wichtigsten Zugangsdaten zu rotieren: Admin-Passwörter, API-Schlüssel von Zahlungs- und Versanddienstleistern, Datenbank-Zugänge und Integrations-Token. Findest du konkrete Spuren, geht es um forensische Aufarbeitung und gegebenenfalls Meldepflichten nach DSGVO.

Was PHP2Shell über den Betrieb von Shops lehrt

Viele Shopbetreiber haben Shopware- oder Plugin-Updates im Blick – die Server-Ebene darunter läuft oft „einfach mit“. PHP2Shell zeigt, warum das riskant ist. Drei Punkte machen in der Praxis den Unterschied:

1. Unterstützte Versionen fahren: Wer auf PHP 8.1 oder älter festhängt, bekommt bei der nächsten kritischen Lücke schlicht keinen Patch. Ein geplanter Versionsplan ist günstiger als ein Notfall-Upgrade.
2. Klare Zuständigkeit: Es muss feststehen, wer PHP-Updates einspielt – Hoster, Agentur oder eigenes Team. Worauf es dabei ankommt, haben wir in Performance & Sicherheit: Was professionelles Hosting leisten muss zusammengefasst, und warum Sparen hier teuer wird, in Die Risiken von Billig-Hosting.
3. Reaktionsfähigkeit: Zwischen Leak und erster Angriffswelle lagen hier nur Stunden. Ein Managed-Hosting-Partner mit Monitoring, Firewall und eingespieltem Update-Prozess verschafft dir genau die Zeit, die du sonst nicht hast – bei PHP2Shell hat maxcluster seine Systeme binnen einer Stunde gepatcht.

Unterstützung beim PHP-Update und im laufenden Betrieb

Wir betreuen Shopware-Shops, Magento- und Hyvä-Shops sowie individuelle PHP-Anwendungen mit Symfony und WordPress und spielen Sicherheitsupdates mit Staging-Test und Rollback-Plan ein. Wenn du unsicher bist, wie es um deinen Shop steht, prüfen wir im Shop-Health-Check PHP-Version, Patchstand, Erweiterungen und Hosting. Für langfristig stabilen Betrieb findest du unter Hosting & Infrastruktur unsere Betriebsmodelle.

Akuter Handlungsbedarf? Melde dich direkt bei uns – wir prüfen kurzfristig, ob dein Shop betroffen ist, und spielen das Update ein.