PrestaShop 1.7 ist 2026 kein „altes System“ mehr – sondern ein Sicherheitsrisiko

Aufrufe
72 Aufrufe

Stand: 27. August 2026. Dieser Beitrag ordnet den Supportstatus von PrestaShop 1.7, die kritische Schwachstelle CVE-2026-54159 im offiziellen Faceted-Search-Modul und den wachsenden Einfluss KI-gestützter Angriffe ein.

Kurzantwort: PrestaShop 1.7 ist End-of-Life. Der Shop kann weiterhin Bestellungen verarbeiten, erhält für bekannte Core-Probleme aber keine regulären Sicherheitskorrekturen mehr. Betreiber sollten Modulversionen und Kompromittierungsindikatoren sofort prüfen und die Migration auf eine unterstützte PrestaShop-Generation planen.

Ein Onlineshop muss nicht offline sein, um gehackt worden zu sein. Bestellungen können weiterhin eingehen, das Backoffice kann funktionieren und Produktseiten können normal aussehen. Für den Betreiber entsteht dadurch schnell der Eindruck, dass technisch alles in Ordnung ist – obwohl ein Angreifer längst Zugriff auf das System haben kann.

Ein typisches erstes Warnsignal ist überraschend unspektakulär: Ein eigentlich legitimer Link im Shop leitet plötzlich auf eine Glücksspielseite, eine Spam-Domain oder eine andere fremde Website weiter. Was zunächst wie ein beschädigter Link oder ein SEO-Problem im PrestaShop-Shop aussieht, kann nur die sichtbare Oberfläche einer deutlich tieferen Kompromittierung sein.

Bei älteren PrestaShop-Installationen ist dieses Risiko heute besonders ernst zu nehmen. Das betrifft insbesondere PrestaShop 1.7 – nicht allein deshalb, weil die Software mehrere Jahre alt ist, sondern weil drei Entwicklungen zusammenkommen:

Das Ergebnis ist eine Situation, in der ein scheinbar stabil laufender Shop technisch funktionieren kann – aber gleichzeitig ein immer größeres Sicherheitsrisiko darstellt.

KI hat alte Shops nicht unsicher gemacht – aber sie verändert die Geschwindigkeit der Angriffe

Bei der Diskussion über künstliche Intelligenz und Cybersecurity ist eine Unterscheidung wichtig: KI hat die Sicherheitslücken in PrestaShop 1.7 nicht erzeugt. Sie verändert aber die Geschwindigkeit, mit der bestehende Schwachstellen gefunden, analysiert und ausgenutzt werden können.

Das britische National Cyber Security Centre (NCSC) geht davon aus, dass KI Cyberangriffe bis 2027 sowohl effizienter als auch häufiger machen wird. Bereits heute wird KI unter anderem für Reconnaissance, Schwachstellenanalyse, Exploit-Entwicklung, Social Engineering, grundlegende Malware-Erstellung und die Auswertung erbeuteter Daten eingesetzt. Besonders relevant ist die Einschätzung, dass KI die Ausnutzung bereits bekannter Schwachstellen beschleunigen dürfte.

Für Betreiber veralteter Onlineshops verändert sich damit eine entscheidende Größe: die Zeit zwischen Veröffentlichung einer Sicherheitslücke und ihrer möglichen automatisierten Ausnutzung.

Früher musste ein Angreifer unter Umständen manuell herausfinden:

Immer mehr Teile dieser Arbeit lassen sich heute automatisieren oder durch KI beschleunigen. Genau deshalb wird Patch-Management wichtiger – nicht weniger. Das NCSC erwartet ausdrücklich, dass KI die Fähigkeit von Angreifern verbessert, bekannte Schwachstellen in Systemen zu identifizieren und auszunutzen, die Sicherheitsupdates nicht installiert haben.

Für eine aktiv gepflegte Software bedeutet das: Patch installieren. Für ein End-of-Life-System entsteht ein anderes Problem: Was passiert, wenn gar kein Patch mehr kommt?

PrestaShop 1.7 ist End-of-Life

