Kritische Sicherheitslücke in Healthcare-Chatbot

Es war ein ganz normaler Tag

Ich war dabei, die Website eines langjährigen Kunden zu warten – ein Unternehmen im US-amerikanischen Gesundheitswesen, das psychische Gesundheitsdienste anbietet. Alle Namen und identifizierenden Details sind bewusst anonymisiert. Routine-Updates. Plugin-Checks. Performance-Monitoring. Nichts Besonderes.

Dann fiel mir der Chatbot auf.

Ein kleines Widget in der unteren rechten Ecke der Website. “Sprechen Sie mit unserem virtuellen Assistenten” – ein KI-Chatbot, der Patienten bei der Terminbuchung und ersten Fragen unterstützt. Der Chatbot stammte von einem Drittanbieter, der sich als “HIPAA-konforme Enterprise-Healthcare-Chatbot-Lösung” vermarktet.

HIPAA regelt in den USA den Schutz bestimmter Gesundheitsinformationen. Mein Kunde hatte den Anbieter unter anderem wegen dessen Compliance-Aussage gewählt. Ob ein konkretes System rechtlich konform ist, lässt sich aber nicht allein aus einem Anbieter-Label ableiten.

Im vereinbarten technischen Kontext fiel die Integration auf, deshalb sah ich mir ihren ausgelieferten Code genauer an.

Die Prüfung zeigte eine kritische Angriffskette.

Die erste Entdeckung: Ein Schlüssel, der nicht hätte existieren dürfen

Wenn du JavaScript-Code analysierst, der von einer Website ausgeliefert wird, findest du oft obfuskierten Code – absichtlich unlesbar gemachten Code, der die Funktionsweise verschleiern soll. Das ist normal. Viele Anbieter tun das, um ihr geistiges Eigentum zu schützen.

Was nicht normal ist: sensible Daten in diesem Code zu verstecken und zu hoffen, dass niemand hinschaut.

Ich fand einen AES-Schlüssel für die clientseitige Verschlüsselung. Direkt im JavaScript. Obfuskiert, aber extrahierbar. Mit diesem Schlüssel konnte ich entschlüsseln, was die Anwendung verschlüsselte.

Das Problem: Diese “Verschlüsselung” war die einzige Sicherheitsebene zwischen der Außenwelt und… nun ja, allem.

Die Kette bricht: Von einem Schlüssel zum vollen Zugriff

Mit dem extrahierten Schlüssel konnte ich:

API-Token entschlüsseln und fälschen – Die Anwendung nutzte verschlüsselte Token für die API-Kommunikation. Mit dem Schlüssel konnte ich eigene Token erstellen.
Auf die Backend-API zugreifen – Die API hatte eine kritische Fehlkonfiguration: Sie akzeptierte Anfragen von jeder Quelle (CORS-Wildcard). Normalerweise sollte eine API nur Anfragen von autorisierten Domains akzeptieren.
Cloud-Zugangsdaten extrahieren – Und hier wurde es wirklich kritisch. Die API lieferte verschlüsselte Zugangsdaten zurück. Mit dem Schlüssel konnte ich sie entschlüsseln: Ein vollständiger Service-Account-Schlüssel für die Cloud-Infrastruktur.

Damit waren Zugangsdaten zum Dialogflow-Agenten des Chatbots erreichbar.

Die Tragweite: Was ein Angreifer hätte tun können

Bevor ich meinem Kunden Bericht erstattete, musste ich verstehen, wie schlimm es wirklich war. Ich ging daher tiefer in die Analyse – streng im Rahmen meiner Wartungsvereinbarung und nur um die Schwere einzuschätzen – und verifizierte, ob die Zugangsdaten funktionieren.

Sie funktionierten.

Erst als die Tragweite klar war, informierte ich meinen Kunden umgehend und stoppte weitere Tests. Es wurden keine Daten verändert, gelöscht oder exfiltriert.

Mit diesen Zugangsdaten hatte ich Zugriff auf:

Vollständige Lese- und Schreibrechte auf den Dialogflow-Agenten des Chatbots. Ich konnte die therapeutischen Antworten lesen, die der Chatbot an Patienten mit psychischen Problemen gab. Ich konnte diese Antworten verändern.

Ein Angreifer hätte:

Therapeutische Ratschläge manipulieren können – Bei einem Chatbot, der Menschen mit Spielsucht, Angstzuständen oder Depressionen unterstützt
Kriseninterventions-Protokolle löschen können – Die Antworten bei Suizidgedanken einfach entfernen
Patientendaten stehlen können – Trainingsdaten und Konversationslogs waren potenziell zugänglich
Den gesamten Chatbot ersetzen können – Import-Funktion mit vollen Rechten

Die Schwachstelle war praktisch ausnutzbar und betraf einen sensiblen Anwendungskontext. Die Verifikation wurde deshalb nach Bestätigung der Tragweite beendet und unmittelbar eskaliert.

Warum das besonders gefährlich ist

