SafePal-Datenpanne legt 39.798 Kundendaten über Plug-in-Lücke offen

Jeder Schlosser kennt die unangenehme Wahrheit: Das stärkste Sicherheitsschloss der Welt nützt nichts, wenn die Kundendatenbank im Hinterzimmer Einbrechern genau verrät, in welchen Häusern die wertvollen Dinge zu finden sind. SafePal hat das gerade auf die harte Tour gelernt. Die Wallets haben gehalten, das Plug-in nicht – und jetzt stehen rund 40.000 Menschen, die sich eine Hardware-Wallet gekauft haben, um genau nicht aufzufallen, auf irgendjemandes Liste.

Was passiert ist

Am Sonntag gab der Hardware-Wallet-Hersteller SafePal eine Datenpanne bekannt, von der 39.798 Kunden betroffen sind, die zwischen dem 2. März 2025 und dem 11. April 2026 Bestellungen aufgegeben haben. Wie CoinDesk berichtete, umfassten die offengelegten Datensätze Namen, physische Adressen und Kontaktdaten. Genug, um eine sehr zielgerichtete Phishing-Kampagne aufzubauen – oder Schlimmeres.

Das Unternehmen machte deutlich, was nicht geleakt wurde: keine Seed-Phrasen, keine privaten Schlüssel, keine Bankdaten, keine Ausweisdaten, keine Passwörter, keine Zahlungskartennummern und – entscheidend – keine Kryptowährungsguthaben. Die Wallets selbst blieben versiegelt. Dies war ein Einbruch in den Shop, nicht in den Tresor.

SafePal führte die Ursache auf eine „Autorisierungslücke" in einem Plug-in zurück, das zur Verfolgung von Kundenbestellungen verwendet wird. Auf Deutsch: Der Tracker hat es einem Kunden wahrscheinlich ermöglicht, die Bestelldetails eines anderen Kunden einzusehen, indem er die Anfrage manipulierte. Eine Zahl ändern, den Kassenbon eines anderen sehen.

SafePal schickte am gleichen Sonntag, an dem die Panne bekannt gegeben wurde, eine E-Mail an alle betroffenen Kunden von [email protected], behob die Lücke, beauftragte ein unabhängiges Drittunternehmen mit der Prüfung der Lösung und der gesamten Bestellabwicklung und verpflichtete sich, persönliche Daten in diesem System künftig nur noch 90 Tage ab der Erhebung aufzubewahren. Außerdem wurden mehr als 30 betrügerische Websites und Phishing-Links im Zusammenhang mit dem Vorfall identifiziert und entfernt sowie ein Verifizierungstool auf der eigenen Website eingerichtet, mit dem Nutzer prüfen können, ob ihre Daten betroffen sind. Nutzern, die jemals eine Seed-Phrase oder einen privaten Schlüssel auf einer Phishing-Seite eingegeben haben, wurde geraten, die Wallet als kompromittiert zu betrachten und Vermögenswerte zu verschieben.

Technische Analyse

Eine „Autorisierungslücke" in einem Bestellverfolgung-Plug-in ist die höfliche Umschreibung für das, was mit ziemlicher Sicherheit ein IDOR oder ein enger Verwandter davon ist. Insecure Direct Object Reference steht seit Jahren nahezu oben auf der OWASP-Liste und wird immer wieder ausgeliefert, weil es die Art von Fehler ist, die nur entsteht, wenn man vergisst, Code zu schreiben – nicht wenn man schlechten Code schreibt.

Das Muster ist erschreckend simpel. Ein Kunde meldet sich an, ruft einen Endpunkt wie /api/orders/482913 auf und erhält seine Bestellung. Der Server prüft, ob eine Sitzung existiert, prüft aber nie, ob diese Sitzung jene Bestell-ID besitzt. Die Zahl erhöhen, die Bestellung von jemand anderem abrufen. Den Vorgang automatisieren, 39.798 Bestellungen erhalten. Jeder, der schon einmal eine frische E-Commerce-Integration geprüft hat, weiß, dass dies der Fehlermodus ist, nach dem man zuerst sucht – und derjenige, der übersehen wird, wenn das Plug-in von einem Wachstumsteam eingebaut wurde, das einfach nur Versandbenachrichtigungen vor einem Produktlaunch zum Laufen bringen musste.

