Security Vulnerability in Hub Emergency Access: Update Required

We have released Cryptomator Hub 2.1.3, which fixes a vulnerability in the Emergency Access feature. Only vaults with Emergency Access set up are affected. All other vaults are not affected.

We have informed all affected customers by email about the update and the steps required before and after it. In this post, we explain what the problem was, what caused it, and how the update fixes it.

Which vaults are affected?

Only vaults in Cryptomator Hub with Emergency Access set up. Vaults without Emergency Access and local vaults are not affected.

Are my vaults safe?

An attack is only possible from within the organization: The attacker would need to be a council member in Emergency Access themselves, and other council members would need to approve a recovery process started by them. Outsiders cannot exploit this vulnerability.

What was the problem?

With Emergency Access, a vault’s recovery key is split into key shares and distributed among the members of a council. Only when enough council members approve a recovery process can the recovery key be restored.

A council member could have started a recovery process for one vault and slipped in key shares of a different vault. Council members approving this process would have unknowingly helped to recover the other vault’s recovery key, without the required number of approvals for that vault.

What was the cause?

Key shares were not cryptographically bound to the vault they belong to or to the recovery process they are used in. Once submitted to a recovery process, a key share of one vault could not be told apart from a key share of another vault. Council members approving the process therefore had no way to detect the manipulation.

What does the update change?

Every key share is now bound to its vault, its recipient, and its recovery process. Key shares that don’t match their context can no longer be decrypted.
Recovery processes with manipulated key shares are rejected.
Council members approving a recovery process can now detect if it has been tampered with.

Since existing key shares cannot be bound retroactively, the update deletes all existing key shares and any ongoing recovery processes. Vault owners therefore need to set up Emergency Access again after the update.

Has this been exploited?

At this time, we have no evidence of active exploitation of this vulnerability.

Security Advisory

All technical details will be included in the security advisory, which will be published in two weeks: GHSA-m34v-6wr7-hxpp

How can I get help?

If you have any further questions or need assistance during the update, don’t hesitate to contact us at [email protected].