PrestaShop hatte bereits nach der Veröffentlichung von PrestaShop 8 angekündigt, dass die 1.7-Reihe nur noch in einen erweiterten Supportmodus wechseln würde. Seit PrestaShop 8 erhielt 1.7 keine reguläre Weiterentwicklung mehr, sondern lediglich kritische und sicherheitsrelevante Korrekturen. Dieser Extended Support sollte mit der Veröffentlichung von PrestaShop 9 enden. Der damalige Fahrplan ist im offiziellen Beitrag „PrestaShop beyond 1.7“ dokumentiert.

PrestaShop 9 wurde am 10. Juni 2025 offiziell veröffentlicht. Damit ist die Konsequenz für Betreiber eindeutig: PrestaShop 1.7 gehört nicht mehr zur aktiv unterstützten Plattformgeneration.

Auch die aktuelle Security Policy des PrestaShop-Projekts weist darauf hin, dass Sicherheitsupdates normalerweise nur auf die jeweils aktuelle Release-Generation angewendet werden.

Wie relevant das inzwischen ist, zeigt eine Sicherheitsmeldung vom August 2026 besonders deutlich. Bei einer neu entdeckten SQL-Injection-Schwachstelle in Backoffice-Listenfiltern stellte PrestaShop ausdrücklich fest, dass der problematische Legacy-Code ebenfalls in PrestaShop 1.7.x und älteren Versionen vorhanden ist. Gleichzeitig wird darauf hingewiesen, dass diese Versionen End-of-Life sind und deshalb keinen Patch mehr erhalten.

Das ist der entscheidende Unterschied zwischen „alte Software“ und „Sicherheitsrisiko“: Eine alte, aber unterstützte Version kann gepatcht werden. Ein End-of-Life-System kann bekannte verwundbare Komponenten enthalten, ohne dass der Hersteller die alte Produktgeneration noch korrigiert.

Ein besonders relevantes Beispiel erschien am 3. Juni 2026. PrestaShop veröffentlichte ein Sicherheitsupdate für das offizielle Modul Faceted Search (ps_facetedsearch), das für die Filter- und Layered-Navigation in vielen PrestaShop-Shops verwendet wird.

Die Schwachstelle erhielt die Kennung CVE-2026-54159 und wurde mit CVSS 10.0 – Critical bewertet. Betroffen sind laut GitHub Security Advisory GHSA-m5f5-28qr-9g9r die Versionen ps_facetedsearch >= 3.0.0 und < 4.0.4.

Betroffene und korrigierte Versionen von ps_facetedsearch
ModulversionStatus für CVE-2026-54159Maßnahme
3.0.0–4.0.3verwundbarsofort auf 4.0.4 oder neuer aktualisieren
4.0.4 oder neuerfür diese konkrete Lücke korrigiertVersion bestätigen und Installation prüfen

Der Fehler ist besonders kritisch, weil der Angriff unter den beschriebenen Bedingungen keine Anmeldung und kein Benutzerkonto erfordert. Bei Shops, deren Filterkonfiguration einen Slider beispielsweise für Preis oder Gewicht verwendet, konnte ein speziell manipulierter Request dazu führen, dass schädliche PHP-Objekte in den Cache eingeschleust wurden. Beim späteren Deserialisieren konnte daraus eine Kette entstehen, die eine beliebige PHP-Datei auf dem Server erzeugt.

Mit anderen Worten: Ein externer Angreifer konnte unter bestimmten Bedingungen eine Webshell auf dem Shopserver ablegen und anschließend Befehle auf dem Server ausführen.

Das ist keine kleine Cross-Site-Scripting-Lücke. Es handelt sich um eine mögliche Remote Code Execution (RCE). Der Angriff kann damit den Übergang markieren von:

„Jemand kann meinen Shop manipulieren.“

zu:

„Jemand kann Code auf meinem Server ausführen.“

PrestaShop veröffentlichte Version 4.0.4 des Moduls als Sicherheitsfix und empfahl betroffenen Betreibern ausdrücklich, das Modul schnellstmöglich zu aktualisieren.

Ist jeder Shop mit Faceted Search automatisch gehackt?

Nein. Das wäre eine falsche Schlussfolgerung. Eine verwundbare Modulversion bedeutet nicht automatisch, dass ein Shop kompromittiert wurde. Sie bedeutet jedoch, dass ein technisch ausnutzbarer Angriffsweg existiert und geprüft werden sollte.

Deshalb sollten Betreiber insbesondere kontrollieren:

