Schwachstellen in PrestaShop 8 und 9: betroffene Versionen und sichere Updates

PrestaShop hat am 18. August 2026 zwei Sicherheitsupdates veröffentlicht: PrestaShop 8.2.8 und PrestaShop 9.1.5. Beide beheben die gleichen fünf Schwachstellen, drei davon mit hohem Schweregrad und zwei mit mittlerem Schweregrad.

Nur weil eine Version anfällig ist, heißt das nicht, dass der Store kompromittiert wurde. Jeder Fehler erfordert bestimmte Bedingungen: Einige erfordern ein Mitarbeiterkonto, ein anderer erfordert das Öffnen einer manipulierten CSV-Datei und einer betrifft insbesondere Installationen, die sich hinter einem Proxy, Balancer oder CDN befinden. Wenn der Shop dennoch eine betroffene Version ausführt, lautet die offizielle Empfehlung, ein Update durchzuführen.

Welche PrestaShop-Versionen betroffen sind

Die fünf offiziellen Hinweise verwenden dieselbe Matrix für unterstützte Filialen. Die festen Versionen sind 8.2.8 und 9.1.5.

Der letzte Punkt erfordert Präzision: Die SQL-Injection-Beratung bestätigt ausdrücklich, dass der fehlerhafte Code auch in PrestaShop 1.7.x und früheren Versionen vorhanden ist, die bereits nicht mehr unterstützt werden. Dies bedeutet nicht, dass die fünf Schwachstellen in allen diesen Filialen bestätigt wurden.

Die fünf Schwachstellen, erklärt ohne Panikmache

1. Ausführbare Formeln in CSV-Exporten

Schweregrad: hoch. PrestaShop hat bestimmte Werte exportiert, ohne Zeichen zu neutralisieren, die eine Tabellenkalkulation als Formeln interpretieren kann. Wenn es einem Angreifer gelingt, einen vorbereiteten Wert in ein Feld einzugeben, das dann exportiert wird, entsteht das Risiko, wenn ein Händler, Mitarbeiter, eine Agentur oder ein Kunde diese Datei mit einer Tabellenkalkulationsanwendung öffnet.

Allein durch die Generierung der CSV wird kein Code auf dem Server ausgeführt. Die Ausbeutung erfordert manipulierte Inhalte und eine Person, die die Datei in einem Programm öffnet, das die Formel verarbeitet. Bis zur Aktualisierung wird in der Empfehlung empfohlen, CSVs als Text zu importieren, Inhalte nicht zu aktivieren oder Links zu aktualisieren und Werte zu überprüfen, die mit Zeichen wie =, +, - oder @ beginnen.

Konsultieren Sie die offizielle Empfehlung zur CSV-Injektion.

2. Interne Anfragen mit Bildern aus einem CSV-Import

Schweregrad: hoch. Beim Importieren von Produkten kann PrestaShop die in der CSV angegebenen Bilder herunterladen. Vor dem Patch hat der Server diese Adressen nicht ausreichend validiert. Eine manipulierte Datei könnte dazu führen, dass der Server interne Ressourcen oder Adressen anfordert, auf die von außen nicht zugegriffen werden sollte.

Dieses Szenario steht keinem Besucher offen: Es erfordert ein Backoffice-Konto mit Importberechtigung und die Verwendung einer böswilligen oder nicht vertrauenswürdigen CSV-Datei. Die potenziellen Auswirkungen sind wichtig, aber die Zugangsbedingung verringert die praktische Gefährdung. Zusätzlich zur Aktualisierung empfiehlt es sich, die Importberechtigung einzuschränken und zu verhindern, dass sich der Webserver uneingeschränkt mit privaten Netzwerken oder internen Diensten verbinden kann.

Beachten Sie beim Importieren die offizielle Empfehlung zu SSRF.

3. IP-Adress-Spoofing hinter einem Proxy oder CDN

Schweregrad: hoch. In einer Architektur mit einem Reverse-Proxy, Balancer oder CDN erreicht die IP des Besuchers PrestaShop normalerweise über den HeaderX-Forwarded-For. Die Anwendung las das Ende der Kette, die der Besucher kontrollieren kann, und nicht den Mehrwert der vertrauenswürdigen Infrastruktur.

Ein Besucher ohne Konto könnte sich als eine andere IP ausgeben. Dies könnte die Zugriffsliste für den Wartungsmodus schwächen, Datensätze verunreinigen und sich auf die Geolokalisierung, Anforderungsbeschränkung oder Betrugskontrollen auswirken, die von dieser Adresse abhängen. Stores, bei denen der Benutzer eine direkte Verbindung zum Webserver herstellt, sind von diesem speziellen Szenario nicht betroffen.

