Beacon-CRM-Datenleck: AWS-Schlüssel legt Daten von 1.000+ Organisationen offen

Ein einziger vergessener Zugangsschlüssel – und die Daten von über 1.000 Organisationen sind womöglich in fremden Händen. Genau das ist beim britischen CRM-Anbieter Beacon passiert. Der Angreifer brauchte keine ausgefeilte Schwachstelle, keinen Zero-Day-Exploit, sondern schlicht einen gültigen AWS-Zugangsschlüssel, der offenbar öffentlich im Programmcode der Web-Anwendung auffindbar war. Mit diesem Schlüssel konnte er nach Angaben von Beacon vermutlich die komplette Datenbank inklusive aller Anhänge herunterladen – in lesbarer Form. Wer Beacon nutzt oder Daten dorthin übermittelt hat, muss jetzt handeln. Und alle anderen Website-Betreiber sollten diesen Fall als Weckruf verstehen.

Was ist passiert?

Beacon CRM ist ein britischer SaaS-Anbieter (Software-as-a-Service, also Software, die man mietet und im Browser nutzt, statt sie selbst zu installieren) für Wohltätigkeits- und Non-Profit-Organisationen. Am 4. August 2026 veröffentlichte das Unternehmen ein ausführliches Update, in dem es einen Datenabfluss bestätigte. Am 12. August 2026 präzisierte Beacon dann die vermutete Ursache: ein kompromittierter AWS-Zugangsschlüssel, der möglicherweise in öffentlich erreichbaren JavaScript-Build-Artefakten der Anwendung offengelegt war.

Der Zeitpunkt lässt sich recht genau eingrenzen. Laut Beacon begann die früheste beobachtete bösartige Aktivität am 27. Juli 2026 um 01:20:16 UTC und dauerte etwa eine Stunde und 27 Minuten. Die AWS-Kosten- und Nutzungsberichte zeigten am 27. und 28. Juli einen auffälligen Anstieg des Datentransfers – ein Indiz für einen umfangreichen Download.

Die entscheidende und unangenehme Botschaft: Welche konkreten Objekte heruntergeladen wurden und wohin, lässt sich aus den vorhandenen Protokollen nicht mehr sicher feststellen. Beacon-CTO David Simpson formulierte es so:

„Specific objects, exact destination of the downloads, and definitive attribution of which objects were accessed cannot be determined from available logs.“
(David Simpson, Chief Technology Officer, Beacon – beaconcrm.org/incident)

Weil das übertragene Datenvolumen im Verhältnis zum Gesamtspeicher so hoch war, bewertet Beacon einen Export der gesamten Datenbank als wahrscheinlich. Für betroffene Kunden bedeutet das im Zweifel: Alle in Beacon gespeicherten Informationen einschließlich Anhängen könnten abgeflossen sein.

Der technische Hintergrund – verständlich erklärt

Um zu verstehen, warum dieser Vorfall so gefährlich ist, muss man zwei Dinge auseinanderhalten. Dies war keine klassische Software-Schwachstelle. Es gibt keine CVE-Nummer (die standardisierte Kennung für öffentlich dokumentierte Sicherheitslücken), keinen veröffentlichten Exploit und keine betroffene Softwareversion, die man einfach patchen könnte. Stattdessen handelt es sich um den Missbrauch gültiger Cloud-Zugangsdaten.

Der wahrscheinliche Zugangspfad: Ein AWS Access Key – ein digitaler Schlüssel, mit dem man auf Amazon-Cloud-Dienste zugreift – lag offenbar in den JavaScript-Build-Artefakten der Anwendung. Das sind die Browser-Dateien, die jede Webanwendung an ihre Besucher ausliefert. Der springende Punkt: Alles, was im Browser landet, ist prinzipiell für jeden abrufbar. Ein Geheimnis in einer solchen Datei ist damit kein Geheimnis mehr.