PrestaShop selbst bezeichnet das Update auf 4.0.4 als den vollständigen Fix für diese konkrete Schwachstelle. Aber hier beginnt bei PrestaShop 1.7 das größere Problem.

Ein gepatchtes Modul macht PrestaShop 1.7 nicht wieder zu einer unterstützten Plattform

Es wäre verlockend, die Situation so zu betrachten: Faceted Search aktualisieren, Cache löschen, fertig. Das löst zwar die konkrete Schwachstelle, sofern das Update korrekt und kompatibel eingespielt wurde. Es löst aber nicht das Grundproblem.

Ein PrestaShop-Shop besteht aus deutlich mehr als einer einzigen PHP-Anwendung:

Ein Shop kann deshalb an einer Stelle gepatcht und gleichzeitig an einer anderen Stelle verwundbar sein. Bei einem aktiv gepflegten Stack werden regelmäßig neue Schwachstellen identifiziert, Patches veröffentlicht und Abhängigkeiten aktualisiert. Bei einer End-of-Life-Plattform wächst dagegen mit der Zeit der Anteil des Systems, dessen Sicherheitszustand nicht mehr zuverlässig durch reguläre Updates abgesichert werden kann.

Ein Redirect kann nur das erste sichtbare Symptom sein

Nehmen wir ein scheinbar einfaches Beispiel: Ein Shopbetreiber stellt fest, dass bestimmte Kategorien oder Navigationslinks Besucher plötzlich auf fremde Glücksspielseiten weiterleiten. Der erste Reflex ist verständlich: Die manipulierte Datei finden, Redirect entfernen und die Seite wieder online bringen. Doch genau das kann gefährlich sein.

Wenn ein Angreifer bereits Remote Code Execution erreicht hat, muss die Untersuchung über die sichtbare Shop-Manipulation hinausgehen. Bei einer tieferen Serverkompromittierung können beispielsweise folgende Artefakte vorhanden sein:

In einem solchen Fall ist der Redirect nur das Symptom. Das eigentliche Problem ist: Der Angreifer hat Persistenz aufgebaut. Dann reicht es nicht, zwei verdächtige PHP-Dateien zu löschen. Ein verbliebener Backdoor-Mechanismus kann die Malware jederzeit erneut installieren.

Warum „wir haben die Malware gelöscht“ keine ausreichende Entwarnung ist

Nach einer bestätigten Kompromittierung sollte die zentrale Frage nicht lauten:

Wo liegt die infizierte Datei?

Sondern:

Wie weit konnte sich der Angreifer im System bewegen?

Hat ein Angreifer PHP-Code auf dem Server ausgeführt, muss grundsätzlich untersucht werden, welche weiteren Rechte und Zugangsdaten erreichbar waren. Dazu können gehören:

Besonders kritisch ist die Vorstellung, man könne eine bereits kompromittierte Installation einfach auf eine neue PrestaShop-Version aktualisieren und damit automatisch bereinigen. Ein Versionsupgrade ist kein Malware-Scanner.

Ein Update ersetzt bestimmte PrestaShop-Dateien. Es garantiert nicht, dass zuvor abgelegte Webshells, zusätzliche Binaries, manipulierte Cronjobs oder persistente Serverzugänge verschwinden. Bei einer bestätigten vollständigen Serverkompromittierung ist daher häufig ein Neuaufbau in einer sauberen, vertrauenswürdigen Umgebung der sicherere Weg. Wer nach einem abgebrochenen oder unsicheren Versionswechsel vor einem instabilen Shop steht, findet im Beitrag „PrestaShop-Update fehlgeschlagen“ eine ergänzende technische Erstdiagnose.

Auch SEO kann zum Opfer einer Shop-Kompromittierung werden

Nicht jeder Angriff zielt unmittelbar auf Kreditkartendaten oder die Zerstörung des Shops. Ein kompromittierter Shop ist auch für Black-Hat-SEO interessant. Angreifer können unter einer bereits etablierten Domain tausende neue Seiten erzeugen, beispielsweise für Online-Casinos, Glücksspiel, Medikamente, Kredite, gefälschte Produkte, Adult Content oder andere Spam-Themen.

