Analyse Shop-Management

Magento Zero-Day: So schleusen Angreifer Backdoors in ungepatchte Onlineshops, und was Händler jetzt tun müssen

Magento Zero-Day: So schleusen Angreifer Backdoors in ungepatchte Onlineshops, und was Händler jetzt tun müssen

Ein Patch, den Tausende Shopbetreiber nicht eingespielt haben, reicht: Angreifer nutzen derzeit eine kritische Sicherheitslücke in Magento Open Source und Adobe Commerce, um Webshells in produktiven Shops zu platzieren. Betroffen ist keine exotische Nischenversion, sondern die Standard-Infrastruktur eines der größten E-Commerce-Stacks der Welt, und damit ein erheblicher Teil der deutschen Handelslandschaft.

Die Lücke erlaubt es, ohne Authentifizierung die Kontrolle über Shop-Sessions zu übernehmen und im Anschluss eigenen Code auf dem Server auszuführen. Security-Forscher beobachten dabei ein bekanntes Muster: Erst wird still getestet, ob ein Shop angreifbar ist. Dann folgt der eigentliche Angriff, PHP-Backdoors in öffentlich erreichbaren Verzeichnissen, die den Angreifern einen dauerhaften Zugang sichern, selbst nachdem die ursprüngliche Lücke geschlossen wurde.

Kernsatz: Wer den Patch erst nach dem Angriff einspielt, hat den Einbruch nicht beendet, die Backdoor bleibt. Bereinigen heißt hier: Dateien prüfen, nicht nur aktualisieren.

Was genau macht diese Magento-Lücke so gefährlich?

Drei Eigenschaften heben diesen Zero-Day von der langen Liste jährlicher Magento-Patches ab. Erstens: Er erfordert keinerlei Login oder Kundenkonto. Ein simpler HTTP-Request gegen den Shop genügt. Zweitens: Er trifft die Standard-Konfiguration, Händler müssen nichts falsch gemacht haben, um verwundbar zu sein. Drittens: Adobe selbst hat mit einem ausserplanmässigen Notfall-Patch reagiert, abseits des regulären Release-Zyklus. Das passiert nur, wenn die interne Einschätzung klar ist, aktive Ausnutzung, reale Schäden.

Die Folgen gehen weit über ein Defacement hinaus. Wer eine Webshell auf einem Shop-Server platziert, hat Zugriff auf die Datenbank, also auf Kundendaten, Bestellhistorien und im ungünstigsten Fall auf Zahlungsdaten. Forscher berichten von Skimmer-Code, den Angreifer in Checkout-Templates einschleusen: Beim Bezahlvorgang werden Kreditkartendaten parallel an Server der Täter kopiert. Der Shopbetreiber merkt davon wochenlang nichts.

Über 250 Shops wurden laut Security-Dienstleistern bereits innerhalb weniger Tage nach der öffentlichen Patch-Verfügbarkeit kompromittiert. Die Zahl steigt täglich, weil Angreifer systematisch vorgehen: automatisierte Scans nach ungepatchten Instanzen, Masseninfektion, danach die Auswahl lohnender Ziele für den eigentlichen Diebstahl.

Warum sind deutsche Händler besonders im Fokus?

Magento beziehungsweise Adobe Commerce ist im DACH-Markt tief verankert. Mittelständische Händler mit Jahresumsätzen zwischen 5 und 100 Millionen Euro bilden das Rückgrat der Installationen, genau das Segment, das Angreifer bevorzugen. Groß genug für wertvolle Kundendaten, klein genug für schwache Security-Prozesse.

Hinzu kommt ein strukturelles Problem: Viele deutsche Magento-Shops werden von Agenturen betreut, die Patches gebündelt alle vier Wochen einspielen. Bei einem aktiv ausgenutzten Zero-Day ist das zu spät. Das Zeitfenster zwischen Patch-Veröffentlichung und Massenausnutzung lag hier bei wenigen Stunden, nicht Tagen. Wer sein Patch-Management auf Monatsrhythmen ausgelegt hat, war per Definition verwundbar.

Und dann ist da die rechtliche Dimension, die den Fall für DACH-Händler verschärft. Eine kompromittierte Kundendatenbank ist eine meldepflichtige Datenschutzverletzung nach DSGVO, 72 Stunden Frist gegenüber der Aufsichtsbehörde, Benachrichtigung betroffener Kunden. Wer den Einbruch erst nach Wochen bemerkt, hat die Frist längst gerissen. Die Bußgeldrisiken summieren sich auf die Umsatzeinbußen durch abgeschaltete Checkouts und Reputationsschäden.

Woran erkenne ich, dass mein Shop bereits infiziert ist?