In einem E-Commerce-Shop könnte ein Angreifer Preise verändern oder Bestellungen manipulieren. Ärgerlich, teuer, juristisch unangenehm. Aber in einem Healthcare-Kontext geht es um Vertrauen und Sicherheit. Menschen öffnen sich einem Chatbot oft in einer verletzlichen Situation. Sie stellen Fragen, die sie vielleicht nicht einmal ihrem Arzt stellen würden.

Wenn Antworten manipulierbar sind, entsteht ein Risiko, das über Datenschutz weit hinausgeht. Es geht um Fehlberatung, eskalierende Krisen und das Gefühl: „Ich kann dieser Plattform nicht mehr trauen.” In der mentalen Gesundheitsversorgung kann dieser Vertrauensverlust reale Folgen haben. Genau deshalb war für mich sofort klar: Das ist nicht nur eine technische Schwachstelle, sondern ein Risiko für Patientensicherheit.

Was ein beauftragter Review solcher Integrationen prüfen kann

Wenn Drittanbieter-Integrationen mit sensiblen Daten beauftragt geprüft werden, gehören je nach Scope unter anderem diese Bereiche dazu:

Client-Side-Code: Wird etwas Sensibles im Browser ausgeliefert, das nicht dort sein sollte?
Token-Handling: Sind Tokens statisch, leicht reproduzierbar oder im Frontend rekonstruierbar?
CORS & Authentifizierung: Darf jede Domain auf die API zugreifen, oder gibt es klare Regeln?
Rückkanäle: Liefert die API Konfiguration, Schlüssel oder IDs zurück, die intern bleiben sollten?
Session-Replay/Analytics: Zeichnet das System Eingaben auf? Sind Maskierungen aktiv?
Abhängigkeiten: Sind zentrale Libraries veraltet oder EOL? Gibt es kritische CVEs?
Marketing vs. Realität: Stimmen Datenschutzaussagen und Compliance-Claims mit dem Code überein?

Diese Checks sind kein Ersatz für eine vollständige Security-Analyse – aber sie reichen oft, um kritische Risiken früh zu entdecken.

Die unbequeme Wahrheit über “HIPAA-konforme” Drittanbieter

Ich analysierte den Code weiter und fand:

12+ bekannte Sicherheitslücken (CVEs) in veralteten Bibliotheken, darunter eine mit CVSS-Score 9.1 (kritisch)
Drei End-of-Life-Frameworks – Software, die keine Sicherheitsupdates mehr erhält
Session-Replay/Fehlertracking ohne Maskierung – Der Chatbot zeichnete 10% aller Patientensitzungen auf (bei Fehlern 100%) und übertrug sie an einen Drittanbieter-Session-Replay/Fehlertracking-Dienst. Patienteneingaben im Klartext.
Falsche Datenschutzaussagen – Der Chatbot behauptete gegenüber Nutzern: “Ich speichere keine persönlichen Informationen oder Konversationshistorie.” Der Code zeigte das Gegenteil.

Der Anbieter bewarb sich als “HIPAA-konform”. Die technische Realität war das genaue Gegenteil.

Die Meldung und die Eskalation

Am 14. Januar 2026 meldete ich die Schwachstelle an meinen Kunden. Die E-Mail war sachlich, aber unmissverständlich: KRITISCH – SOFORTIGE AKTION ERFORDERLICH.

Die Reaktion kam schnell. Mein Kunde informierte den Chatbot-Anbieter. Ein externer Sicherheitsdienstleister wurde hinzugezogen. Das Widget wurde serverseitig deaktiviert. Ich stellte zunächst eine redigierte Version des Reports bereit und bat für die vollständige Dokumentation um einen sicheren Übertragungsweg.

Kurze Timeline (vereinfacht)

Tag 0: Fund im Rahmen der Routine-Wartung
Tag 1: Meldung an den Kunden, formale Eskalation
Tag 1–2: Containment (Widget deaktiviert), Übergabe eines redigierten Reports
Woche 1–2: Remediation beim Anbieter
Woche 2: QA-Verifizierung der Maßnahmen

In den folgenden Wochen arbeitete der Anbieter an der Behebung:

Zugangsdaten widerrufen und rotiert
Sensible Daten aus dem Frontend-Code entfernt
CORS-Konfiguration korrigiert
Serverseitige Authentifizierung und Token-Handling implementiert
Serverseitige Verarbeitung statt Client-seitiger Entschlüsselung

Zwei Wochen später erhielt ich die Nachricht: “Alle Änderungen implementiert. Können Sie die Behebung verifizieren?”

Ich führte eine vollständige QA durch. Die ursprüngliche Angriffskette war unterbrochen. Die kritischen Schwachstellen waren behoben.

Responsible Disclosure: Warum ich redaktiert habe

In Sicherheitsvorfällen gilt: so viel wie nötig dokumentieren, aber so wenig wie möglich exponieren. Deshalb habe ich den Report anfangs nur redigiert geteilt – ohne Zugangsdaten oder sensible Details. Das schützt den Kunden, minimiert Missbrauchsrisiken und stellt sicher, dass die Behebung durch den Anbieter nicht unnötig gefährdet wird. Die vollständige technische Dokumentation habe ich erst über einen sicheren Übertragungsweg bereitgestellt.

Was wäre gewesen, wenn…