Besonders problematisch wird es, wenn diese Seiten physisch oder über manipulierte Routing-Regeln URLs erzeugen, die den legitimen Seiten des Shops ähneln. Google kann diese URLs crawlen und indexieren. Der Betreiber sieht währenddessen möglicherweise weiterhin seine normale Website.

Das Ergebnis kann langfristig sein:

Ein Security Incident kann deshalb gleichzeitig zu einem SEO Incident werden.

Warum KI das Risiko für ungepatchte Shops zusätzlich erhöht

Der entscheidende Effekt von KI liegt in der Skalierung. Angreifer müssen nicht zwingend eine neue, spektakuläre Zero-Day-Schwachstelle erfinden. Es reicht häufig, bekannte Schwachstellen effizienter auszunutzen.

KI kann dabei helfen:

  1. große Mengen potenzieller Ziele zu analysieren,
  2. technische Informationen über eine Installation zu strukturieren,
  3. veröffentlichten Vulnerability-Code zu verstehen,
  4. Exploits an leicht unterschiedliche Umgebungen anzupassen,
  5. Malware und Skripte schneller zu verändern,
  6. Daten nach einem erfolgreichen Einbruch auszuwerten,
  7. Social-Engineering-Angriffe überzeugender zu gestalten.

Das NCSC erwartet deshalb ausdrücklich einen steigenden Druck auf Systeme, die Sicherheitsupdates nicht zeitnah erhalten. Interessant ist, dass dieselbe Entwicklung auch auf der Verteidigerseite stattfindet: Beim PrestaShop-Sicherheitsrelease 8.2.8 vom 18. August 2026 erwähnt das Projekt, dass eine SQL-Injection-Schwachstelle im Rahmen eines koordinierten Vulnerability-Disclosure-Prozesses mit Hilfe von Anthropic Claude entdeckt wurde.

Das zeigt, wohin sich die Branche entwickelt: KI-unterstützte Schwachstellenforschung ist keine Zukunftsvision mehr. Sie findet bereits statt. Für Shopbetreiber bedeutet das nicht, in Panik zu geraten, sondern die eigene Update-Strategie an die neue Geschwindigkeit anzupassen.

„Der Shop läuft doch noch“ ist kein Sicherheitsargument

PrestaShop 1.7 kann auch 2026 noch Produkte anzeigen, Bestellungen verarbeiten und Zahlungen abwickeln. Mitarbeiter können sich weiterhin im Backoffice anmelden. Doch technische Funktionsfähigkeit und Sicherheit sind zwei unterschiedliche Dinge.

Ein altes Auto kann noch fahren, obwohl bestimmte sicherheitsrelevante Komponenten längst nicht mehr dem aktuellen Stand entsprechen. Bei Software kommt ein zusätzlicher Faktor hinzu: Angreifer lernen ständig mehr über das System.

Mit jedem veröffentlichten Advisory wächst das öffentliche Wissen über mögliche Schwachstellen. Bei einer unterstützten Software wächst gleichzeitig auch der Schutz durch Patches. Bei einer End-of-Life-Version fehlt diese Gegenseite zunehmend.

Warum die Migration auf eine unterstützte PrestaShop-Version notwendig wird

Ein Upgrade garantiert niemals hundertprozentige Sicherheit. Auch aktuelle Software enthält Schwachstellen. Das beweisen die Sicherheitsupdates für PrestaShop 8 und 9 selbst.

Der Unterschied liegt jedoch im Security Lifecycle: Aktuelle Versionen werden untersucht. Schwachstellen werden gemeldet. Updates werden entwickelt. Patches werden veröffentlicht. Genau dieser Prozess ist ein zentraler Bestandteil moderner IT-Sicherheit.

PrestaShop 9 basiert auf einer deutlich modernisierten technischen Grundlage. Bereits PrestaShop 9.0 brachte unter anderem:

Auch aktuelle Versionen müssen konsequent aktualisiert werden. Das zeigt das Sicherheitsrelease PrestaShop 9.1.5 vom 18. August 2026, mit dem fünf Sicherheitsprobleme behoben wurden. Parallel erhielt PrestaShop 8.2.8 entsprechende Security Fixes; die 8.2-Reihe befindet sich allerdings bereits im Extended Support.

Das ist kein Gegenargument gegen ein Upgrade. Im Gegenteil: Es zeigt, warum ein aktiver Update-Kanal so wichtig ist. Schwachstellen existieren. Die entscheidende Frage ist, ob sie noch behoben werden.

