.svg){kind=logo}
Von September bis November 2025 hat die secuvera GmbH eine statische Quellcode-Analyse unseres gesamten Monorepos durchgeführt. secuvera ist ein vom BSI zertifizierter IT-Sicherheitsdienstleister und anerkannte Prüfstelle für IT-Sicherheit.
Die Prüfung ergab drei Schwachstellen mittlerer Schwere und zwei Hinweise ohne direktes Risiko. Kritische oder hohe Schwachstellen wurden nicht gefunden. Wir haben alle drei Schwachstellen behoben und im September 2026 nachtesten lassen.
Das Ergebnis des Nachtests: Keine der Schwachstellen ist im geprüften Quellcode noch vorhanden. secuvera attestiert dem Quellcode ein sehr hohes Sicherheitsniveau, die höchste Stufe im verwendeten Bewertungsschema.
Wir veröffentlichen den vollständigen Bericht und beschreiben im Folgenden jede einzelne Schwachstelle, was sie bedeutet hat und was wir geändert haben.
Damit Sie das Ergebnis richtig einordnen können, hier der Prüfumfang im Klartext:
Im Mapping auf die OWASP Top 10 wurden alle zehn Kategorien mit "Pass" bewertet.
Was gefunden wurde: Zugangsdaten für interne Betriebs- und Entwicklungswerkzeuge waren direkt in Konfigurationsdateien hinterlegt statt über Umgebungsvariablen bereitgestellt zu werden. Ein Angreifer benötigt Zugriff auf den Quellcode, um sie überhaupt zu sehen, was secuvera in der Bewertung berücksichtigt hat (Metrik "Privileges Required: High"). Schlüssel, mit denen sich Kundendaten entschlüsseln ließen, waren nicht darunter und können es architektonisch auch nicht sein: Durch unsere Zero-Knowledge-Architektur liegen diese Schlüssel ausschließlich auf Ihren Geräten und nie auf unseren Servern.
Was wir geändert haben: Wir haben die betroffenen Zugangsdaten aus dem Quellcode entfernt und rotiert, die zuvor enthaltenen Werte sind damit wertlos. Zugangsdaten werden heute nicht mehr im Code hinterlegt, sondern beim Deployment in die jeweilige Umgebung injiziert. Im Repository verbleiben ausschließlich Zugangsdaten für lokale Test- und Entwicklungsumgebungen.
Was gefunden wurde: Die heylogin Browser-Erweiterung kommuniziert über die Browser-Funktion postMessage() mit einem Overlay, das wir in die besuchte Webseite einfügen, etwa um Zugangsdaten auszufüllen. Dabei wurde ein Platzhalter statt einer konkreten Zielangabe verwendet, sodass der Browser nicht einschränkte, welche Herkunft der empfangende Kontext haben darf. Laut Bericht ging es dabei um Fingerprinting der Erweiterung sowie um Client-Parameter und Anwendungszustand, nicht um die Freigabe unserer Server-Schnittstellen.
Was wir geändert haben: Der Platzhalter wurde durch eine konkrete Zielangabe ersetzt, Nachrichten gehen damit nur noch an den dafür vorgesehenen Kontext. Eine Lint-Regel verhindert den Einsatz des Platzhalters bei künftigen Änderungen automatisch.
Was gefunden wurde: Die iOS-App speicherte sensible Daten in der iOS-Keychain mit der Zugriffsstufe kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly. Dabei bleiben die Daten nach der ersten Entsperrung bis zum nächsten Neustart im Gerätespeicher zugänglich, auch wenn das Gerät zwischenzeitlich wieder gesperrt wird. Ein Angriff setzt physischen Zugriff auf das Gerät und zusätzlich einen Jailbreak voraus, weshalb secuvera die Angriffskomplexität als hoch bewertet.
Was wir geändert haben: Diese Änderung war die aufwendigste der drei und der Grund dafür, dass zwischen Bericht und Nachtest längere Zeit vergangen ist.
Bei heylogin gibt es kryptografische Operationen, die zwingend auf den Endgeräten von Admins ausgeführt werden müssen, weil wir als Betreiber die dafür nötigen Schlüssel nicht besitzen und ausschließlich auf der Clientseite entschlüsselt wird. Ein Beispiel ist die automatisierte Provisionierung über Entra ID: Sie erfordert kryptografische Operationen, die auf einem Admin-Gerät im Hintergrund ausgeführt werden. Solche Operationen konnten bisher auch bei gesperrtem Gerät starten.
Mit der Umstellung der betroffenen Keychain-Einträge auf kSecAttrAccessibleWhenUnlockedThisDeviceOnly war das nicht mehr möglich. Wir mussten die Anwendung deshalb zunächst grundlegend umbauen, damit diese Operationen zuverlässig nachgeholt werden, sobald ein Admin-Gerät wieder entsperrt ist. Anschließend haben wir die Änderung in einer internen Beta getestet und danach schrittweise ausgerollt, um zu prüfen, ob alle Abläufe weiterhin so funktionieren wie zuvor. Diesen Schritt haben wir bewusst nicht abgekürzt, weil zentrale Funktionen von heylogin von diesen Hintergrundoperationen abhängen. Die Operationen benötigen dadurch mehr Zeit bis zur Ausführung. Wir halten das für vertretbar, weil die Schlüssel nur noch zugänglich sind, solange das Gerät tatsächlich entsperrt ist.
Neben den Schwachstellen hat secuvera zwei informative Hinweise vergeben. Diese stellen laut Bericht kein direktes Risiko dar und fließen nicht in die Bewertung des Sicherheitsniveaus ein. Sie waren nicht Teil des Nachtests. Wir ordnen sie trotzdem offen ein:
Wir veröffentlichen die Dokumente, damit Sie sich selbst ein Bild machen können:
Der Bericht enthält die vollständige Beschreibung aller Befunde inklusive Bewertung nach CVSS. Komponenten- und Pfadangaben sind in der öffentlichen Fassung anonymisiert.
.png){kind=icon}