Die Aktualisierung des Kerns ist notwendig, ersetzt jedoch nicht die Überprüfung der Infrastruktur. Der Proxy sollte den empfangenen Header überschreiben und der Ursprungsserver sollte nur Datenverkehr aus den autorisierten Bereichen des CDN oder Balancers akzeptieren.

Siehe die offizielle Empfehlung zu X-Forwarded-For.

4. SQL-Injection von Backoffice-Filtern

Schweregrad: Mittel. Die Namen einiger Backoffice-Eintragsfilter wurden vor der Verwendung in einer Abfrage nicht ordnungsgemäß validiert. Ein authentifizierter Mitarbeiter könnte einen Filter einrichten, um auf Informationen zuzugreifen, die außerhalb seiner Profilberechtigungen liegen. Dies konnte der Forscher sogar mit dem restriktivsten eingebauten Profil nachweisen.

Es handelt sich hierbei nicht um einen anonymen Angriff aus dem öffentlichen Store: Er erfordert eine gültige Mitarbeitersitzung. Es ist jedoch in Unternehmen relevant, in denen Agenturen, Zeitarbeitskräfte, Kundendienstmitarbeiter oder Mitarbeiter mit eingeschränkten Berechtigungen Zugriff haben. Das Advisory bietet keine alternative Konfigurationslösung: Die Lösung besteht in der Aktualisierung.

Siehe das offizielle SQL-Injection-Advisory.

5. Kundeninformationen sind für Mitarbeiter ohne Erlaubnis sichtbar.

Schweregrad: Mittel. Der Endpunkt, der Backoffice-Benachrichtigungen sendet, hat die Berechtigungen der Mitarbeiter nicht überprüft. Jedes authentifizierte Konto, auch mit einem Profil ohne Berechtigungen, könnte aktuelle Daten wie Kundennamen, Bestellmengen, Spediteure und Status einsehen.

Der öffentliche Shop und anonyme Besucher sind in diesem Fall nicht beteiligt. Das Risiko konzentriert sich auf Einrichtungen, die auf eingeschränkte Profile angewiesen sind, um Funktionen zwischen Mitarbeitern, Agenturen oder Lieferanten zu trennen. Da es sich um personenbezogene Daten handelt, verdienen sie auch die Aufmerksamkeit des Datenschutzmanagements. Es gibt keine Einstellung, die den Endpunkt repariert, ohne den Patch anzuwenden.

Siehe die offizielle Empfehlung zur Zugriffskontrolle.

Welches Risiko tatsächlich für ein Geschäft besteht

Priorität sollte nicht allein durch die Schweregradbezeichnung entschieden werden. Es empfiehlt sich, die installierte Version mit dem tatsächlichen Betrieb des Stores abzugleichen:

• Wenn CSV-Importe und -Exporte durchgeführt werden, wirken sich zwei der Fehler direkt auf gängige Prozesse aus.
• Wenn mehrere Personen oder Lieferanten auf das Backoffice zugreifen, werden SQL-Injection und unberechtigter Zugriff auf Benachrichtigungen wichtiger.
• Wenn der Store Cloudflare, ein anderes CDN, einen Balancer oder einen Reverse-Proxy verwendet, müssen sowohl der Patch als auch die Konfiguration von Header.
• Wenn die Installation 1.7 oder früher ist, bleibt zumindest der SQL-Fehler ungepatcht und erhöht das Risiko, auf einem nicht unterstützten Zweig zu arbeiten.

Das Fehlen sichtbarer Anzeichen beweist auch nicht, dass ein System sauber ist, aber das Ausführen einer betroffenen Version beweist nicht, dass ein Angriff stattgefunden hat. Die professionelle Vorgehensweise besteht darin, die Offenlegung zu korrigieren, Aufzeichnungen zu überprüfen, wenn der Kontext dies rechtfertigt, und Schlussfolgerungen zu vermeiden, die nicht durch Beweise gestützt werden.

Soll ich sofort ein Upgrade durchführen?

Wenn Sie PrestaShop 8.0–8.2.7 oder 9.0–9.1.4 verwenden, sollten Sie das Upgrade als Priorität planen. „Priorisiert“ bedeutet nicht, dass man unvorbereitet den Knopf für die Produktion drückt. Es bedeutet, jetzt mit der Überprüfung zu beginnen, die Änderung in einer sicheren Umgebung zu testen und sie nicht auf unbestimmte Zeit aufzuschieben.