Für eine realistische Planung helfen die Waldbyte-Leitfäden zur Migration von PrestaShop 1.7 auf PrestaShop 9.1 und die allgemeine PrestaShop-Migrationscheckliste. Entscheidend ist immer die konkrete Modul-, Theme-, Daten- und Schnittstellenlandschaft des Shops.

Was Betreiber eines PrestaShop-1.7-Shops jetzt prüfen sollten

Wer noch PrestaShop 1.7 betreibt, sollte die Situation nicht auf die Frage reduzieren, ob der Shop heute sichtbar funktioniert. Mindestens folgende Punkte sollten geprüft werden:

1. Exakte PrestaShop-Version bestimmen

Nicht nur „1.7“, sondern die vollständige installierte Version dokumentieren.

2. Faceted-Search-Version kontrollieren

Ist ps_facetedsearch in einer Version zwischen 3.0.0 und 4.0.3 installiert, muss die veröffentlichte Sicherheitslücke CVE-2026-54159 unmittelbar berücksichtigt werden.

3. Alle Module inventarisieren

Dazu gehören auch deaktivierte oder scheinbar nicht mehr verwendete Module, deren Dateien noch auf dem Server liegen.

4. Den Server und nicht nur PrestaShop untersuchen

Bei Anzeichen einer Kompromittierung müssen auch Prozesse, Benutzer, Cronjobs, SSH-Konfiguration, temporäre Verzeichnisse und andere serverweite Persistenzmechanismen geprüft werden.

5. Administratoren und Zugänge kontrollieren

Unbekannte Mitarbeiterkonten oder ungewöhnliche Änderungen können Hinweise auf einen erfolgreichen Angriff sein.

6. Webserver-Logs analysieren

Verdächtige Requests rund um bekannte Schwachstellen können wichtige Hinweise liefern.

7. Datenbank und öffentlich erreichbare Dateien prüfen

SQL-Dumps, ZIP-Backups, Logs oder Konfigurationskopien gehören nicht in öffentlich erreichbare Verzeichnisse.

8. Zugangsdaten rotieren

Bei bestätigter Kompromittierung sollten relevante Passwörter, Tokens und Keys aus einer vertrauenswürdigen Umgebung heraus erneuert werden.

9. Eine Migration planen

Ein Sicherheitspatch für ein einzelnes Modul ändert nichts daran, dass PrestaShop 1.7 selbst End-of-Life ist. Waldbyte unterstützt bei PrestaShop Updates, der kontrollierten PrestaShop-Migration und bei Support und laufender Wartung.

Bei einem bereits gehackten Shop: erst Incident Response, dann Migration

Eine wichtige Unterscheidung: Shop A läuft auf PrestaShop 1.7, zeigt aber bisher keine Hinweise auf eine Kompromittierung. Bei Shop B wurden dagegen Webshells, Redirects oder andere eindeutige Einbruchsspuren gefunden. Beide Shops sollten modernisiert werden – aber nicht auf dieselbe Weise.

Bei Shop A kann eine kontrollierte Migration mit vorheriger Modul-, Theme- und Datenanalyse geplant werden. Bei Shop B muss zuerst davon ausgegangen werden, dass die bestehende Umgebung nicht mehr vertrauenswürdig ist. Dann sollte die Vorgehensweise eher lauten:

Eindämmen → analysieren → Persistenz entfernen → Credentials erneuern → saubere Zielumgebung aufbauen → Daten validieren → migrieren → testen → überwachen.

Nicht: Malware löschen → PrestaShop aktualisieren → hoffen.

Fazit: PrestaShop 1.7 funktioniert vielleicht noch – aber darauf kommt es nicht mehr an

Die Diskussion über PrestaShop 1.7 sollte 2026 nicht mehr ausschließlich unter dem Gesichtspunkt geführt werden:

„Brauchen wir die neuen Funktionen wirklich?“

Die wichtigere Frage lautet:

„Können wir ein geschäftskritisches E-Commerce-System verantwortungsvoll weiterbetreiben, wenn seine Plattformgeneration keine regulären Security Fixes mehr erhält?“