Besonders tückisch: Die sogenannte Verschlüsselung ruhender Daten (englisch „encryption at rest“ – die Daten liegen verschlüsselt auf den Servern) half in diesem Fall überhaupt nicht. Denn der Angreifer nutzte gültige Zugangsdaten. AWS liefert für einen berechtigten Zugriff die Daten automatisch entschlüsselt aus. Die Verschlüsselung schützt gegen Diebstahl der Festplatte – nicht gegen einen Angreifer mit gültigem Schlüssel.

Immerhin: Beacon fand nach eigenen Angaben weder Persistenzmechanismen (also dauerhaft eingerichtete Hintertüren) noch konnte eine Tätergruppe zugeordnet werden. Und zum Stand 12. August lag laut Online-Monitoring von Beacon kein Hinweis auf eine Veröffentlichung oder einen Missbrauch der Daten vor:

„There has been no indication from online monitoring that data associated with the incident has been published, disclosed or otherwise misused.“
(Beacon, Incident Update vom 12.08.2026)

Das ist eine gute Nachricht – aber keine Entwarnung. Fehlender nachweisbarer Missbrauch entkräftet weder den möglichen Datenabfluss noch Ihre eigene Pflicht zur Risikobewertung.

Wer ist betroffen?

Beacon hat nach Medienangaben mehr als 1.500 Kunden. Die BBC berichtete anfänglich von mehr als 1.000 potenziell betroffenen Organisationen. Eine Zahl betroffener Personen oder Datensätze wurde nicht veröffentlicht.

Für deutsche KMU gilt: Allein durch den Betrieb einer Website sind Sie nicht betroffen. Konkret betroffen oder potenziell betroffen ist, wer Beacon vor dem Stichtag am 27. Juli 2026 genutzt oder Daten in eine Beacon-Instanz übermittelt hat. Öffentlich betroffene Organisationen nannten unter anderem folgende Datenkategorien:

• Namen von Unterstützern und Spendern
• E-Mail- und Postadressen
• Telefonnummern
• Angaben zu Spenden, Freiwilligenarbeit oder Veranstaltungen

Welche Daten genau bei Ihnen betroffen sein könnten, hängt vollständig von Ihrem eigenen Datenbestand in Beacon ab.

So prüfen Sie, ob Sie betroffen sind

1. Prüfen Sie Ihr Lieferanten- und Verarbeitungsverzeichnis. Gab es am oder vor dem 27.07.2026 ein Beacon-Konto, einen Testzugang oder eine CRM-/Website-Integration, die personenbezogene Daten an Beacon übermittelte? Ohne solche Nutzung besteht nach den verfügbaren Quellen keine spezifische Beacon-Betroffenheit.
2. Wenn Beacon eingesetzt wurde: Behandeln Sie alle damals gespeicherten Daten einschließlich Anhängen als potenziell exportiert. Beacon kann nicht verbindlich eingrenzen, welche Objekte abflossen.
3. Ermitteln Sie den betroffenen Datenbestand. Beacon empfiehlt, die Personenliste nach einem Erstellungsdatum vor dem 28.07. zu filtern oder eigene Sicherungen vom damaligen Stand heranzuziehen. Dokumentieren Sie Datenkategorien, Anzahl der Personen, besondere Kategorien, Minderjährige und Angaben mit Missbrauchspotenzial.
4. Inventarisieren Sie alle Integrationen. API-Keys, Formulare, Webhooks, Zahlungs- und Marketing-Dienste – alles, was mit Beacon verbunden ist.
5. Auch ohne Beacon-Nutzung: Prüfen Sie Ihre eigenen ausgelieferten JavaScript-Bundles, Quellcode-Repositories (inklusive Historie!), CI/CD-Variablen und Kollaborationstools auf versehentlich eingecheckte Secrets. Das ermittelt Ihr eigenes, gleichartiges Risiko – es belegt keine Beacon-Betroffenheit.

Das müssen Sie jetzt konkret tun

Wichtiger Hinweis zum Zeitplan: Es gibt keinen CVE-Patch und kein Versionsupdate, das Sie einspielen müssten. Beacon erklärt, die vermutete Ursache behoben, alle Zugangsdaten AWS-integrierter Dienste und Konten zurückgesetzt sowie EDR (Endpoint Detection and Response – Sicherheitsüberwachung auf Endgeräten, hier SentinelOne) und Cloud-Native-Security eingeführt zu haben. Ihre Aufgaben als Kunde:

