PHP2Shell: PHP-Sicherheitslücke gefährdet deinen PrestaShop-Shop

Am 20. Oktober tauchte eine Warnung auf, die halb das Internet in Atem hielt: zwei schwere Sicherheitslücken in PHP, der Sprache, mit der dein PrestaShop-Shop läuft. Über sie kann ein Fremder ohne Benutzername und Passwort die Kontrolle über deinen Server übernehmen. Sie laufen unter dem Namen PHP2Shell. PHP hat den Patch am 21. Oktober veröffentlicht, und was du tun musst, hängt von einer einzigen Sache ab: der PHP-Version, auf der dein Shop läuft.

Wir erklären es ohne Fachchinesisch: was passiert ist, wie du erkennst, ob es dich betrifft, was du heute tun solltest und wie du erfährst, ob dein Hoster den Patch schon eingespielt hat.

Was ist PHP2Shell, und warum ist die Lücke so gefährlich?

PHP ist der Motor unter PrestaShop, WordPress, Magento und den meisten Shops und Websites der Welt. Die beiden Lücken, geführt als CVE-2026-109618 und CVE-2026-109619, haben einen Schweregrad von 9,2 von 10. In der Praxis heißt das: Wer sie auszunutzen weiß, kann auf deinem Server ausführen, was er will. Eine Hintertür hinterlassen, die Daten deiner Kunden stehlen oder ein falsches Captcha wie das von ClickFix in deinen Shop einbauen.

Anders als bei anderen Warnungen läuft der Angriff weder über PrestaShop noch über ein Modul. Er passiert in PHP, bevor dein Shop den Besuch überhaupt zu sehen bekommt. Egal wie gut du ihn pflegst: Ist das PHP auf dem Server angreifbar, ist es dein Shop auch.

Und die Informationen waren vorzeitig durchgesickert. Die Sicherheitsfirma Sansec berichtet, dass zusammen mit der Warnung ein Screenshot eines fertigen Angriffswerkzeugs aufgetaucht ist, und rechnete mit massenhaften Angriffen, sobald der Patch veröffentlicht würde. Laut derselben Quelle hatte Cloudflare die ersten Versuche bereits gesehen und Regeln eingerichtet, um sie abzufangen.

Ist mein PrestaShop-Shop betroffen?

Höchstwahrscheinlich ja. In seiner Sicherheitswarnung stuft PHP jede Installation als gefährdet ein, die Webseiten ausliefert, ganz gleich, wie der Server PHP ausführt, und sieht das höchste Risiko bei Apache-Servern mit mod_php: Dort ist bereits ein Angriff nachgewiesen, der ohne Benutzername und Passwort funktioniert. Sansec spricht von jedem Server mit PHP 5.4 oder neuer, in der Praxis also jedem PrestaShop-Shop, der heute online ist.

Die Frage, auf die es wirklich ankommt, ist eine andere: Bekommst du den Patch überhaupt? PHP hat die Lücken in den Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 geschlossen. Für die alten Versionen ohne offiziellen Support hat PHP den Patch ohne neue Version veröffentlicht, und innerhalb von ein, zwei Tagen haben die Panels und Systeme der Hoster daraus ein normales Update gemacht: cPanel und CloudLinux von PHP 5.2 bis 8.1; DirectAdmin, Ubuntu, Red Hat, AlmaLinux und das Remi-Repository für die Versionen 7.4 bis 8.1, die sie noch pflegen. Und jede PrestaShop-Version läuft nur mit bestimmten PHP-Versionen:

• PrestaShop 1.6: läuft mit PHP 5.6 bis 7.1. Einen Patch gibt es, wenn dein Hoster cPanel oder CloudLinux nutzt; sonst nur über kostenpflichtigen Extended Support wie den von TuxCare oder Zend.
• PrestaShop 1.7: höchstens PHP 7.4. Ein gepatchtes 7.4 gibt es schon in fast allen Panels: Dein Hoster muss es nur installieren.
• PrestaShop 8: höchstens PHP 8.1. Wie bei 1.7: Ein gepatchtes 8.1 gibt es schon, es hängt an deinem Hoster.
• PrestaShop 9: läuft mit PHP 8.1 bis 8.4. Ab PHP 8.2 bekommt er das offizielle Update; läuft er auf 8.1, reicht es, PHP zu aktualisieren.

Anders gesagt: Fast jeder Shop kann heute auf einem PHP ohne diese Lücke laufen. Ist es aber nicht PrestaShop 9, hängt es davon ab, ob dein Hoster den Patch eingespielt hat, und weil sich die Versionsnummer nicht ändert, sieht man es nicht auf den ersten Blick: Du musst ihn fragen. Außerdem ist es ein Notfall-Patch: PHP 8.1 und älter haben keinen offiziellen Support mehr, bei der nächsten Lücke hängst du also wieder davon ab, dass jemand sie auf eigene Faust behebt.

So findest du heraus, welche Version du hast

Melde dich im Backoffice deines Shops an und öffne Erweiterte Einstellungen → Informationen. Dort siehst du die PrestaShop-Version und etwas weiter unten die PHP-Version. Mit diesen beiden Zahlen weißt du, welcher Fall auf dich zutrifft.

Was du heute tun solltest, der Reihe nach

