87 Minuten, eine Woche zu spät rekonstruiert

Der eigentliche Einbruch dauerte rund 87 Minuten in den frühen Morgenstunden des 27./28. Juli 2026. Laut CTO David Simpson lag ein AWS-Zugriffsschlüssel offen in JavaScript-Build-Artefakten, die direkt von Beacons eigener öffentlicher Website ausgeliefert wurden, also genau dem Client-Bundle, das jeder Browser eines Besuchers herunterlädt, ohne dass irgendein Alarm auslöst.

Beacon erkannte den Einbruch nicht in Echtzeit. Simpson zufolge rekonstruierte das Unternehmen den Vorfall erst nachträglich anhand von AWS Cost and Usage Reports für Mai bis Juli 2026 und fand dabei einen Anstieg der Datentransferkosten genau an den beiden fraglichen Tagen, ein Beleg, der zur Download-Aktivität passt, statt aus einem laufenden Erkennungssystem zu stammen.

Diese rückwirkende Methode erklärt die Lücke bei der Offenlegung: Der Vorfall geschah am 27./28. Juli, Beacon informierte Kunden am 4. August und veröffentlichte am 13. August ein Update, das immer noch nicht alle Fragen klären konnte. Simpson sagte Kunden direkt, dass es Dinge geben werde, die man zu diesem Vorfall vielleicht nie herausfinden werde, und versprach in den kommenden Wochen weitere Details.

Wer tatsächlich betroffen ist

Beacons Kundenstamm umfasst mehr als 1.500 Wohltätigkeitsorganisationen, und das Unternehmen hat ausdrücklich erklärt, noch nicht festgestellt zu haben, bei wie vielen davon tatsächlich Daten abgeflossen sind, nur dass eine vollständige Kopie der Datenbank inklusive Anhangdateien angefertigt und mit hoher Wahrscheinlichkeit im Klartext heruntergeladen wurde.

The Register nennt konkret betroffene Organisationen, darunter Molly Rose Foundation, Macmillan Cancer Support Jersey, English National Ballet, Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, British Deaf Association und Lincoln Cathedral, eine Spannweite von Trauerbegleitung über Krankenhaus-Fundraising bis zu Behindertenverbänden und Kulturerbe.

Das sind keine klinischen Patientendaten wie bei einem Krankenhaus selbst, doch Spender- und Unterstützerdaten bei solchen Organisationen betreffen regelmäßig Menschen in Trauer, Krankheit oder Krise, genau die Gruppe, die eine verantwortliche Stelle eigentlich mit mehr Sorgfalt schützen sollte als eine gewöhnliche Adressliste, nicht weniger.

Die Lücke, die DORA und NIS2 schließen sollten, aber nicht erreichen

Die EU-Verordnung DORA verpflichtet Finanzunternehmen, unter Artikel 28 bis 30 ein Register jedes IKT-Drittanbieters zu führen und dessen Risiko zu bewerten, gerade damit die Sicherheitslage eines Anbieters vor und nicht erst nach einem Vorfall geprüft wird. NIS2 verlangt vergleichbare Sicherheits- und Meldepflichten von wesentlichen und wichtigen Einrichtungen in Energie, Gesundheit, digitaler Infrastruktur und öffentlicher Verwaltung.

Wohltätigkeitsorganisationen und die SaaS-Anbieter, die sie bedienen, fallen aus beiden Regimen vollständig heraus. Ihr einziges Auffangnetz ist das allgemeine Rechenschaftsprinzip der britischen DSGVO-Fassung, das eine Wohltätigkeitsorganisation weiterhin als Verantwortliche haftbar macht, selbst wenn das Produkt eines Auftragsverarbeiters versagt, sowie das freiwillige Meldeverfahren der Charity Commission, die selbst erklärt, Meldungen nach Risiko zu priorisieren statt alle gleichzeitig zu bearbeiten.

Das ist der Servola-Befund, der in keinem Einzelbericht so auftaucht: Ein Schlüssel, der in öffentlichem JavaScript liegen bleibt, ist genau die Art von einfachem Fehler bei der Geheimnisverwaltung, die DORAs verpflichtender Penetrationstest und Prüfpfad bei regulierten Anbietern vor Vertragsabschluss abfangen soll. Nimmt man dieses Regime weg, wie beim gemeinnützigen Sektor, findet die Prüfung, die eigentlich in der Beschaffung stattfinden sollte, jetzt im Nachhinein statt, Meldung für Meldung bei der Charity Commission.

Was eine Wohltätigkeitsorganisation vor der Vertragsverlängerung fragen sollte

Die praktische Antwort braucht kein neues Gesetz. Jede Organisation, die einen SaaS-Vertrag unterschreibt oder verlängert, kann direkt Belege für automatisiertes Secret-Scanning in der Build-Pipeline des Anbieters verlangen, eine schriftliche Zusage zur Reaktionszeit bei Vorfällen und die Bestätigung, welche Spender- oder Begünstigtenfelder wirklich nötig sind und welche nur bequem.

Das Muster ist nicht auf Beacon beschränkt. Anbieterlecks durch einfache Fehler bei der Zugangsdatenverwaltung, vom bislang unerklärten Social-Engineering-Vorfall bei RingCentral bis zur Kompromittierung des Versanddienstleisters bei Trezor und ShipMonk, wiederholen sich, weil Lieferketten-Sicherheitsstandards für regulierte Sektoren nicht automatisch auf benachbarte Sektoren übertragen werden, die dieselbe Software-Klasse mit einem Bruchteil des Sicherheitsbudgets und ohne vertragliche Druckmittel einkaufen.

Solange dieses Druckmittel für Wohltätigkeitsorganisationen nicht existiert wie für Banken unter DORA, erledigt die freiwillige Meldung bei der Charity Commission die Kontrollfunktion, die derzeit keine externe Aufsicht übernehmen kann, eine unterbesetzte Organisation und eine Meldung nach der anderen.

Weiterlesen: 45.601 Lücken, 171 werden wirklich genutzt  |  Eine Nachricht erreichte die SSH-Schlüssel