PHP-Sicherheitslücke PHP2Shell: Was Shopbetreiber mit alter PHP-Version jetzt tun müssen

Stand: 22. Oktober 2026

Die kurze Antwort

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die unter dem Namen PHP2Shell bekannt sind. Angreifer können damit ohne Login Code auf dem Server ausführen. Gepatcht sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Wer PHP 8.1 oder älter einsetzt, bekommt kein reguläres Update, sondern nur minimale Quellcode-Patches. Für Shopbetreiber heißt das: PHP-Version prüfen, sofort patchen lassen und den Update-Rückstand abbauen, bevor die nächste Lücke kommt.

Was ist PHP2Shell?

PHP2Shell ist der Name für zwei Sicherheitslücken im Kern von PHP, die als CVE-2026-109618 und CVE-2026-109619 geführt werden. Beide sind mit einem CVSS-Wert von 9,2 als kritisch eingestuft. Sie entstehen, wenn PHP bei Speicherfehlern oder fatalen Fehlern Daten aus einer Anfrage nicht sauber aufräumt. Eine präparierte Anfrage reicht dann, um Schadcode auf dem Server auszuführen.

Entdeckt hat die Lücken das Sicherheitsunternehmen Wiz, das sie im August an das PHP-Team gemeldet hat. Die Lücke hängt außerdem nicht vom Code deines Shops ab. Selbst eine leere PHP-Seite ist angreifbar, solange die PHP-Version betroffen ist. Laut CERT-EU kursieren bereits Proof-of-Concept-Exploits. Mehrere Einrichtungen in Deutschland, darunter DENIC und die Universität Hamburg, haben deshalb Websites vorsorglich vom Netz genommen.

Welche PHP-Versionen sind betroffen?

Betroffen ist praktisch jede PHP-Version der letzten zehn Jahre. Wiz hat mindestens eine der Lücken in allen Versionen bis zurück zu PHP 5.4 nachgewiesen. Laut PHP-Advisory sind alle Installationen gefährdet, die Web-Anfragen beantworten, egal ob über mod_php, PHP-FPM, php-cgi, FrankenPHP oder LiteSpeed. Am höchsten ist das Risiko bei mod_php.

Entscheidend ist deshalb, ob die PHP-Version deines Shops schon einen Patch bekommen hat.

Welche PHP-Versionen wurden gepatcht?

Das PHP-Team hat am 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Angekündigt wurde das Release erst einen Tag vorher, am 20. Oktober. Wer eine dieser vier Versionsreihen nutzt, kommt mit einem normalen Patch-Update auf den sicheren Stand.

Auf php.net betont das PHP-Team, dass es keine vollständige Abhilfe ohne Update gibt. Viele Linux-Distributionen haben ihre Pakete bereits vorab erhalten und rollen sie aus. Frag deinen Hoster, ob die gepatchten Pakete auf deinem Server installiert und die PHP-Prozesse neu gestartet sind. Ohne Neustart läuft weiter die alte Version.

Was gilt für PHP 8.1, 8.0 und 7.4, die kein Update mehr bekommen?

Für PHP 8.1 und älter veröffentlicht das PHP-Projekt keine regulären Updates mehr. Das Sicherheitsteam hat für 7.4, 8.0 und 8.1 nur minimale Quellcode-Patches auf GitHub bereitgestellt. Sie richten sich an alle, die PHP selbst kompilieren. Einige Distributionen und Anbieter von Langzeit-Support liefern eigene Patches.

Bis zum Release war unklar, ob es für diese Versionen überhaupt etwas geben würde. Hoster und Agenturen mussten deshalb mit dem schlechtesten Fall planen: einer kritischen Lücke ohne Patch, auf Servern, deren PHP-Version sich nicht von heute auf morgen anheben lässt. Dass es am Ende Patches gab, war keine Selbstverständlichkeit. Beim nächsten Mal kann das anders aussehen.

