.svg){kind=logo}
From September to November 2025, secuvera GmbH carried out a static source code analysis of heylogin. secuvera is a BSI-certified IT security service provider and an approved testing body for IT security.
The analysis identified three vulnerabilities of medium severity and two informational findings. No critical or high severity vulnerabilities were found. We remediated all three vulnerabilities and had them retested in September 2026.
The result of the retest: None of the vulnerabilities were still present in the reviewed source code. secuvera attests a very high security level to the source code, the highest rating in the assessment scheme used.
We are publishing the full report and describe below what each vulnerability meant and what we changed.
So that you can put the result in context, here is the scope in plain terms:
In the mapping against the OWASP Top 10, all ten categories were rated "Pass".
What was found: Credentials for internal operational and development tools were stored directly in configuration files instead of being supplied through environment variables. An attacker needs access to the source code to see them at all, which secuvera took into account in the rating (metric "Privileges Required: High"). No keys that could decrypt customer data were among them, and architecturally there cannot be any: because of our zero-knowledge architecture, those keys exist only on your devices and never on our servers.
What we changed: All affected credentials were rotated, which makes the values previously contained in the code worthless. Production credentials are now injected into the respective environment at deployment time instead of being held in the repository. What remains there are credentials for local test and development environments only, which provide no access to production systems.
What was found: The heylogin browser extension communicates with an overlay that we insert into the website you are visiting, for example to fill in credentials, using the browser function postMessage(). A wildcard was used instead of a specific target origin, so the messages reached a broader context than necessary and the surrounding website could in principle read them. According to the report, what was at stake was fingerprinting of the extension along with client parameters and application state, not the exposure of our server interfaces.
What we changed: The wildcard was replaced with a specific target origin, so messages now only reach the intended context. A lint rule automatically prevents the wildcard from being used in future changes.
What was found: The iOS app stored sensitive data in the iOS Keychain with the accessibility level kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly. At that level the data stays available in device memory from the first unlock until the next restart, even if the device is locked again in the meantime. Exploiting this requires physical access to the device plus a jailbreak, which is why secuvera rates the attack complexity as high.
What we changed: This was the most demanding of the three changes and the reason why a longer period passed between the report and the retest.
heylogin has cryptographic operations that necessarily run on the devices of admins, because we as the operator do not hold the keys required for them and decryption happens exclusively on the client side. One example: when someone is newly invited to an organisation, an admin device performs a cryptographic operation in the background so that the invited person gains access to the logins shared with them. Operations like these could previously start even while the device was locked.
Once the affected Keychain entries were moved to kSecAttrAccessibleWhenUnlockedThisDeviceOnly, that was no longer possible. We therefore had to substantially rebuild the application first, so that these operations are reliably carried out as soon as an admin device is unlocked again. We then rolled the change out in an internal beta and tested it, followed by an open beta to verify that everything still works as it did before. We deliberately did not shorten this step, because core heylogin functionality depends on these background operations.
For individual operations that genuinely require background access, we deliberately continue to use kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, so the accessibility level matches the protection needs of each entry. The operations now take longer to execute. We consider this acceptable because the keys are accessible only while the device is actually unlocked.
In addition to the vulnerabilities, secuvera recorded two informational findings. According to the report these pose no direct risk and do not factor into the security level rating. They were not part of the retest. We are addressing them openly nonetheless:
We are publishing the documents so that you can form your own view:
The report contains the full description of all findings including the CVSS assessment. Component and path details have been redacted in the public version.
.png){kind=icon}
