// HEISE ONLINE — LINUX & OPEN SOURCE
Sicherheitslücken in ePA-Clients: „Die Implementierungen hatten blinde Flecken“
Sicherheitsforscher sorgten für Fixes kritischer Lücken in ePA-Clients und der Telematikinfrastruktur. Dr. Simon Weber erklärt die Details im Interview.
Mehrere frei verfügbare Softwarekomponenten für die Anbindung an die elektronische Patientenakte wiesen im Frühjahr 2026 Sicherheitslücken in zentralen Schutzmechanismen auf. Betroffen waren drei unabhängig voneinander entwickelte Open-Source-Implementierungen: der ePA3-Service von fbeta, Ovivas epa4all-client sowie epa4all von Med United (service health erx).
Die Fehler betrafen den sogenannten VAU-Kanal – also die Verbindung zur vertrauenswürdigen Ausführungsumgebung (VAU). Dabei handelt es sich um eine zusätzliche kryptografische Schicht, die Gesundheitsdaten zwischen ePA-Client und Aktensystem absichern soll.
Die Schwachstellen reichten von unvollständigen Prüfungen der Serveridentität über Probleme bei kryptografischen Zählern bis hin zu deaktivierten TLS-Zertifikatsprüfungen. Nach Responsible-Disclosure-Meldungen durch die Sicherheitsforscher von Machine Spirits wurden alle Lücken behoben; Hinweise auf eine tatsächliche Ausnutzung liegen nicht vor. In der Praxis dürfte der Kreis potenziell Betroffener zudem sehr klein gewesen sein: fbeta zählte zum Zeitpunkt des Fundes nur einen produktiven DiGA-Kunden mit sehr seltenen ePA-Exporten, Med United verweist auf wenige Supportkunden außerhalb des DiGA-Bereichs, und Oviva schützte die Verbindungsstrecken mit zusätzlichen TLS- und VPN-Tunneln.
Die Gematik weist darauf hin, dass ihre Bibliothek lib-vau / lib-vau-csharp ausschließlich für Testzwecke entwickelt worden sei. Sie sei ausdrücklich als nicht produktionsgeeignet gekennzeichnet gewesen; zudem habe die Dokumentation darauf hingewiesen, dass Zertifikate nicht geprüft werden. Für produktiv eingesetzte Software seien die jeweiligen Hersteller verantwortlich.
Die Sicherheitsforscher teilen diese Einordnung mit Blick auf die unmittelbare technische Verantwortung. Zugleich wirft der Fall die weitergehende Frage auf, welche Rolle sicherheitskritischer Beispielcode in einem komplexen Ökosystem spielt – gerade dann, wenn sich mehrere unabhängige Hersteller an ähnlichen Stellen vertun.
Wie die Sicherheitslücken entdeckt wurden und welche Lehren sich daraus ziehen lassen, erklärt Dr. Simon Weber im Gespräch mit heise online. Weber fand die Lücken gemeinsam mit dem Sicherheitsforscher und Diplom-Informatiker Volker Schönefeld bei Machine Spirits.
Warum haben Sie sich überhaupt mit der VAU und dem Authenticator beschäftigt?
Der Hintergrund ist, dass ich mich schon während meiner Promotion mit Angriffserkennung in Krankenhäusern und der Sicherheit digitaler Gesundheitsversorgung beschäftigt habe. Danach haben wir bei Machine Spirits festgestellt, dass gerade bei Medizinprodukten und Gesundheits-IT zwar hohe regulatorische Anforderungen gelten, aber oft nur wenige Menschen die eingesetzten Protokolle und Bibliotheken wirklich im Detail prüfen können.
Wir schauen uns deshalb auch Open-Source-Komponenten an, die in üblichen Pentests leicht unter dem Radar bleiben. Angefangen hatten wir mit dem Gematik-Authenticator, den ich noch aus dem Krankenhausumfeld kannte. Darüber sind wir auf weitere Referenzimplementierungen der Gematik gestoßen – darunter lib-vau.