.svg){kind=logo}
Von September bis November 2025 hat die secuvera GmbH eine statische Quellcode-Analyse unseres gesamten Monorepos durchgeführt. secuvera ist 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: Alle betroffenen Zugangsdaten wurden rotiert, die zuvor im Code enthaltenen Werte sind damit wertlos. Produktive Zugangsdaten werden heute beim Deployment in die jeweilige Umgebung injiziert statt im Repository zu liegen. Dort verbleiben ausschließlich Zugangsdaten für lokale Test- und Entwicklungsumgebungen, die keinen Zugriff auf produktive Systeme ermöglichen.
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 die Nachrichten an einen breiteren Kontext gingen als notwendig und grundsätzlich auch die umgebende Webseite sie mitlesen konnte. Laut Bericht ging es 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: Wird jemand neu in eine Organisation eingeladen, führt ein Admin-Gerät im Hintergrund eine kryptografische Operation aus, damit die eingeladene Person Zugriff auf die für sie freigegebenen Logins erhält. 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 ausgerollt und getestet und danach in einer offenen Beta, 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.
Für einzelne Operationen, die tatsächlich Hintergrundzugriff benötigen, setzen wir weiterhin bewusst kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly ein, die Zugriffsstufe richtet sich also nach dem Schutzbedarf des Eintrags. 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}
