Werkzeuge

Im Juni 2026 bestätigte der dänische Pharmariese Novo Nordisk ein schweres Datenleck. Laut Berichten von HIPAA Journal, FiercePharma und Silicon UK behauptete eine Erpressergruppe namens FulcrumSec, sie habe 1,3 TB an Daten gestohlen, und forderte ein Lösegeld von 25 Millionen Dollar, dessen Zahlung Novo Nordisk verweigerte. Für Entwickler ist das wichtigste Detail nicht das Lösegeld - es ist die Art, wie sich die Angreifer nach Darstellung der Gruppe Zugang verschafften.

Nach den eigenen Angaben der Gruppe, wie Silicon UK und andere berichteten, erfolgte der erste Zugriff über Geheimnisse, die in clientseitigem JavaScript zurückgelassen wurden. Das ist ein Fehler, der jedem Web-Team unterlaufen kann, und er ist ein klarer, vermeidbarer Fehler. Hier ist, was geschah, warum es wichtig ist und wie Sie verhindern, dass es Ihrem eigenen Code passiert.

Was Novo Nordisk offengelegt hat

Novo Nordisk machte den Vorfall am 11. Juni 2026 öffentlich und veröffentlichte auf der eigenen Website ein Vorfall-Update. Kurz darauf setzte FulcrumSec das Unternehmen laut BankInfoSecurity mit Beispieldaten aus der behaupteten Beute von 1,3 TB auf seine Dark-Web-Leak-Seite. Als das Unternehmen die Zahlung des genannten Lösegelds von 25 Millionen Dollar verweigerte, begann die Gruppe, die gestohlenen Daten zu veröffentlichen.

Das gestohlene Material umfasst laut Yahoo Finance und FiercePharma Informationen zu klinischen Studien, geistiges Eigentum sowie KI-Modelle, die für die Wirkstoffforschung genutzt werden. FulcrumSec, eine Cyber-Erpressergruppe, die mindestens seit September 2025 aktiv ist, erklärte, sie verfolge zudem private Verkäufe der gestohlenen Forschungsdaten. Novo Nordisk hat die technischen Behauptungen der Angreifer nicht im Detail bestätigt, weshalb die Angaben zum Einstiegspunkt als Darstellung der Gruppe zu behandeln sind.

Wie die Angreifer Berichten zufolge eindrangen

Nach Darstellung von FulcrumSec, wie Silicon UK berichtete, verschaffte sich die Gruppe im März 2026 Zugang über Geheimnisse, die in clientseitigem JavaScript auf zwei separaten Subdomains von Novo Nordisk zurückgelassen wurden. Im Klartext: Sensible Zugangsdaten wurden im eigenen JavaScript der Website an den Browser ausgeliefert, wo sie jeder lesen konnte.

• Halten Sie jedes Geheimnis serverseitig (Umgebungsvariablen oder ein Secrets-Manager)
• Liefern Sie niemals Zugangsdaten in clientseitigem JavaScript aus
• Beschränken Sie jedes Token auf den minimal nötigen Zugriff
• Rotieren Sie Zugangsdaten regelmäßig - und sofort bei Offenlegung
• Fügen Sie Ihrer CI-Pipeline ein automatisiertes Secret-Scanning hinzu

Die Gruppe gab an, zu diesen Geheimnissen hätten Zugangsdaten für eine Azure Container Registry und ein persönliches Zugriffstoken von GitHub gehört, das nach eigenen Angaben Zugriff auf Hunderte Repositories hatte. Ein einziges geleaktes Token mit weitreichenden Rechten kann eine unbedachte Codezeile in ein unternehmensweites Datenleck verwandeln. Genau darin liegt die Gefahr eines fest im Code hinterlegten Geheimnisses: Es tut genau das, wofür es gebaut wurde - für jeden, der es findet.

Warum Geheimnisse im Client-Code so gefährlich sind

Clientseitiges JavaScript ist per Definition öffentlich. Der Browser jedes Besuchers lädt es herunter, und jeder kann die Entwicklertools oder das rohe Bundle öffnen und es lesen. Einen verborgenen Wert im Frontend-Code gibt es nicht - Minifizierung oder Obfuskierung bremsen einen Leser nur aus, sie verbergen nichts. Wenn ein Geheimnis an den Browser ausgeliefert wird, betrachten Sie es als bereits geleakt.

Dasselbe Risiko gilt für Tokens, die in ein Git-Repository committet, in ein Container-Image eingebacken oder in ein Build-Log geschrieben werden. Automatisierte Scanner durchsuchen öffentliche Websites und Code-Hoster rund um die Uhr genau nach solchen Zeichenketten. Ein Token, das weitreichenden Zugriff gewährt - wie ein persönliches Zugriffstoken mit Hunderten Repositories im Geltungsbereich - ist der schlimmste Fall, denn ein einziges Leck legt alles offen, was es erreichen kann.

Wie Sie Geheimnisse aus Ihrem Client-Code heraushalten

Die Lösung ist eine Disziplin, kein einzelnes Werkzeug. Halten Sie jedes Geheimnis serverseitig, in Umgebungsvariablen oder einem dedizierten Secrets-Manager, und lassen Sie keines in das Browser-Bundle gelangen. Beschränken Sie jedes Token auf das Minimum, das es braucht, rotieren Sie Zugangsdaten regelmäßig und rotieren Sie sie sofort, wenn sie möglicherweise offengelegt wurden. Fügen Sie Ihrer Pipeline ein automatisiertes Secret-Scanning hinzu, damit ein committeter Schlüssel erkannt wird, bevor er ausgeliefert wird.

Frontend-Code, der einen geschützten Dienst aufrufen muss, sollte über Ihren eigenen Server oder eine Serverless-Funktion laufen, die das Geheimnis hält, statt das Geheimnis selbst zu tragen. Wenn Sie eine geleakte Zugangsdaten finden, ist die Reihenfolge einfach: erst widerrufen, dann untersuchen. Ein widerrufenes Token ist harmlos, egal wer es kopiert hat.

Das ehrliche Fazit

Das Datenleck bei Novo Nordisk erinnert daran, dass die schädlichsten Fehler oft die grundlegendsten sind. Die Behauptungen der Angreifer bleiben die Darstellung der Angreifer, und Novo Nordisk hat den Einstiegspunkt selbst nicht im Detail dargelegt. Doch die Lehre steht für sich: Ein Geheimnis im clientseitigen Code ist ein öffentliches Geheimnis. Bewahren Sie Zugangsdaten auf dem Server auf, beschränken und rotieren Sie sie und scannen Sie danach, bevor sie ausgeliefert werden.