PrestaShop empfiehlt die Aktualisierung auf 8.2.8 oder 9.1.5. Bei einer Standardinstallation kann der Vorgang direkt erfolgen; In einem Shop mit Modulen von Drittanbietern, Überschreibungen, benutzerdefinierten Themes oder Unternehmensintegrationen kann das Update Inkompatibilitäten aufdecken, die nichts mit den Schwachstellen zu tun haben.

Aus diesem Grund sollte ein PrestaShop-Update oder eine Migration als kontrollierte Änderung behandelt werden, mit der echten Möglichkeit eines Rollbacks, wenn die Tests nicht zufriedenstellend sind.

So aktualisieren Sie einen PrestaShop-Shop sicher

Ein professioneller Prozess muss nicht endlos sein, aber er muss die Punkte abdecken, die das unterstützen Verkauf:

1. Inventar und Kompatibilität. Bestätigen Sie die genaue Version von PrestaShop und PHP; Überprüfen Sie Module, Theme, Überschreibungen und Integrationen mit ERP, PIM, Logistik, Zahlungen oder Marketing.
2. Wiederherstellbare Kopie. Speichern Sie Dateien und Datenbank und prüfen Sie, ob ein Wiederherstellungsvorgang und nicht nur eine Sicherungsdatei vorhanden ist.
3. Staging-Tests. Replizieren Sie den Shop in einer isolierten Umgebung, wenden Sie das Update dort an und überprüfen Sie Fehler, Protokolle und geplante Aufgaben, bevor Sie sie berühren Produktion.
4. Geschäftsvalidierung. Testen Sie Katalog, Suche, Kundenkonto, Warenkorb, Rabatte, Steuern, Spediteure, Kasse, Zahlungen, Bestellungen, Rechnungen, E-Mails, Lagerbestände, Retouren, Webhooks und Cron.
5. Infrastrukturüberprüfung. Überprüfen Sie Caches, Proxy, CDN und IP-Header, insbesondere auf die Schwachstelle von X-Forwarded-For.
6. Bereitstellung und Beobachtung. Wählen Sie ein geeignetes Fenster, führen Sie ein Rollback durch und überwachen Sie Protokolle, Konvertierungen, Zahlungen und automatische Prozesse nach dem Update.

Dieses Verfahren verringert das Risiko, dass eine Sicherheitskorrektur letztendlich zu Checkout-Fehlern, Bestandsabweichungen oder Kommunikationsverlusten mit externen Diensten führt. Es ist auch ein natürlicher Teil eines PrestaShop-Wartungsdienstes: Den Status der Plattform zu kennen, bevor ein Update dringend ist.

Was passiert mit alten Shops

PrestaShop 8.2 befindet sich im erweiterten Support und erhält hauptsächlich kritische und sicherheitsrelevante Korrekturen. Installationen 1.7 und früher werden nicht mehr unterstützt. Konkret bestätigt das PrestaShop-Team, dass der SQL-Injection-Code auch in 1.7.x und früheren Versionen vorhanden ist und dass sie keinen Patch erhalten werden.

Bei einem alten Shop scheint das manuelle Kopieren eines isolierten Fixes einfacher zu sein als die Migration, aber der Rest der technischen Schulden bleibt ungelöst: veraltetes PHP, aufgegebene Module, Inkompatibilitäten und zukünftige Schwachstellen. Die Entscheidung sollte mit einer Evaluierung des Stores beginnen und in einem überprüfbaren Migrationsplan enden, nicht in einer Reihe improvisierter Patches.

Die praktische Entscheidung

Überprüfen Sie zuerst die genaue Version. Wenn es innerhalb der betroffenen Bereiche liegt, bereiten Sie ein Upgrade auf 8.2.8 oder 9.1.5 vor und überprüfen Sie insbesondere Mitarbeiter, CSV-Importe und Proxy- oder CDN-Infrastruktur. Wenn Sie PrestaShop 1.7 oder einen früheren Zweig verwenden, ist die Migration aufgrund des Fehlens eines Patches für den SQL-Fehler sowohl eine Frage der Sicherheit als auch der Wartung.

Wenn Sie eine betroffene Version aktualisieren müssen, ohne Module, Themes, Integrationen oder den Checkout-Vorgang zu beeinträchtigen, können PsDevs die Umgebung überprüfen und ein kontrolliertes Update vorbereiten. Sagen Sie uns, welche Version Sie verwenden und wir werden den Umfang prüfen, bevor wir eingreifen.

Offizielle Quellen

• PrestaShop 8.2.8 ist verfügbar.
• PrestaShop 9.1.5 ist verfügbar verfügbar.
• Sicherheitshinweise aus dem offiziellen PrestaShop-Repository.