Stripe-Schlüssel offengelegt: 688.363 Kundendatensätze gefährdet

Die am 18. August 2026 veröffentlichte Sammlung sieht nach einer massenhaften Kompromittierung von Händler-Zugangsdaten aus – nicht nach einem bestätigten Angriff auf Stripes eigene Systeme. Ein Akteur unter dem Alias „Satanic“ soll das Material im Untergrundforum pwnforums veröffentlicht haben. Darin befanden sich offenbar aktive geheime API-Schlüssel sowie Daten, die aus einzelnen Händlerkonten abgerufen worden waren.

Der gemeldete Umfang

Die detaillierteste Analyse beschreibt einen Datensatz mit:

• 659 Händlerkonten
• 650 aktiven sk_live-Schlüsseln
• schätzungsweise 688.363 Kundendatensätzen
• Händlern aus 42 Ländern
• rund 35 GB Daten in 17.654 Dateien

Das Material soll unter anderem Daten und Vorgänge zu folgenden Bereichen enthalten haben:

• Belastungen und Zahlungen
• Payment Intents
• Rechnungen
• Auszahlungen
• Rückerstattungen
• Kontobewegungen und Saldo-Transaktionen

Die Datensätze stammten demnach aus dem Zeitraum von Januar 2022 bis Juni 2026.

Besonders kritisch ist, dass 519 der 659 Konten offenbar sowohl Zahlungen annehmen als auch Auszahlungen veranlassen konnten. Solange die betreffenden Zugangsschlüssel aktiv blieben, hätte diese Kombination betrügerische Zahlungsvorgänge oder Versuche zur Umleitung von Geldern erleichtern können.

Die meisten betroffenen Händler wurden in den USA mit 212 Konten verortet. Es folgten das Vereinigte Königreich mit 81 und Frankreich mit 57 Konten.

Wer veröffentlichte die Daten?

Die Veröffentlichung wird dem Akteur „Satanic“ zugeschrieben. Er soll die Daten am 18. August im Forum pwnforums bereitgestellt haben – offenbar zum kostenlosen Download und nicht als klassisches Verkaufsangebot.

Allerdings stimmen die Zahlen der ersten Veröffentlichung nicht vollständig mit dem später validierten Datensatz überein. Eine Analyse von Hudson Rock sprach von 669 Händlerordnern, 1.033 kompromittierten API-Schlüsseln und einem angeblichen Archiv von 33 GB.

Die Abweichungen könnten auf unterschiedliche Veröffentlichungsphasen, Zählweisen oder Validierungskriterien zurückgehen. Sie sollten deshalb nicht zu einer einzigen, zweifelsfrei bestätigten Gesamtsumme zusammengeführt werden. Auch die Behauptung, der Akteur verfüge über rund 20.000 weitere Stripe-API-Schlüssel, wurde nicht unabhängig bestätigt.

Hudson Rock berichtete außerdem, dass das Forum mit 33 GB geworben habe, während das tatsächlich herunterladbare Archiv nur etwa 2,37 GB groß gewesen sei. Diese Differenz ist mit der Behauptung vereinbar, dass weiteres Material außerhalb des ersten Downloads existiert haben könnte – sie beweist diese Behauptung jedoch nicht.

Warum es offenbar kein Einbruch in Stripes Infrastruktur war

Nach bisheriger Einschätzung lässt sich der Datenzugriff dadurch erklären, dass Angreifer gestohlene geheime Händler-Schlüssel für reguläre Stripe-API-Anfragen verwendeten. Die Daten wären in diesem Szenario über Zugangsdaten abgerufen worden, die bereits Zugriff auf einzelne Händlerkonten gewährten – nicht durch eine Schwachstelle in Stripes zentralen Systemen. Hinweise auf eine Kompromittierung von Stripes Kerninfrastruktur wurden von den Forschern nicht gefunden.

Als mögliche Quellen der offengelegten Schlüssel gelten unter anderem:

• Protokolle von Infostealern
• öffentliche Commits in Code-Repositories
• zugängliche .env-Dateien
• unsichere Backups
• CI/CD-Protokolle
• falsch konfigurierte Webserver
• automatisierte Suche nach Umgebungsvariablen und anderen schlecht geschützten Geheimnissen

Zum Zeitpunkt der Berichte war keine Infostealer-Infektion eindeutig mit den konkret aufgeführten Händler-Domains verknüpft. Die ursprüngliche Quelle der Zugangsdaten blieb daher offen.

