Kritische Sicherheitslücke in Healthcare-Chatbot entdeckt

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 – das ist das US-amerikanische Gesetz zum Schutz von Gesundheitsinformationen. Die Compliance-Anforderungen sind hoch. Die Strafen bei Verstößen können existenzbedrohend sein. Mein Kunde hatte den Anbieter gewählt, weil er diese Compliance versprach.

Ich beschloss, mir den Code genauer anzuschauen. Nicht weil ich etwas Bestimmtes vermutete. Einfach aus Gewohnheit. Als jemand, der seit Jahren Websites wartet, entwickelt man einen Instinkt dafür, Drittanbieter-Integrationen zu hinterfragen.

Was ich in den nächsten Stunden fand, ließ mir das Blut in den Adern gefrieren.

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:

1. 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.

2. Auf die Backend-API zugreifen – Die API hatte eine fatale Fehlkonfiguration: Sie akzeptierte Anfragen von jeder Quelle (CORS-Wildcard). Normalerweise sollte eine API nur Anfragen von autorisierten Domains akzeptieren.

3. 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.

Ich starrte auf meinen Bildschirm. In meinen Händen hielt ich die Schlüssel zum Dialogflow-Agenten des Chatbots meines Kunden.

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.

Lass das einen Moment sacken.

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

Das war keine theoretische Schwachstelle. Das war eine Patientensicherheits-Notlage. Jeder Internetnutzer mit einem Browser und grundlegenden Entwickler-Tools hätte das ausnutzen können.

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 ich in solchen Fällen standardmäßig prüfe

Wenn Drittanbieter-Integrationen mit sensiblen Daten arbeiten, gehe ich immer die gleichen Bereiche durch. Nicht um „Hacking zu spielen“, sondern um die realen Risiken zu verstehen:

• 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 Konsequenzen real geworden wären. HIPAA-Verstöße können empfindliche Strafen nach sich ziehen, je nach Schwere bis in den siebenstelligen Bereich. Dazu der Reputationsschaden bei Patienten, die dem Unternehmen ihre sensiblen Gesundheitsdaten anvertraut hatten.

Mein Kunde hatte Glück. Diesmal.

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 ist mehr als Updates klicken

Hätte ich nur die WordPress-Updates installiert und die Backups gecheckt, hätte ich diese Schwachstelle nie gefunden. Echte Wartung bedeutet, genauer hinzuschauen. Fragen zu stellen. Neugierig zu sein.

Die unbequeme Wahrheit: Die meisten Website-Betreiber wissen nicht, was ihr Code tut. Sie vertrauen darauf, dass alles funktioniert. Bis es das nicht mehr tut.

4. Die teuersten Probleme sind die, die niemand bemerkt

Mein Kunde zahlte für professionelle Wartung. Diese Investition hat ihm möglicherweise HIPAA-Strafen, Anwaltskosten und Reputationsschaden in Höhe von Hunderttausenden erspart.

Der ROI von Sicherheit: Du siehst ihn nicht, bis etwas passiert. Und dann ist es zu spät.

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:

1. Welche Tools sind eingebunden? Hast du eine aktuelle Liste aller Widgets, Chatbots, Tracking-Tools?
2. Welche Daten fließen durch sie? Werden Formulare, Chats oder Support-Anfragen erfasst?
3. Was verspricht der Anbieter? Gibt es belastbare Nachweise (Audit-Bericht, Pen-Test, BAA)?
4. Wie aktuell ist die Technik? Werden veraltete Frameworks oder alte Bibliotheken genutzt?
5. 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.

Ein letzter Gedanke

Als ich diese Schwachstelle fand, war mein erster Impuls: Das kann nicht sein. Ein Anbieter, der sich auf Healthcare spezialisiert, der mit HIPAA-Compliance wirbt – der kann doch keine Zugangsdaten im Frontend-Code ausliefern.

Aber er tat es. Und er ist wahrscheinlich nicht der Einzige.

Wie viele “sichere” Chatbots, “konforme” Widgets und “geprüfte” Integrationen laufen gerade auf Websites, warten darauf, dass jemand genauer hinschaut?

Ich weiß es nicht. Aber ich weiß, dass ich bei meinen Kunden weiter hinschauen werde.

---

Nutzt du Drittanbieter-Integrationen auf deiner Website?

Chatbots, Buchungssysteme, Analytics-Tools, Marketing-Widgets – jede Integration ist potenziell ein Sicherheitsrisiko. Besonders wenn sensible Daten im Spiel sind.

Ich biete Sicherheitsüberprüfungen für Drittanbieter-Integrationen an. Keine Panik-Mache, keine überflüssigen Tools – nur eine nüchterne Analyse, was der Code auf deiner Website wirklich tut.

Lass uns über deine Website sprechen →

---

Dieser Artikel beschreibt einen realen Fall aus meiner Arbeit. Alle identifizierenden Details wurden anonymisiert. Die technischen Fakten sind akkurat. Der betroffene Kunde hat der Veröffentlichung in anonymisierter Form zugestimmt.