ps_facetedsearch-Lücke: Das PrestaShop-Update, das keinen Aufschub duldet

Bewertung 10 von 10 – ausnutzbar ganz ohne Konto

Am 3. Juni 2026 hat das PrestaShop-Team einen Notfall-Patch für ps_facetedsearch veröffentlicht, das Modul für die facettierte Suche, das seit Version 1.7.1.0 auf so gut wie jedem Shop standardmäßig installiert ist. Die behobene ps_facetedsearch-Sicherheitslücke erreicht den Höchstwert der CVSS-Skala: 10.0.

Drei Eigenschaften machen sie so gefährlich:

• sie erfordert keinerlei Authentifizierung: weder ein Kundenkonto noch einen Backoffice-Zugang;
• sie lässt sich vom Frontend aus ausnutzen, mit einer einzigen HTTP-Anfrage;
• sie führt zu Remote Code Execution, also zum Ablegen einer fernsteuerbaren PHP-Datei auf Ihrem Server.

Anders gesagt: Ein Bot, der PrestaShop-Shops abklappert, kann Ihren übernehmen, ohne dass in Ihrem Administrationsverlauf irgendetwas auftaucht.

So funktioniert die Lücke

Das Modul legt die Filterblöcke im Cache ab, damit die Facetten nicht bei jedem Seitenaufruf neu berechnet werden müssen. Die Werte der Schieberegler-Filter (Preis, Gewicht) liest es aus der URL aus und speichert sie serialisiert in diesem Cache.

Das Problem entsteht beim Auslesen. Bis Version 4.0.3 wendete das Modul die native PHP-Funktion unserialize() auf diese Werte an, ohne sie vorher ausreichend zu prüfen. Ein Angreifer kann also eine URL bauen, die ein schädliches PHP-Objekt enthält. Beim Deserialisieren stößt dieses Objekt eine Gadget-Kette an, die in den Abhängigkeiten von PrestaShop steckt, und schreibt am Ende eine beliebige Datei in das Verzeichnis des Moduls.

Der offizielle Patch ersetzt unserialize() durch \Tools::unSerialize(), die abgesicherte Variante von PrestaShop.

Sind Sie betroffen?

Verwundbare Versionen: 3.0.0 bis 4.0.3. Behoben in Version 4.0.4.

Ihre Version finden Sie im Backoffice unter Module > Modul-Manager, wenn Sie nach „Facettensuche“ suchen. Alternativ lesen Sie das Tag <version> in der Datei modules/ps_facetedsearch/config.xml.

In der Datenbank genügt eine Abfrage:

SELECT name, version FROM ps_module WHERE name = 'ps_facetedsearch';

Alles unterhalb von 4.0.4 gilt als angreifbar – auch dann, wenn die Filter nur in wenigen Kategorien erscheinen: Der Controller bleibt erreichbar.

Der Patch: zwei mögliche Wege

Den Core aktualisieren. PrestaShop hat am selben Tag die Versionen 8.2.7 und 9.1.4 veröffentlicht, die das korrigierte Modul bereits enthalten. Das ist der empfohlene Weg, wenn Sie ohnehin nah an diesen Versionen liegen.

Nur das Modul aktualisieren. Laden Sie ps_facetedsearch 4.0.4 aus dem offiziellen Repository und ersetzen Sie den Ordner. Diese Variante geht am schnellsten, wenn ein Core-Update bei Ihnen einen echten Testaufwand bedeutet.

In beiden Fällen leeren Sie anschließend var/cache/prod/ und den Cache des Moduls. Können Sie nicht sofort eingreifen, greifen Sie zu den Behelfsmaßnahmen aus dem Advisory: Schieberegler-Filter aus den öffentlichen Templates entfernen, den Cache der facettierten Suche leeren und in der Web Application Firewall alle Anfragen blockieren, deren Query-String PHP-Serialisierungsmuster enthält (O:, ;i:).

Prüfen, ob der Shop bereits besucht wurde

Ein Patch schließt keine Tür, die schon benutzt wurde. Suchen Sie nach dem Update nach Spuren einer abgelegten Datei.

Kürzlich geänderte PHP-Dateien in den Modulen:

find modules/ -name "*.php" -mtime -60 -ls

Typische Muster einer Hintertür:

grep -rl "eval(\$_POST\|eval(base64_decode\|assert(\$_REQUEST" modules/ themes/ override/

Prüfen Sie außerdem:

• das Verzeichnis modules/ps_facetedsearch/: Jede .php-Datei, die nicht zur offiziellen Distribution gehört, ist verdächtig;
• die Zugriffslogs Ihres Hosters, auf der Suche nach Anfragen mit auffällig langen Zeichenketten;
• die Tabelle ps_employee: Ein unbekanntes Administratorkonto steht für eine dauerhaft eingerichtete Kompromittierung;
• die Dateien .htaccess und robots.txt, die häufig manipuliert werden, um Spam-Seiten zu verbergen.

Werden Sie fündig, reicht es nicht, die Datei zu löschen. Zu einem Einbruch gehört fast immer eine zweite Hintertür. Sie müssen sämtliche Mitarbeiterpasswörter ändern, die Schlüssel in config/settings.inc.php neu erzeugen – darunter _COOKIE_KEY_ – und ein Backup von vor dem Einbruch einspielen. Unser Beitrag über einen gehackten PrestaShop-Shop beschreibt das komplette Vorgehen.

Die Lehre: Standardmodul heißt nicht sicheres Modul

Viele Händler behalten ihre Drittanbieter-Module im Blick und lassen die mitgelieferten Module einfach laufen. Dieser Fall zeigt: Standardcode läuft auf Hunderttausenden Shops – und genau der ist für Angreifer am interessantesten.

Drei Gewohnheiten senken das Risiko drastisch:

• die Sicherheitsmeldungen von PrestaShop und Friends-of-Presta verfolgen;
• Sicherheitspatches innerhalb von 72 Stunden einspielen, bei komplexen Shops über eine Staging-Umgebung;
• ein Inventar der Modulversionen führen, um die Frage „Bin ich betroffen?“ in fünf Minuten beantworten zu können.

Genau das deckt ein PrestaShop-Wartungsvertrag ab.

Sofort einen Audit nötig?

Wir prüfen Ihre Version, spielen den Patch ein und suchen nach Spuren eines Einbruchs. Kostenlose Erstanalyse, Rückmeldung innerhalb von 1 Stunde, von 9 bis 22 Uhr, 7 Tage die Woche.