1. Sieh dir deine beiden Versionen an, PrestaShop und PHP, wie oben beschrieben.
2. Erstelle ein vollständiges Backup, Dateien und Datenbank, und bewahre es außerhalb des Servers auf. Wenn etwas passiert, ist es das Einzige, mit dem du zurückkommst.
3. Ist dein Shop ein PrestaShop 9, bitte deinen Hoster, PHP auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 oder neuer zu aktualisieren, oder mach es selbst im Hosting-Panel, wenn du dort die Version wählen kannst. Bist du auf PHP 8.1, wechsle bei der Gelegenheit gleich auf 8.3 oder 8.4.
4. Nutzt du Cloudflare, prüfe, ob die Wolke bei deiner Domain orange ist: Dann läuft der Verkehr durch die Regeln von Cloudflare, bevor er deinen Server erreicht. Das bringt wenig, wenn die Adresse deines Servers bekannt ist und er Besuche von überall annimmt. Bitte deinen Techniker deshalb, ihn nur für Cloudflare zu öffnen.
5. Läuft dein Shop auf 1.6, 1.7 oder 8, frag deinen Hoster, ob er den PHP2Shell-Patch für deine PHP-Version schon eingespielt hat. Wenn nicht, lass dir von deinem Techniker die Sofortmaßnahmen einrichten, die wir unten beschreiben. Und setz einen Termin für das Update auf PrestaShop 9: Nur so kommst du wieder auf ein PHP mit offiziellem Support.

Den Shop im Backoffice in den Wartungsmodus zu versetzen, schützt dich diesmal nicht: PHP liest den Besuch, bevor PrestaShop entscheidet, die Wartungsseite anzuzeigen.

Und wenn mein Hoster den Patch nicht hat?

PHP schlägt einige Servereinstellungen vor, die manche Angriffswege schließen, und weist darauf hin, dass sie den Shop nicht sicher machen: Das schafft nur das Update. Sansec nennt eine weitere Notmaßnahme: Auf dem Server wird die Art von Übertragung gesperrt, mit der Dateien auf eine Website hochgeladen werden. Das hat einen Preis: Solange sie aktiv ist, kann niemand Dateien in deinen Shop hochladen. Weder du die Fotos eines neuen Produkts noch deine Kunden einen Anhang im Kontaktformular. Verkaufen kann der Shop ganz normal weiter.

Das verschafft dir ein paar Tage, mehr nicht: Entweder spielt dein Hoster den Patch ein, oder du wechselst zu einem, der ihn hat. Und bei der nächsten PHP-Lücke – und es wird sie geben – hängt dein Shop wieder davon ab, denn PHP 8.1 und älter haben keinen offiziellen Support mehr.

Welche PHP-Version jede PrestaShop-Version unterstützt und wie lange sie Patches bekommt, steht in einer Tabelle unter welche PHP-Version für PrestaShop.

Lohnt es sich, PrestaShop jetzt zu aktualisieren?

Es ist die Frage, die man immer verschiebt, weil der Shop ja läuft. PHP2Shell zeigt, was passiert, wenn man sie zu lange verschiebt: Den Tag, an dem das Problem kommt, suchst du dir nicht aus, und ob der Patch bei dir ankommt, hängt von anderen ab.

Mit PrestaShop 9 bist du auf einem PHP, das noch jahrelang Sicherheitsupdates bekommt. Die Umstellung läuft, ohne dass du den Shop schließt, du nimmst Produkte, Kunden, Bestellungen und deine Google-Rankings mit, und ein kleiner Shop kostet ab 690 €. Alles dazu steht in PrestaShop 1.7 oder 1.6 auf 9 aktualisieren und auf unserer Seite zur Migration von PrestaShop 1.6 und 1.7 auf 9.

Und wenn du solche Warnungen nicht selbst im Blick behalten willst, ist genau dafür die PrestaShop-Wartung da: Wir überwachen deinen Shop, halten seine Module aktuell und, wenn er auf einem BK Modules Server läuft, auch PHP, damit dich eine solche Warnung nicht unvorbereitet trifft.

Brauchst du heute Hilfe?

Wenn du nicht weißt, welcher Fall auf dich zutrifft, wenn dein Hoster nicht antwortet oder wenn dein Shop ein 1.6, 1.7 oder 8 ist und du da rauswillst: Schick uns deine PrestaShop- und deine PHP-Version. Wir sagen dir, was du heute tun solltest, und wenn nötig bekommst du einen Festpreis für die Umstellung auf PrestaShop 9.

Ich will meinen Shop aktualisieren

Für dein technisches Team

Gepatchte Versionen: 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für 7.4, 8.0 und 8.1 veröffentlicht PHP den Minimal-Patch als Quellcode, verlinkt in seinem Advisory, ohne neue Version. Gepatchte Pakete behalten ihre Versionsnummer, php -v unterscheidet sie also nicht: Maßgeblich ist die Paket-Revision (rpm -q, dpkg -l). Gepatchte Revisionen: cPanel EasyApache 4 ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5; CloudLinux ea-php / alt-php 5.2–8.5 (21–22/10); Remi 7.4.33-31, 8.0.30-21, 8.1.34-6; Ubuntu 22.04 8.1.2-1ubuntu2.28. Die Teilmaßnahmen von PHP gehören in die php.ini, in den PHP-FPM-Pool (php_admin_value) oder in die Serverkonfiguration, nie per ini_set() oder .user.ini, und alle Prozesse neu starten:

; CVE-2026-109618
memory_limit = -1
post_max_size = 32M   ; 8M, wenn keine Dateien hochgeladen werden
; CVE-2026-109619
session.upload_progress.enabled = 0
; nur in PHP 8.5
fatal_error_backtraces = 0

PHP rät davon ab, memory_limit durch Systemlimits (RLIMIT_AS, RLIMIT_DATA) zu ersetzen. Die Maßnahme von Sansec, multipart/form-data zu blockieren (blockiert alle Datei-Uploads, auch im Backoffice), unter Apache:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Unter Nginx:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Mit Cloudflare den Port 443 des Origin-Servers auf deren IP-Bereiche beschränken; sonst geht der Angriff direkt an die IP des Servers.