Mit der Veröffentlichung von PrestaShop 9 endete der vorgesehene Extended Support für PrestaShop 1.7. Gleichzeitig werden weiterhin reale Schwachstellen in Core und Modulen entdeckt. CVE-2026-54159 im Faceted-Search-Modul zeigt, wie gravierend solche Probleme sein können: eine kritische, nicht authentifizierte Remote-Code-Execution-Schwachstelle mit CVSS 10.0.

KI verschärft die Rahmenbedingungen zusätzlich – nicht weil eine künstliche Intelligenz plötzlich automatisch jeden alten Shop hackt, sondern weil Schwachstellensuche, Reconnaissance, Exploit-Analyse und Angriffsskalierung schneller werden.

Ein PrestaShop-1.7-Shop kann heute noch Bestellungen verarbeiten. Das beweist nicht, dass er sicher ist. Es beweist lediglich, dass er noch funktioniert.

PrestaShop 1.7 zu ersetzen ist deshalb 2026 nicht mehr nur eine Frage von neuen Funktionen oder technischer Modernisierung. Es ist Risikomanagement.

PrestaShop 1.7 noch im Einsatz?

Wenn Ihr Shop weiterhin auf PrestaShop 1.7 läuft, sollte der erste Schritt nicht zwingend ein blindes Upgrade sein. Zunächst sollte geklärt werden:

Waldbyte unterstützt Unternehmen bei der technischen Analyse bestehender PrestaShop-Shops, bei der Sicherheitsbewertung und bei der kontrollierten Migration auf eine aktuelle PrestaShop-Generation. Denn bei einem geschäftskritischen Onlineshop sollte die Frage nicht sein, wie lange eine veraltete Installation noch läuft, sondern wie lange man das damit verbundene Risiko noch tragen möchte.

PrestaShop-Sicherheitsanalyse anfragen

FAQ zur PrestaShop 1.7 Sicherheit

Ist PrestaShop 1.7 im Jahr 2026 noch sicher?

PrestaShop 1.7 ist End-of-Life und erhält nicht mehr regulär neue Sicherheitskorrekturen. Eine Installation kann weiterhin funktionieren, verfügt jedoch nicht mehr über denselben aktiven Security Lifecycle wie aktuelle PrestaShop-Versionen.

Ist das Faceted-Search-Modul von PrestaShop unsicher?

Nicht jede Version. Die Schwachstelle CVE-2026-54159 betrifft ps_facetedsearch ab Version 3.0.0 bis einschließlich 4.0.3. Version 4.0.4 enthält den Sicherheitsfix. Die Schwachstelle kann unter bestimmten Bedingungen eine nicht authentifizierte Remote Code Execution ermöglichen.

Bedeutet eine verwundbare Faceted-Search-Version automatisch, dass mein Shop gehackt wurde?

Nein. Eine verwundbare Version beweist keine Kompromittierung. Sie sollte jedoch unverzüglich aktualisiert und die Installation auf mögliche Hinweise einer bereits erfolgten Ausnutzung untersucht werden.

Reicht es aus, Faceted Search auf Version 4.0.4 zu aktualisieren?

Das Update schließt die konkrete Schwachstelle CVE-2026-54159. Es behebt jedoch nicht das grundsätzliche End-of-Life-Problem von PrestaShop 1.7 und entfernt auch keine bereits vorhandene Malware oder Server-Backdoors.

Macht KI PrestaShop 1.7 unsicherer?

KI erzeugt die bestehenden Schwachstellen nicht. Sie kann jedoch Reconnaissance, Vulnerability Research, Exploit-Entwicklung und andere Teile eines Cyberangriffs beschleunigen. Dadurch steigt besonders für ungepatchte und nicht mehr unterstützte Systeme der Zeitdruck.

Sollte ein gehackter PrestaShop-1.7-Shop einfach auf PrestaShop 9 aktualisiert werden?

Bei einer bestätigten Kompromittierung sollte zunächst untersucht werden, wie weit der Angreifer Zugriff auf den Server hatte. Ein normales Versionsupgrade garantiert nicht, dass Webshells, Backdoors, manipulierte Systemdateien oder kompromittierte Zugangsdaten entfernt werden. In solchen Fällen ist ein kontrollierter Neuaufbau in einer sauberen Umgebung häufig die bessere Grundlage für die Migration.

Quellen und weiterführende Informationen