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

Dein Onlineshop · 7 Min. Lesezeit · Aktualisiert am 21/10/2026

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 dir ohne Fachchinesisch: was passiert ist, wie du erkennst, ob du betroffen bist, was du heute tun solltest und was, wenn dein Shop auf einer Version läuft, die den Patch nicht bekommt.

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. PHP 8.1 und älter bekommen keine offiziellen Updates mehr: Für 7.4, 8.0 und 8.1 stellt PHP einen Minimal-Patch bereit, der von Hand kompiliert werden muss, und einige Anbieter von Extended Support übernehmen ihn in ihre Pakete. Und jede PrestaShop-Version läuft nur mit bestimmten PHP-Versionen:

  • PrestaShop 1.6: läuft mit PHP 5.6 bis 7.1. Kein Patch.
  • PrestaShop 1.7: höchstens PHP 7.4. Kein offizielles Update; nur für 7.4 gibt es den Minimal-Patch zum Selbstkompilieren.
  • PrestaShop 8: höchstens PHP 8.1. Kein offizielles Update; auch den Minimal-Patch für 8.1 muss man von Hand kompilieren.
  • PrestaShop 9: läuft mit PHP 8.1 bis 8.4. Ab PHP 8.2 bekommt er das Update; läuft er auf 8.1, reicht es, PHP zu aktualisieren.

Anders gesagt: Ist dein Shop kein PrestaShop 9, gibt es kein offizielles Update, das du einspielen kannst, weil deine PrestaShop-Version mit keinem PHP läuft, das es hat. Bleibt der Minimal-Patch: Das ist Arbeit für einen Techniker, und vor der nächsten Lücke schützt er dich auch nicht.

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. Ist dein Shop ein 1.6, 1.7 oder 8, frag deinen Hoster, ob er den Patch für deine PHP-Version einspielt, bitte deinen Techniker um die Notmaßnahmen, die wir weiter unten beschreiben, und setz dir einen Termin für das Update auf PrestaShop 9. Nur so bekommst du wieder ein PHP mit Sicherheitsupdates.

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 Shop den Patch nicht bekommen kann?

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.

Damit gewinnst du ein paar Tage, mehr nicht. Bei der nächsten PHP-Lücke – und die kommt – steht dein Shop wieder genau da, denn PHP 8.1 und älter bekommen keine Updates mehr.

Lohnt es sich, PrestaShop jetzt zu aktualisieren?

Das ist die Frage, die man immer aufschiebt, weil der Shop ja läuft. PHP2Shell zeigt, was passiert, wenn man sie zu lange aufschiebt: Den Tag, an dem das Problem kommt, suchst du dir nicht aus, und der Patch liegt nicht in deiner Hand.

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 dich um solche Warnungen gar nicht erst kümmern willst, ist genau das die Aufgabe einer PrestaShop Wartung: Jemand aktualisiert PHP, PrestaShop und Module für dich und sagt dir Bescheid, bevor das Problem deinen Shop erreicht.

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 Branches mit dem Minimal-Patch als Quellcode, verlinkt in seiner Warnung; das sind keine offiziellen Versionen. Die Teilmaßnahmen, die PHP nennt, 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; danach 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;
}

Bei Paketen aus dem Remi-Repository (üblich unter RHEL, AlmaLinux oder Rocky) wies Sansec darauf hin, dass das Update nicht am selben Tag ankam: installierte Version mit php -v prüfen. Mit Cloudflare den Port 443 des Origin-Servers auf deren IP-Bereiche beschränken; sonst trifft der Angriff direkt die IP des Servers.

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

So können wir Ihnen helfen

Alle Leistungen ansehen →

Weiterlesen

Dürfen wir Ihnen bei Ihrem Projekt helfen? Sprechen wir darüber

Erzähl uns, was dein Geschäft braucht

Ein Modul, eine App, ein Server, der Ärger macht, oder etwas Dringendes. Wir antworten innerhalb von 24 Stunden, mit einem Festpreisangebot samt Termin.