PrestaShop gehackt: Kartenskimmer erkennen und entfernen

Der schlimmste Angriff ist der, der nichts kaputt macht

Wirft ein gehackter PrestaShop-Shop einen Fehler 500, merkt es der Händler binnen einer Stunde. Steckt dagegen ein Skimmer im Shop, läuft alles weiter wie gewohnt: Bestellungen gehen ein, Kunden zahlen – und ein in die Zahlungsseite eingeschleustes Skript kopiert die Kartennummern still und leise auf einen fremden Server.

Die Angriffswelle, die Anfang 2026 bei PrestaShop zu beobachten war, folgt genau diesem Muster. Der Einstiegspunkt ist so gut wie nie der Core, sondern ein nicht aktualisiertes Drittanbieter-Modul, oft vor Jahren installiert und längst vergessen.

Zwei Folgen treten sofort ein: Der Shop verliert seine PCI-DSS-Konformität gegenüber dem Zahlungsdienstleister, und der Vorfall muss nach Artikel 33 DSGVO innerhalb von 72 Stunden der zuständigen Datenschutzbehörde gemeldet werden.

Diese Signale sollten Sie aufhorchen lassen

Keines dieser Signale ist für sich genommen ein Beweis, aber jedes einzelne gehört überprüft:

• Kunden melden betrügerische Abbuchungen kurz nach einer Bestellung bei Ihnen;
• Ihr Zahlungsdienstleister spricht Sie auf eine auffällige Betrugsquote an;
• eine JavaScript-Datei des Themes trägt ein aktuelles Änderungsdatum, obwohl Sie nichts veröffentlicht haben;
• im Quelltext der Bestellseite taucht ein <script>-Tag auf, das auf eine unbekannte Domain zeigt;
• die Google Search Console meldet irreführende Inhalte oder indexierte Spam-Seiten.

Die Domains, über die Daten abfließen, imitieren bewusst seriöse Dienste: Namen mit cdn, analytics, jquery oder tag-manager, dazu ungewöhnliche Endungen. Eine Domain, die aussieht wie Google, aber nicht google.com ist, ist das zuverlässigste Warnsignal.

Die Diagnose per SSH in fünf Befehlen

In den letzten sieben Tagen geänderte Dateien:

find . -type f -name "*.php" -mtime -7 -not -path "./var/cache/*"
find . -type f -name "*.js" -mtime -7 -not -path "./var/cache/*"

Verschleierter Code in Themes und Modulen:

grep -rl "eval(atob\|eval(String.fromCharCode\|_0x" themes/ modules/

Klassische Hintertüren:

grep -rl "eval(\$_POST\|assert(\$_REQUEST\|base64_decode(\$_" . --include="*.php"

In der Datenbank gibt es eine gut dokumentierte Klassiker-Injektion: JavaScript im Shopnamen, der auf jeder Seite wieder ausgegeben wird.

SELECT name, value FROM ps_configuration WHERE value LIKE '%<script%';
SELECT id_employee, email, active FROM ps_employee;

Ein Mitarbeiterkonto, das Sie nicht zuordnen können, oder ein Konfigurationswert mit HTML darin: Das ist die Bestätigung.

Der Ablauf der Bereinigung

Wer einen gehackten Shop in beliebiger Reihenfolge säubert, holt sich die Infektion zurück. Die Reihenfolge ist entscheidend.

1. Den Zustand einfrieren. Sichern Sie Dateien und Datenbank vollständig, bevor Sie irgendetwas anfassen. Das ist Ihr einziges Beweismaterial und Ihre einzige Chance, den Einfallsweg zu verstehen.

2. Die Blutung stoppen. Schalten Sie den Shop in den Wartungsmodus. Solange die Zahlungsseite online ist, fließen weiter Kartennummern ab.

3. Den Code aus einer sauberen Quelle wiederherstellen. Laden Sie den PrestaShop-Core in exakt der installierten Version erneut herunter und überschreiben Sie die Dateien – ausgenommen img/, upload/, download/, Ihre Eigenentwicklungen und config/settings.inc.php. Jedes Drittanbieter-Modul installieren Sie neu über den Hersteller, niemals aus einem Archiv, das auf dem Server liegt.

4. Die Datenbank säubern. Korrigieren Sie manipulierte Werte in ps_configuration, löschen Sie unbekannte Mitarbeiterkonten und sehen Sie sich CMS-Seiten sowie Produktbeschreibungen an, die <script> enthalten.

5. Alles erneuern. Mitarbeiterpasswörter, Datenbankpasswort, FTP- und SSH-Zugänge, API-Schlüssel der Zahlungsmodule sowie die kryptografischen Schlüssel in config/settings.inc.php (_COOKIE_KEY_, _RIJNDAEL_KEY_). Neue Schlüssel beenden alle Sitzungen – auch die des Angreifers.

6. Die Eingangstür schließen. Ohne diesen Schritt ist die Neuinfektion eine Frage von Tagen. Aktualisieren Sie sämtliche Module, prüfen Sie für jedes einzelne die von Friends-of-Presta veröffentlichten Advisories und spielen Sie die Sicherheitspatches des Core ein.

Den Shop dauerhaft härten

• Das Admin-Verzeichnis umbenennen und zusätzlich per HTTP-Authentifizierung schützen.
• Die Ausführung von PHP in img/, upload/ und download/ über die Serverkonfiguration unterbinden.
• Zwei-Faktor-Authentifizierung für alle Mitarbeiterkonten aktivieren.
• Eine Web Application Firewall und eine Integritätsüberwachung der Dateien einrichten: Eine neu angelegte PHP-Datei in modules/ muss einen Alarm auslösen.
• Täglich sichern, mit mindestens 30 Tagen Aufbewahrung. Eine Sicherung über sieben Tage nützt nichts, wenn der Einbruch erst nach drei Wochen auffällt.

Wurde Ihr Shop über ein ungepatchtes Modul für die facettierte Suche kompromittiert, lesen Sie ergänzend unsere Analyse zur ps_facetedsearch-Sicherheitslücke.

Noteinsatz

Ein Skimmer wird mit jedem Tag teurer, den er im Shop bleibt. Wir prüfen, bereinigen und sichern ab – mit einem schriftlichen Bericht zum Einfallsweg. Kostenlose Erstanalyse, Rückmeldung innerhalb von 1 Stunde – Kontakt aufnehmen.