1. Beacon-Passwörter sofort zurücksetzen. Ändern Sie die Passwörter aller Beacon-Nutzer auf lange, einzigartige Werte. Beacon fordert dazu ausdrücklich auf.
2. Alte Beacon-API-Keys widerrufen und neu ausstellen. Trennen Sie alle angebundenen Dienste nach dem jeweiligen Anbieterprozess und verbinden Sie sie mit neuen Schlüsseln erneut. Beacon nennt unter anderem Mailchimp, JustGiving, FundraiseUp, Dotdigital, SendGrid, MuchLoved, Enthuse, GoCardless und Zapier.
3. Datenschutzprozess starten. Legen Sie ein Incident-Log an, ermitteln Sie Daten- und Betroffenenkreis, prüfen Sie den Auftragsverarbeitungsvertrag und binden Sie Datenschutzbeauftragte und Leitung ein.
4. Meldepflicht prüfen. Verantwortliche müssen bei Risiko grundsätzlich binnen 72 Stunden ab Kenntnis an die Aufsichtsbehörde melden. Auch bei fehlender Meldepflicht ist der Vorfall zu dokumentieren.
5. Betroffeneninformation vorbereiten. Bei voraussichtlich hohem Risiko müssen die betroffenen Personen unverzüglich, klar und verständlich informiert werden.

Für Ihre eigenen Systeme

Selbst wenn Sie Beacon nie genutzt haben, ist die technische Kernlehre wertvoll:

• Keine Langzeit-Zugangsdaten in Client-Code. Niemals AWS-Keys oder andere Secrets in JavaScript-Bundles, Repositories oder Build-Logs ausliefern.
• Exponierte Schlüssel sofort deaktivieren und rotieren – nicht nur aus dem Code löschen. Ein einmal öffentlich gewordener Schlüssel bleibt kompromittiert, auch wenn er aus dem sichtbaren Code verschwindet.
• Temporäre statt langfristiger Zugangsdaten. AWS empfiehlt ausdrücklich IAM-Rollen mit kurzlebigen Credentials: „Where possible, we recommend relying on temporary credentials instead of creating long-term credentials such as access keys.“ (AWS IAM Best Practices)
• MFA, Least Privilege und regelmäßige Reviews. Multi-Faktor-Authentifizierung, minimale Rechtevergabe und die regelmäßige Prüfung nicht benötigter Zugangsdaten gehören zum Standard.
• Überwachung verbessern. Untersuchen Sie CloudTrail-Zugriffe und Kosten-/Datentransfer-Auffälligkeiten, richten Sie Alarme auf ungewöhnliche Datenbewegungen ein und prüfen Sie öffentliche und kontoübergreifende Zugriffe – etwa mit dem IAM Access Analyzer.

Wie verbreitet das Grundproblem ist, zeigt der GitGuardian-Report 2026: Allein 2025 wurden 28.649.024 neue Secrets in öffentlichen GitHub-Commits gezählt – ein Plus von 34 % gegenüber dem Vorjahr. Von den 2022 gefundenen validen Secrets waren vier Jahre später noch 64 % aktiv. GitGuardian bringt es auf den Punkt: „The problem isn't detection. It's remediation.“ Das Problem ist also nicht das Aufspüren, sondern das konsequente Aufräumen.

DSGVO-Einordnung: Was gilt in Deutschland?

Für deutsche Verantwortliche, die Beacon für Kunden-, Spender-, Mitglieder- oder Interessentendaten eingesetzt haben, ist der Vorfall typischerweise ein Auftragsverarbeiter-Fall. Wer genau Verantwortlicher und wer Auftragsverarbeiter ist, muss im konkreten Vertrag geprüft werden.

Die Rechtslage im Überblick:

