PrestaShop Fehler 500 oder weiße Seite: was du jetzt tun kannst
Dein PrestaShop-Shop zeigt Fehler 500 oder eine weiße Seite: was du jetzt tust, ohne es schlimmer zu machen, und wie du…
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.
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.
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:
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.
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.
Den Shop im Backoffice in den Wartungsmodus zu versetzen, schützt dich diesmal nicht: PHP liest den Besuch, bevor PrestaShop entscheidet, die Wartungsseite anzuzeigen.
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.
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.
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.
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.
Dein PrestaShop-Shop zeigt Fehler 500 oder eine weiße Seite: was du jetzt tust, ohne es schlimmer zu machen, und wie du…
Was die Wartung eines PrestaShop-Shops umfasst, wie viele Stunden du brauchst und was sie pro Jahr kostet: drei Pakete…
PrestaShop 1.6 oder 1.7 auf Version 9 aktualisieren, ohne den Shop zu schließen: was du mitnimmst, was mit Modulen,…
Ein Modul, eine App, ein Server, der Ärger macht, oder etwas Dringendes. Wir antworten innerhalb von 24 Stunden, mit einem Festpreisangebot samt Termin.