Plug-ins sind hier der wiederkehrende Schurke. Hardware-Wallet-Anbieter beschäftigen sich, völlig zu Recht, intensiv mit der Firmware, dem sicheren Element und der Lieferkette des Geräts selbst. Der E-Commerce-Stack, der das Gerät tatsächlich verkauft, ist oft eine Shopify- oder Magento-Installation mit einem Friedhof von Drittanbieter-Erweiterungen für Tracking, Steuern, Fulfillment und E-Mail. Jede davon ist eine separate Authentifizierungsfläche, oft von einem Zwei-Personen-Betrieb geschrieben und selten durch dasselbe Bedrohungsmodell wie die Wallet-Firmware abgedeckt.

Der im selben CoinDesk-Artikel erwähnte Coldcard-Vorfall, bei dem ein Angreifer Berichten zufolge mindestens 120 Millionen Dollar in Bitcoin abgezogen hat, ist eine ganz andere Kategorie. Dort ging es um Geld. Hier geht es um Metadaten. Aber die Metadaten sind die Karte, und die Karte ist es, die opportunistisches Phishing in zielgerichtete Extraktion verwandelt. Gib mir einen Namen, eine physische Adresse und die Bestätigung, dass die Person eine bestimmte Marke von Hardware-Wallet besitzt, und ich muss nicht raten, wem ich den gefälschten Firmware-Update-Brief schicke.

Wer betroffen ist