Die Vorbereitung erschwert auch, wie solche Lücken in der PHP-Welt kommuniziert werden. Das Update wird vorab angekündigt und als kritisch markiert, Details zur Lücke und zu den betroffenen Versionen bleiben aber bis zur Veröffentlichung unter Verschluss. Das hält Angreifer im Dunkeln. Für alle, die Shops betreuen, heißt es aber auch: planen ohne vollständige Informationen. Am 21. Oktober kursierten den ganzen Tag über Gerüchte, die sich am Ende nur teilweise bestätigt haben.

Warum kann man die PHP-Version nicht einfach aktualisieren?

Der Wechsel auf eine neuere PHP-Version, etwa von 8.1 auf 8.3, ist kein Knopfdruck. Jede neue Versionsreihe entfernt alte Funktionen und verhält sich in Details anders. Plugins, Eigenentwicklungen und Schnittstellen, die mit PHP 8.1 laufen, können unter 8.2 oder 8.3 Fehler werfen oder still falsche Ergebnisse liefern. Ohne Test riskierst du, dass der Checkout oder die ERP-Anbindung ausfällt.

Dazu kommt die Shop-Software selbst. Jede Shopware-Version unterstützt nur bestimmte PHP-Versionen. Ist der Shop zu alt, muss erst Shopware aktualisiert werden, bevor PHP folgen kann. Aus einem Sicherheitsupdate wird dann ein kleines Projekt mit Testphase, und genau dafür fehlt in einer akuten Lage die Zeit.

Ist mein Shopware-Shop betroffen?

Jeder Shopware-Shop läuft auf PHP und ist damit grundsätzlich betroffen. Wie schnell er sicher wird, hängt von der Kombination aus Shopware- und PHP-Version ab. Laut endoflife.date unterstützen Shopware 6.7 und 6.6 PHP 8.2 bis 8.5. Diese Shops brauchen nur das Patch-Update von PHP.

Shopware 6.5 läuft auch auf PHP 8.2 und 8.3. Wer dort noch auf PHP 8.1 steht, hat einen vergleichsweise kurzen Weg, muss Plugins und Eigenentwicklungen aber trotzdem testen. Schwieriger wird es bei Shopware 6.4 und Shopware 5: Dort ist die Plattform selbst nicht mehr im Support. Für Shopware-5-Shops führt der Weg mittelfristig nur über eine Migration auf Shopware 6.

Wie lief der Patch-Tag bei den Shops, die wir betreuen?

Von den neun Shops, die wir betreuen, liefen acht auf PHP 8.4 oder 8.3 und damit auf Versionen mit regulärem Support. Für sie war der 21. Oktober ein ruhiger Tag: Wir wussten zu jedem Zeitpunkt, dass ein Patch kommt und die Hoster sich darum kümmern. Ein Shop lief auf PHP 8.0. Für ihn mussten wir bis zuletzt davon ausgehen, dass es keinen Patch geben würde.

Der Ablauf in deutscher Zeit: Gegen 15:30 Uhr wurden die Lücken veröffentlicht, gegen 16:00 Uhr folgten die Patches. In dieser halben Stunde haben die meisten Hoster die Seiten ihrer Kunden vorsorglich vom Netz genommen, auch bei unseren Shops. Gegen 19:30 Uhr waren alle Shops bis auf einen wieder erreichbar. Der letzte lag bei einem Hoster, der nicht zu unseren bevorzugten Partnern gehört, und war spätestens gegen 23:30 Uhr wieder online.

Beim Shop auf PHP 8.0 haben wir versucht, den Betreiber zu erreichen und Maßnahmen abzustimmen. Gegen 20:30 Uhr hat der Hoster auch diesen Shop gepatcht. Das ging gut aus, weil es entgegen den Erwartungen Quellcode-Patches für 8.0 gab. Der Unterschied zwischen den acht entspannten Shops und dem einen kritischen war allein die PHP-Version.

Was sollten Shopbetreiber jetzt tun?

Finde zuerst heraus, welche PHP-Version dein Shop nutzt. Das sagt dir dein Hoster oder deine Agentur. Läuft eine der vier gepatchten Versionsreihen, sorge dafür, dass das Update heute eingespielt und PHP neu gestartet wird. Bei PHP 8.1 oder älter klär mit deinem Hoster, ob ein Backport installiert werden kann.