Hier liegt die eigentliche Falle: Die Lücke schliesst sich durch den Patch, die Backdoor nicht. Deshalb reicht ein Blick auf die Versionsnummer nicht aus. Betreiber sollten konkret prüfen:

  • Neu angelegte oder geänderte PHP-Dateien im Verzeichnis pub/ und in Media-Ordnern, klassische Webshell-Standorte, weil sie vom Webserver ausführbar sind.
  • Unbekannte Admin-Accounts in der Benutzerverwaltung. Angreifer legen Hintertür-Logins an, um unabhängig von der technischen Backdoor wieder einsteigen zu können.
  • Auffällige Cron-Jobs und geänderte Templates, besonders im Checkout-Bereich. Skimmer verstecken sich gern in scheinbar harmlosen JavaScript-Injektionen.
  • Server-Logs auf Requests gegen Admin- und Session-Endpunkte aus ungewöhnlichen IP-Ranges, viele Angriffe liefen über automatisierte Infrastruktur im Ausland.

Sauber aufgesetzte Shops nutzen Integritätsmonitoring: File-Change-Detection, Versionskontrolle über das Deployment, Filebeat- oder ähnliche Log-Pipelines. Wer das nicht hat, fliegt jetzt blind, und sollte im Zweifel davon ausgehen, dass ein ungepatchter Shop seit Veröffentlichung der Lücke angegriffen wurde. Nicht vielleicht. Wurde.

Ein Patch schließt die Tür. Er räumt nicht die Leute aus dem Haus, die schon drin sind.

Wie sollten Shopbetreiber jetzt vorgehen?

Die richtige Reihenfolge ist entscheidend, und sie unterscheidet sich von dem, was die meisten Agenturen routinemäßig tun. Erst forensisch sichern, dann patchen, dann bereinigen. Wer sofort updated, überschreibt womöglich Beweise für den Einbruch und weiß danach nicht, ob Kundendaten abgeflossen sind.

Konkret heißt das: Server-Snapshot oder zumindest ein Dateisystem-Backup vor jeder Änderung. Danach den Notfall-Patch einspielen, danach aktiv nach Backdoors suchen, manuell oder über spezialisierte Scanner, die auf bekannte Webshell-Signaturen prüfen. Bei positivem Befund geht es nicht weiter mit „läuft ja wieder“, sondern mit Incident Response: Session-Tokens invalidieren, alle Admin-Passwörter und API-Keys rotieren, Zahlungsdienstleister informieren, Datenschutzfolgen mit dem DPO klären.

Strukturell bleibt eine unbequeme Wahrheit: Adobe Commerce ist ein Enterprise-Produkt mit Enterprise-Ansprüchen an den Betrieb. Händler, die keine Kapazität für 24-Stunden-Patch-Reaktionen haben, sollten entweder einen Hosting-Partner mit Managed-Security-Verpflichtung wählen, oder sich ernsthaft mit der Frage auseinandersetzen, ob der selbst gehostete Stack noch zu ihrer Organisation passt. SaaS-Plattformen haben diese Kategorie von Problem schlicht nicht.

Kernsatz: Die Lücke ist gepatcht, aber die Angriffe laufen weiter, gegen jeden Shop, der noch nicht aktualisiert hat. Jeder Tag Verzögerung ist ein Tag Angriffsfläche.

Was dieser Vorfall über E-Commerce-Security verrät

Dieser Zero-Day ist kein Einzelfall, sondern ein Muster. Magento/Adobe Commerce erlebt in unregelmäßigen Abständen schwere, aktiv ausgenutzte Lücken, die CosmicSting-Welle mit tausenden kompromittierten Shops, darunter Namen wie Ray-Ban und National Geographic, liegt nicht lange zurück. Die Plattform ist groß, verbreitet und komplex genug, dass Sicherheitsforscher und Kriminelle sie gleichermaßen intensiv untersuchen.

Für die Branche heißt das: Security ist kein IT-Thema mehr, sondern ein Betreiber-Risiko mit direktem Umsatzbezug. Ein kompromittierter Checkout kostet Conversion, Vertrauen und im schlimmsten Fall die Zahlungslizenz, Kartennetzwerke setzen Händlern nach Skimming-Vorfällen enge Fristen für die Bereinigung, sonst droht der Entzug der Akzeptanz.

Die Angriffe auf ungepatchte Shops werden sich in den kommenden Wochen fortsetzen, die Scans laufen automatisiert und pausenlos. Wer diesen Text liest und seinen Patch-Status nicht aus dem Kopf nennen kann, hat seine erste Aufgabe für heute gefunden. Und wer beim Prüfen eine Backdoor findet: Dann beginnt die Arbeit erst. Die Meldefrist läuft ab Entdeckung, nicht ab Einbruch.