← Terug naar blog 4 mei 2026 Proton Pass: Second-Password Bypass Through Emergency Access Blog I've been using the Proton suite for a couple of years, and my family is on it too. New features, fresh takes on familiar tools, a clear privacy-first stance: Proton has a lot going for it. Some choices are debatable (the Bitcoin wallet, for one), but overall we like the platform. For context: Proton Pass lets you set a second password specifically on the Pass vault, separate from your main account password. It's an extra layer on top of everything else, designed so that even if someone gets into your Proton account, they still can't open your password vault without that second password. It's the whole point of the feature. About a month ago, a family member forgot that second password. The timing was bad: it happened right before the weekend. He had taken security seriously and used unique generated passwords for every account, so losing access to Pass meant losing access to almost everything else. Banking, subscriptions, daily logins, all out of reach. We emailed Proton support. Resetting a Pass second password is a standard procedure: you verify your identity, and they help you back in. But support didn't respond before the weekend, and after a day or two he came to me. He needed a way in. While we were sorting things out, his main account password had been reset, and at some point Multi-Factor Authentication got disabled. I'm not certain whether the MFA removal happened automatically as part of the reset or somewhere else in the flow. Either way, the account was now behind a single password, and the Pass vault was supposedly still locked behind its own second password. That's when I noticed Emergency Access, a relatively new feature. The waiting time field showed "None", meaning I could add myself as an emergency contact and get in immediately. So I did. I linked my own account, logged in through Emergency Access, and opened Proton Pass. Full access. The second password, the entire reason that layer exists, was never requested. The vault was wide open. What is this feature? The idea behind it is solid. You nominate another Proton user as a trusted contact, and if something happens to you (you pass away, lose access to your account or whatever the case) they can request access and eventually get into your full account. It saves your family from the nightmare of being potentially locked out of your financial, healthcare, and personal records at the worst possible moment. Genuinely a great feature. But also a security risk. How this vulnerability applies Plenty of people don't set up multi-factor authentication. It's an extra hassle, they don't fully understand it, or they just can't be bothered. This is especially common with older users, who'd rather stick to "a password they can remember", or with someone who forgot to re-enable MFA after a password reset. The moment that password leaks or they fall for a phishing attempt, an attacker is in. "Okay, but I've got a second password on my Proton Pass. No way they'd be able to pivot into all my accounts, credit cards, recovery keys, identities, email aliases, right?" The vulnerability Turns out there's a pretty easy way to bypass the whole second-password system, without having enough time to confirm it. As the attacker, we've got access to an account we'll call "Target", with the alias being [email protected] : With access to the account, when we navigate to pass.proton.me , we're hit with the extra password lockout: No way we can access their whole Proton Pass vault, right? Right? Setting up the recovery All we need to do is spin up a fresh Proton account. Verification is minimal by design, since Proton's whole pitch is that you shouldn't have to hand over personal data to use it. That tradeoff is a separate discussion, so let's stick to the security angle here. So: the account's been taken over. The victim has no idea their password leaked, or that they got phished. From here, we just head over to: https://account.proton.me/u/0/mail/recovery From there we navigate to "Add emergency contact" and drop in our freshly created attacker account. In this case we'll call it [email protected] : The important part here is setting the Wait time for access to None . This is where the weakness of the implementation starts to show. With the wait time set to none , we get instant access to every other platform tied to the account. No window for the user to change their password, kill active sessions, or double-check that the emergency contact is actually someone they trust. Although it can be hard to think of a solution for this, the instantaneous access option doesn't help. We do get an email that the emergency contact is added, but in this scenario it would be too late: Hiding the emergency access notifications I was thinking that an email notification would be enough to alert the user to the account access request. But with access to the email account, we could add a rule t...