Danach gehört der Update-Pfad auf den Plan: Welche PHP-Version ist das Ziel, braucht es dafür ein Shopware-Update, welche Plugins müssen geprüft werden? Wer eine Agentur hat, sollte diese Fragen jetzt stellen und nicht erst bei der nächsten Lücke.

Was hilft, wenn das Update nicht sofort möglich ist?

Es gibt Teilmaßnahmen, die das Risiko senken, aber nicht beseitigen. Das PHP-Team und CERT-EU nennen unter anderem einen niedrigeren Wert für post_max_size, das Abschalten von session.upload_progress.enabled und Größenlimits für Anfragen auf Webserver- oder Proxy-Ebene. Unter PHP 8.5 kommt fatal_error_backtraces=0 hinzu.

Diese Einstellungen können Funktionen deines Shops beeinflussen, etwa Datei-Uploads im Backend. Sie sind eine Brücke für Stunden oder wenige Tage, kein Ersatz für das Update. CERT-EU empfiehlt für Systeme, die sich nicht patchen lassen, im Zweifel die Trennung vom öffentlichen Netz. Für einen Onlineshop heißt das im schlimmsten Fall: Wartungsmodus, bis der Patch drauf ist.

Ist PHP damit unsicher oder veraltet?

Nein. Kritische Lücken gibt es in jeder großen Software, und das PHP-Team hat in diesem Fall schnell und koordiniert reagiert: Vorankündigung, Patches für alle unterstützten Versionen und sogar Quellcode-Patches für drei Versionen außerhalb des Supports. PHP wird weiter aktiv entwickelt, PHP 8.5 erhält Sicherheitsupdates bis Ende 2029.

Das Risiko liegt bei alten Versionen, die niemand mehr aktualisiert. Genau dort setzen Angreifer an, sobald eine Lücke öffentlich ist.

Wie verhindert man, beim nächsten Mal wieder unter Druck zu geraten?

Mit einem Minimum an laufender Wartung. Wer PHP und Shopware regelmäßig in kleinen Schritten aktualisiert, steht bei einer neuen Lücke nicht vor der Wahl zwischen „ungepatcht bleiben“ und „riskantes Update unter Zeitdruck“. Dann ist der Patch ein Routine-Update, das sich schnell einspielen lässt.

Konkret heißt das: Halte deine PHP-Version innerhalb des offiziellen Supports, plane Shopware-Updates fest ein und sorge für ein Testsystem, auf dem sich Updates vorher prüfen lassen. Was dazu gehört, beschreiben wir in unseren Artikeln zur laufenden Wartung nach dem Go-live und dazu, was ein gutes Shopware-Setup ausmacht. Wie viel Budget du dafür einplanen solltest, zeigt unsere Übersicht, was laufende Wartung kostet. Mit Monitoring und Alerting bemerkst du außerdem früh, wenn auf deinem Server etwas Ungewöhnliches passiert.

Welche PHP-Frist steht als Nächstes an?

Am 31. Dezember 2026 endet der Sicherheitssupport für PHP 8.2. Ab dann gilt für 8.2 dasselbe wie heute für 8.1: keine regulären Updates mehr, auch nicht bei der nächsten kritischen Lücke. Laut php.net bekommt PHP 8.3 noch bis Ende 2027 Sicherheitsupdates, 8.4 bis Ende 2028.

Wer heute auf PHP 8.2 aktualisiert, um PHP2Shell zu schließen, hat also gut zwei Monate Ruhe. Sinnvoller ist es, gleich auf PHP 8.3 oder 8.4 zu gehen, sofern Shopware-Version und Plugins das zulassen.

Wie wir dich unterstützen können

Wir bei datrycs prüfen PHP- und Shopware-Versionen, testen Updates auf einem Staging-System und spielen sie kontrolliert ein. Wenn du nicht sicher bist, wie dein Shop gerade dasteht, schreib uns über das Kontaktformular unten auf dieser Seite. Wir sagen dir ehrlich, was jetzt nötig ist und was warten kann.