• Art. 33 Abs. 2 DSGVO: Der Auftragsverarbeiter (hier Beacon) muss den Verantwortlichen unverzüglich informieren.
• Art. 33 Abs. 1 DSGVO: Der Verantwortliche meldet die Verletzung bei voraussichtlichem Risiko unverzüglich und möglichst binnen 72 Stunden ab Kenntnis an die zuständige Aufsichtsbehörde.
• Art. 34 DSGVO: Bei voraussichtlich hohem Risiko müssen die betroffenen Personen unverzüglich und klar benachrichtigt werden.
• Art. 33 Abs. 5 DSGVO: Es besteht in jedem Fall eine Dokumentationspflicht – auch wenn keine Meldung nötig ist.

Wichtig: Eine bloße Behauptung „die Daten waren verschlüsselt“ genügt hier nicht als Entlastung. Beim tatsächlichen Zugriff waren die Daten lesbar. Ihre Risikobewertung muss die konkreten Datenkategorien, Betroffenengruppen und wahrscheinlichen Folgen einbeziehen. Die LfD Niedersachsen weist zudem darauf hin, dass eine vorläufige Meldung fristwahrend sein kann – fehlende Details dürfen Sie nachreichen.

Ob ein Einzelfall meldepflichtig ist, ergibt sich also nicht automatisch aus der bloßen Beacon-Nutzung, sondern aus einer dokumentierten Risikobewertung.

Haftungsrisiko

Art. 83 Abs. 4 DSGVO sieht für Verstöße gegen die Sicherheitspflichten (Art. 32 fällt darunter) grundsätzlich Bußgelder bis zu 10 Mio. EUR oder 2 % des weltweiten Vorjahresumsatzes vor – je nachdem, welcher Betrag höher ist. Ein einschlägiges deutsches Beispiel ist der Fall 1&1: Der BfDI verhängte zunächst 9,55 Mio. EUR wegen unzureichender Zugriffssicherung; das Landgericht Bonn bestätigte 2020 den Art.-32-Verstoß und setzte die Buße auf 900.000 EUR fest. Der Fall ist technisch nicht identisch mit Beacon, zeigt aber, wie ernst deutsche Behörden und Gerichte mangelhafte Zugriffskontrollen nehmen.

Auch die britische Charity Commission hat den Fall auf dem Schirm und steht in Kontakt mit der dortigen Datenschutzbehörde ICO:

„Given the nature of this incident and the number of charities that may be affected, the Commission has been actively monitoring the situation and is in contact with the Information Commissioner’s Office (ICO).“
(UK Charity Commission)

Ein Hinweis zur Chronologie

Bei den Quellen gibt es eine Abweichung, die wir transparent halten: Beacons eigener Incident-Guide datiert das Bekanntwerden auf Mittwoch, den 29. Juli 2026. Ein BBC-Bericht vom 5. August nennt dagegen Montag, den 3. August, als Entdeckungszeitpunkt. Kunden wurden nach Beacons Angaben ab dem 3. August informiert.

Fazit

Der Beacon-Vorfall ist ein Lehrstück in Sachen Secret-Management und Cloud-Sicherheit. Kein spektakulärer Exploit, sondern ein einziger Schlüssel am falschen Ort hat die Daten von über 1.000 Organisationen gefährdet. Für aktive Beacon-Kunden vor dem 27. Juli 2026 ist das Risiko hoch: Beacon selbst hält einen Export sämtlicher Datenbankinhalte für wahrscheinlich, die Daten wurden mit gültigen Zugangsdaten in lesbarer Form abgerufen, und der genaue Umfang lässt sich nicht rekonstruieren. Namen, Kontakt- und Kontextdaten sind ideale Zutaten für gezieltes Phishing und Social Engineering.

Wenn Sie Beacon einsetzen: Setzen Sie jetzt Passwörter zurück, rotieren Sie alle API-Keys und starten Sie Ihren Datenschutzprozess – die 72-Stunden-Frist läuft ab Ihrer Kenntnis. Wenn Sie Beacon nicht nutzen: Nehmen Sie den Fall zum Anlass, Ihre eigenen JavaScript-Bundles und Code-Repositories auf versteckte Geheimnisse zu durchsuchen. Denn wie der Fall zeigt, kann ein einziger vergessener Schlüssel teuer werden – rechtlich und für das Vertrauen Ihrer Kunden.