Der Unterschied ist für die Reaktion auf den Vorfall entscheidend: Ein Einbruch in Stripes Infrastruktur wäre ein plattformweiter Sicherheitsvorfall. Ein Leak von Händler-Schlüsseln deutet dagegen auf zahlreiche separat offengelegte Geheimnisse hin, die anschließend gegen die jeweils berechtigten Konten eingesetzt wurden.

Was ein einziger aktiver Schlüssel ermöglichen konnte

Forscher berichteten, dass ein einziger aktiver Schlüssel ausreichte, um innerhalb von 17 Stunden die Kundenliste eines Händlers abzurufen, einen betrügerischen Payment Link zu erstellen und eine Testzahlung auszuführen.

Das zeigt, warum ein aktiver, weitreichend berechtigter Geheimschlüssel wie ein unmittelbarer Sicherheitsvorfall behandelt werden muss. Ein Angreifer muss Stripe nicht selbst knacken, wenn der Schlüssel bereits Zugriff auf Kundendaten und Zahlungsfunktionen ermöglicht.

Das Risiko beschränkt sich damit nicht auf die Offenlegung von Daten. Abhängig von den Berechtigungen des Schlüssels und der Kontokonfiguration könnten Unbefugte Zahlungsinformationen einsehen oder Aktionen rund um Payment Links, Belastungen, Rückerstattungen und Auszahlungen ausführen. Der veröffentlichte Datensatz enthielt mehrere dieser Vorgangstypen; daraus folgt jedoch nicht, dass bei jedem aufgeführten Konto tatsächlich Betrug festgestellt wurde.

Warum das Scannen von GitHub allein nicht genügt

Der Fall macht außerdem deutlich, dass das Durchsuchen öffentlicher Code-Repositories keinen vollständigen Schutz für Zahlungszugangsdaten bietet. Forscher fanden mögliche Leckstellen unter anderem in GitHub-Actions-Protokollen, historischen Artefakten, öffentlichen .env-Dateien, Backups und falsch konfigurierten Servern – also an Orten, die von einer einfachen Repository-Prüfung möglicherweise nicht erfasst werden.

Separat wurde berichtet, dass Forscher mehr als 50.000 Stripe-Geheimnisse in öffentlichem Code, GitHub-Actions-Protokollen und falsch konfigurierten Servern gefunden hätten. Diese Zahl beschreibt das größere Problem offengelegter Schlüssel, bestätigt aber nicht, dass all diese Schlüssel Teil der Veröffentlichung vom 18. August waren.

Für Unternehmen bedeutet das praktisch: Einen Schlüssel aus dem aktuellen Repository zu löschen, macht ihn nicht automatisch ungültig. Kopien können weiterhin in der Commit-Historie, in Build-Protokollen, Artefakten, Backups oder bereits ausgerollten Systemen liegen. Ein möglicherweise offengelegter Schlüssel muss deshalb gesperrt oder rotiert werden; zugleich sollten die betroffenen Systeme untersucht werden.

Was Stripe-Händler jetzt tun sollten

Betroffene oder potenziell betroffene Unternehmen sollten zunächst den Zugriff eindämmen:

1. Möglicherweise offengelegte Live-Schlüssel sofort sperren oder rotieren. Das Entfernen einer Datei oder eines Repository-Eintrags reicht nicht aus, um einen Schlüssel ungültig zu machen.
2. Stripe-API- und Kontoaktivitäten prüfen – insbesondere unbekannte IP-Adressen, Zugriffe auf Kundenlisten, Datenexporte, die Erstellung von Payment Links, Zahlungsversuche, Rückerstattungen und Auszahlungen.
3. Bankverbindungen für Auszahlungen sowie kürzlich geänderte Auszahlungsdaten kontrollieren. Bei Bedarf sollten Unternehmen Überweisungen vorübergehend stärker überwachen oder zusätzliche Freigaben verlangen.
4. Breit berechtigte Schlüssel durch eingeschränkte Schlüssel ersetzen, die nur die tatsächlich benötigten API-Operationen erlauben.
5. Geheimnisse in einem verwalteten Secret-Store hinterlegen und sie aus Quellcode, Umgebungsdateien, Protokollen und ungeschützten Backups entfernen.
6. Historische Repositories, CI/CD-Protokolle, Artefakte, Server und Backups durchsuchen – nicht nur den aktuell öffentlichen Code.

Die derzeitige Beweislage spricht für ein ernstes Leak von Händler-Zugangsdaten mit erheblichem Risiko für Kunden- und Zahlungsdaten. Sie belegt jedoch keinen Einbruch in Stripes zentrale Infrastruktur. Wegen der widersprüchlichen Zahlen sollten die genannten Werte außerdem als datensatzbezogene Schätzungen und nicht als endgültiges Gesamtinventar verstanden werden.