Ich denke oft darüber nach, was hätte passieren können.

Wenn ich nicht neugierig gewesen wäre. Wenn ich nur die Updates installiert und die Performance gecheckt hätte, ohne mir den Chatbot genauer anzuschauen.

Wenn ein Angreifer zuerst dort gewesen wäre. Die Schwachstelle existierte seit der Installation des Chatbots. Monate, vielleicht Jahre. Jeder hätte sie finden können.

Wenn die Schwachstelle missbraucht worden wäre. Dann hätten technische, organisatorische und möglicherweise rechtliche Folgen geklärt werden müssen. Welche Pflichten und Kosten tatsächlich entstanden wären, lässt sich aus dem Fund allein nicht seriös beziffern.

Der Fund wurde vor einem bekannten Missbrauch behoben.

Die Lehren: Was du aus diesem Fall mitnehmen solltest

1. “Konformität” ist kein Freifahrtschein

Ein Anbieter kann sich als HIPAA-konform, DSGVO-konform oder ISO-zertifiziert bezeichnen. Das bedeutet nicht automatisch, dass seine Software sicher ist. Zertifizierungen prüfen Prozesse und Richtlinien – nicht zwingend den tatsächlichen Code.

Frage deinen Anbieter: Wann wurde der letzte Penetrationstest durchgeführt? Von wem? Können Sie die Ergebnisse teilen?

2. Drittanbieter-Integrationen sind Einfallstore

Jedes Widget, jeder Chatbot, jede Integration, die du auf deiner Website einbindest, ist Code, den du nicht kontrollierst. Dieser Code kann Schwachstellen enthalten. Er kann Daten an Orte senden, von denen du nichts weißt.

Meine Empfehlung: Lass Drittanbieter-Integrationen regelmäßig überprüfen – besonders wenn sie mit sensiblen Daten arbeiten.

3. Routine-Wartung und Security-Review sind verschiedene Aufträge

Updates, Backups und Funktionschecks gehören zur laufenden Website-Betreuung. Eine gezielte Prüfung von Drittanbieter-Code, Authentifizierung und Datenflüssen ist dagegen ein eigener Security-Scope. Im beschriebenen Fall entstand dieser Scope aus einer konkreten Auffälligkeit und wurde entsprechend begrenzt.

Betreiber brauchen deshalb eine aktuelle Übersicht der eingebundenen Dienste und eine klare Entscheidung, welche Integrationen nur betrieben und welche technisch geprüft werden sollen.

4. Frühe Befunde schaffen eine bessere Entscheidungsgrundlage

Der dokumentierte Befund ermöglichte Containment, Behebung und anschließende Verifikation. Einen hypothetisch vermiedenen Schaden oder Return on Investment leite ich daraus nicht ab.

Ein schneller Reality-Check für deine eigenen Integrationen

Wenn du Drittanbieter-Tools auf deiner Website nutzt, kannst du dir selbst ein paar einfache Fragen stellen – ganz ohne tiefes technisches Wissen:

Welche Tools sind eingebunden? Hast du eine aktuelle Liste aller Widgets, Chatbots, Tracking-Tools?
Welche Daten fließen durch sie? Werden Formulare, Chats oder Support-Anfragen erfasst?
Was verspricht der Anbieter? Gibt es belastbare Nachweise (Audit-Bericht, Pen-Test, BAA)?
Wie aktuell ist die Technik? Werden veraltete Frameworks oder alte Bibliotheken genutzt?
Gibt es Monitoring ohne Maskierung? Session-Replay & Error-Tracking sind häufige Risiken.

Wenn du bei zwei oder mehr Fragen unsicher bist, lohnt sich ein kurzer Security-Check. Viele Probleme lassen sich mit kleinen Änderungen entschärfen – bevor daraus ein Vorfall wird.

Was der Fall belegt

Ein Compliance-Claim ersetzt keine technische Verifikation. In diesem Fall lagen sensible Schlüssel im Frontend, weitere Datenflüsse widersprachen der öffentlichen Aussage des Anbieters, und die Behebung musste anschließend im Produktivverhalten geprüft werden. Daraus folgt kein pauschales Urteil über alle Chatbots, sondern ein klarer Prüfgrund für sensible Integrationen.

Nutzt du Drittanbieter-Integrationen auf deiner Website?

Chatbots, Buchungssysteme, Analytics-Tools und Marketing-Widgets erweitern den technischen und datenschutzrelevanten Scope einer Website. Bei sensiblen Daten sollte klar sein, welche Prüfung beauftragt ist und welche nicht.

Ich biete klar begrenzte technische Reviews für Drittanbieter-Integrationen an. Der vereinbarte Ausschnitt wird dokumentiert geprüft; formale Penetrationstests, Rechtsberatung und Zertifizierung bleiben getrennte Leistungen.

Drittanbieter-Integration technisch prüfen lassen

Dieser Artikel beschreibt einen realen, anonymisierten Fall aus meiner Arbeit. Er ersetzt weder einen formalen Penetrationstest noch eine rechtliche Compliance-Bewertung.

Kritische Sicherheitslücke in Healthcare-Chatbot entdeckt