Die 39.798 Kunden tragen das primäre Risiko. Ihre Namen und Lieferadressen schweben jetzt in welchem Kanal auch immer der Angreifer nutzt, und das qualifizierende Signal („diese Person besitzt eine SafePal") ist bereits eingebettet. Es ist eine Welle von postalischem Phishing, gefälschten Ersatzgeräte-Lieferungen, gefälschten Support-Anrufen und der besonders unangenehmen Variante zu erwarten, bei der jemand an einer physischen Adresse auftaucht und behauptet, vom Anbieter zu sein. SafePals eigener Hinweis, dass durch Phishing getäuschte Nutzer ihre Wallets als kompromittiert betrachten sollten, leistet in diesem Satz schwere Arbeit.

SafePal selbst erleidet einen Markenschaden, der schwer zu beziffern, aber leicht zu spüren ist. Wenn die gesamte Botschaft lautet „wir sind das Sicherheitsunternehmen", wirkt eine Panne im Bestellsystem schlimmer als dieselbe Panne bei einem Matratzenhändler. Die 90-Tage-Aufbewahrungszusage und das unabhängige Audit sind die richtigen Maßnahmen – und sie wurden schnell umgesetzt, was zählt.

Die breitere Hardware-Wallet-Kategorie bekommt ebenfalls Schaden ab. Trezor warnte früher 14.000 Kunden, nachdem ein Fulfillment-Partner eine Datenpanne erlitten hatte. Ledgers Kundendatenbankleck von 2020 wird noch in jedem ernsthaften Bedrohungsüberblick zitiert. Es gibt ein Muster, und es geht nicht um die Wallets. Es geht um die Einzelhandels-Infrastruktur dahinter. Jeder CISO bei einem Hardware-Anbieter, der das an einem Montagmorgen liest, stellt sich dieselbe Frage: Wie sieht unsere Bestellpipeline aus, und wer hat sie zuletzt geprüft?

Für iGaming- und Fintech-Leser, die meinen, das sei jemand anderes Problem: Schauen Sie sich Ihre eigenen KYC-nahen Systeme an. Loyalty-Plattformen, Einzahlungsbestätigungs-E-Mails, Kurier-Integrationen für physische Karten. Gleiche Risikoform, gleiche Fehlerklasse, gleiche „wir haben es nicht als sicherheitskritisch betrachtet"-Entstehungsgeschichte.

Leitfaden für Sicherheitsteams

Drei Dinge, die es diese Woche zu tun gilt, in der Reihenfolge der Peinlichkeit, wenn man sie auslässt.

Erstens: Durchsuchen Sie Ihre Codebase und Ihre Drittanbieter-Plug-ins nach Objektabfrage-Endpunkten, die einer Sitzung, aber keinem Eigentumsanspruch vertrauen. Alles in der Form GET /orders/:id, /tickets/:id, /documents/:id. Automatisierte IDOR-Scanner erkennen die offensichtlichen Fälle. Manuelle Prüfung erkennt diejenigen, bei denen die Prüfung zwar existiert, aber nur für die „Ansicht"-Route und nicht für die „PDF herunterladen"-Route. Das ist der langweilige Teil – und genau dort leben die Fehler.

Zweitens: Behandeln Sie Datenhaltung als Sicherheitskontrolle, nicht als Compliance-Pflicht. SafePals Umstieg auf 90-tägige Aufbewahrung von Bestelldaten ist der richtige Instinkt: Daten, die man nicht hat, können nicht leaken. Bestellverarbeitungssysteme sammeln personenbezogene Daten wie Keller Kartons ansammeln. Aggressive TTLs auf Versanddatensätze, Kontaktdaten und veraltete Kundenimporte verkleinern den Schadenradius des nächsten Plug-in-Fehlers, den man noch nicht kennt.

Drittens: Führen Sie ein Tabletop-Übung für das Szenario „unsere Kundenliste ist öffentlich, unser Produkt ist in Ordnung" durch. Kommunikation, Recht, Support und Technik reagieren darauf anders als auf ein Geldverlust-Ereignis, und die meisten Incident-Playbooks sind für den Geldverlust-Fall geschrieben. Wer entwirft die E-Mail? Wer überwacht die Phishing-Seiten? Wer spricht mit dem Prüfer? SafePal entfernte infolge dieses Vorfalls mehr als 30 betrügerische Domains, was bedeutet, dass jemand einen Takedown-Workflow bereit hatte. Wenn Ihr Team das nicht hat, bauen Sie es, bevor Sie es brauchen.

Bonus: Wenn Sie physische Waren an Kunden verkaufen, die Wert auf Privatsphäre legen, fragen Sie sich, ob Sie die Lieferadresse wirklich noch benötigen, nachdem das Paket zugestellt wurde. Neun von zehn Mal lautet die Antwort: Nein.

Wichtigste Erkenntnisse

• SafePals Datenpanne legte Bestelldaten von 39.798 Kunden zwischen dem 2. März 2025 und dem 11. April 2026 über eine Autorisierungslücke in einem Bestellverfolgung-Plug-in offen. Guthaben, Schlüssel und Seed-Phrasen blieben unberührt.
• Die wahrscheinliche Fehlerklasse ist IDOR oder ähnliches – das Plug-in-Ökosystem rund um E-Commerce ist die eigentliche Angriffsfläche, nicht die Wallet-Firmware.
• Betroffene Kunden sind einem erhöhten zielgerichteten Phishing-Risiko ausgesetzt, da die geleakten Daten sowohl die Identität als auch den Produktbesitz bestätigen.
• SafePals Reaktion (schnelle E-Mail-Benachrichtigung, Drittanbieter-Audit, 90-Tage-Aufbewahrungsgrenze, mehr als 30 Phishing-Seiten entfernt) ist die Vorlage, die andere Anbieter kopieren sollten.
• Zurück zum Schlosser: Das Sicherheitsschloss ist nur so privat wie die Kundenliste im Hinterzimmer. Prüfen Sie das Hinterzimmer.