Relationship-enrollment bug in Bitkey

Block, Inc. (“Block” or “we”) received a report on Saturday, August 1, 2026, from X user @1440000bytes, about a bug in Bitkey’s relationship-enrollment flows which drive recovery contacts and inheritance enrollment. 

At this time, and based on the information we currently have available, we have no evidence that any customer was exploited or that their funds were impacted.  Customers may continue to use Bitkey as normal. Out of an abundance of caution, for the small cohort of customers using the 2nd generation Bitkey and who have added an inheritance beneficiary, we recommend that they download the upcoming mobile app update when it’s published, and then re-enroll their inheritance beneficiaries.

The report identified a real bug, but our current assessment is that an outside actor who would attempt to exploit it would not gain control of the wallet or the ability to move funds. If there were a successful insider attack, the attack would leave specific server logs, but our logs do not contain such activity for the period for which this bug has been active. 

In a specific app flow that runs only for certain customers using the 2nd generation Bitkey (our recently released device with a screen) and having used the relationship-enrollment flows, the Bitkey service could also observe small random values produced by the same source. Exploitation would require extensive access to Bitkey’s service infrastructure and active interference while a customer was enrolling a Recovery Contact or Inheritance beneficiary.

Relationship enrollment protects high-value recovery and inheritance flows, so we are treating the bug with urgency. We are submitting a mobile app patch that moves relationship-enrollment secrets to a cryptographically secure random-number generator. 

What was not affected

Recent unrelated wallet vulnerabilities involving weak randomness have made people understandably worried. In some wallet systems, weak entropy during wallet creation can be catastrophic. If a seed phrase or private key is created with too little randomness, an attacker may be able to reconstruct the key and move funds.

That is not what happened here.

This issue is not about the randomness used to create Bitkey spending keys. The bug we identified does not weaken the app key, the hardware key, or the server key. It also does not let someone derive wallet keys from the blockchain. Finally, it does not create a broad internet-scale attack against Bitkey customers.

The affected value was a one-time secret used during relationship-enrollment setup. It was not a private key, seed phrase, or spending key. The affected value is a short one-time authentication secret used when adding a Recovery Contact or inheritance beneficiary. You can read more detail about our recovery whitepaper here. That secret is intentionally much smaller than a private key because it is used inside SPAKE2, which is built for password-style secrets shared out of band.

The size of the secret is not the core bug. A short SPAKE2 secret is appropriate when the protocol is used correctly and the secret is unpredictable to the relay. The bug is that the app generated this secret with a random source that does not have the security properties required for cryptographic secrets.

Who is potentially in scope

The underlying bug is limited to the Bitkey mobile app, not in the hardware device itself. The app generated relationship-enrollment secrets with a non-cryptographic random-number generator.

The demonstrated practical exploit path is much narrower: It depends on the 2nd generation Bitkey action-proof nonces that are visible to the Bitkey service and generated by the app from the same random source. This limited exploit path was not present before the affected 2nd generation Bitkey flow launched in late April 2026.

We have no evidence of any customers being impacted.  Even in the case of a successful exploit, the attacker does not have enough cryptographic material to move funds in the  multi-sig wallet. Bitkey users should continue to use the wallet normally and keep their app software updated.

Adding a Recovery Contact or inheritance beneficiary

When you add a Recovery Contact or inheritance beneficiary, the Bitkey app needs to make sure it is connecting to the person who received the invitation.

The Bitkey service helps relay messages between the two apps. But the service should not be able to silently replace the intended person with someone else.

To protect that flow, Bitkey uses a standardized protocol called SPAKE2. SPAKE2 is a password-authenticated secure key exchange. In plain terms, it lets two apps prove they know the same short secret without sending that secret to the server.

The invitation contains a short secret that the customer shares out-of-band with their Recovery Contact or beneficiary. If the secret is unpredictable, the Bitkey service can relay messages but cannot impersonate the Recovery Contact or beneficiary.

An overview of the bug

The enrollment secret and privileged-action nonce came from the same non-cryptographic random-number generator. Under narrow conditions, observing enough related outputs could reveal the generator’s internal state and make a later enrollment secret predictable.

The relationship-enrollment secret was generated with kotlin.random.Random. That is a general-purpose random-number generator. It is not designed for cryptographic secrets.

The secret itself is small by design. Bitkey’s enrollment code uses 23 significant bits – about 3 bytes after masking. That does not make it a private key, and it should not be compared to the entropy requirements for wallet key generation. SPAKE2 is specifically designed to work with short secrets, as long as the secret is unpredictable to the party relaying the exchange and the protocol is not turned into a reusable guessing oracle. 

General-purpose randomness can be fine for many software applications, but cryptographic secrets need a stronger property: they must remain unpredictable even if an attacker can observe other outputs from the system. That property was missing here.

In addition, in 2nd generation Bitkey, Bitkey also introduced privileged-action proofs for sensitive operations. Those proofs include a small nonce, which is sent to the Bitkey service. In the affected implementation, that nonce came from the same general-purpose random-number generator used for the relationship-enrollment secret. 

Together, these two uses of a non-cryptographic random-number generator could, under narrow conditions, reveal its internal state and make a later SPAKE2 secret predictable. If a compromised service saw enough related outputs from the same app session or thread, it could reconstruct the generator state and predict the short secret generated later in the enrollment flow.

Key clarifications

To avoid confusion, here is what our assessment says:

• This bug does not mean that Bitkey wallet keys were generated with weak entropy.
• The affected random value was not a private key, seed, or wallet spending key.
• This is not a bug in the 2nd generation Bitkey hardware device or its firmware. The bug is in the mobile app code that generates information used during relationship setup.
• We have not found evidence that any customer was exploited.
• Customers who use the app with the 1st generation Bitkey device do not have the same demonstrated prediction path as those who use it with 2nd generation Bitkey.
• Not every relationship enrollment created by the app by 2nd generation Bitkey customers is affected. The practical path requires the narrow conditions described below.

Outside attackers: why this is not a remote-drain vulnerability

Our current assessment is that this issue does not enable a remote-drain attack that could be conducted without significant access to multiple parts of Bitkey’s production infrastructure.

An ordinary outside attacker does not see or control the relationship-enrollment traffic between the Bitkey app and the Bitkey service. That traffic is protected by TLS, the same internet security layer used across banking, commerce, messaging, and modern apps.

To exploit this issue from the network, an attacker would first need to defeat or bypass TLS for the victim. That is an exceptional condition. Examples could include a compromised device, attacker control over trusted root certificates, or another serious compromise that makes the app trust an attacker-controlled connection.

If an attacker has that level of access, the customer is exposed to many risks beyond this specific issue. The attacker may be able to interfere with other apps, accounts, and traffic on the device.

Even in that scenario, this bug alone would not give the attacker everything needed to spend from a Bitkey wallet. At most, it could help the attacker interfere with relationship setup and obtain recovery-related material. Bitkey still requires 2 of 3 wallet keys to spend.

A network attacker does not get the Bitkey hardware key. They also do not get the Bitkey server signing path from this issue. That path is protected separately, including by app authentication and server-side authorization controls. 

This is why we do not assess this as a remote-drain vulnerability.

Server-side control scenario

The highest-impact scenario requires an attacker to control part of Bitkey’s service infrastructure and actively interfere during enrollment. Access obtained later would not be enough

An attacker would need the ability to actively manipulate the traffic between the Bitkey mobile app and the service that manages enrollment of Recovery Contacts and Inheritance setup on Bitkey backend servers. This means that an attacker who later gains access to the traffic and the encrypted backups used for Inheritance cannot gain any information about the wallet's mobile key (this property is typically referred to as perfect forward secrecy, and was intentionally designed into this protocol).

The impact depends on whether the customer is setting up inheritance or recovery contacts.

Inheritance

Under the narrow server-side scenario, an attacker could potentially impersonate the intended beneficiary and gain access to encrypted inheritance material, but this issue alone would not let them move funds. When a customer adds an inheritance beneficiary, the Bitkey app creates encrypted inheritance material for that beneficiary. That material includes the customer’s app private spending key, encrypted to the beneficiary’s Delegate Decryption Key.

If an attacker with service-side control substituted its own DDK during beneficiary setup, it could later decrypt the inheritance material for that beneficiary.

That still would not expose the hardware key. But in Bitkey’s 2-of-3 model, an attacker with the app spending key would need one more signing key to spend. The relevant second key would be the server key, exercised through the Bitkey service signing path.

That server signing path is protected by separate authorization controls. This issue does not extract the server key or expose the hardware key. A complete theft through this path would require both successful DDK substitution and misuse of the server signing path.

Impact on Recovery Contacts

The same enrollment-authentication bug applies when adding a Recovery Contact.

The direct impact is smaller. In Social Recovery, the full encrypted backup remains in the customer’s cloud storage, such as iCloud or Google Drive. The Bitkey service may receive a DDK-wrapped key, but it never receives the full encrypted backup.

That means DDK substitution alone is not a complete theft path for ordinary Social Recovery. A separate compromise of the customer’s cloud backup, device, or another data path would be needed to recover the app spending key through that route.

How multisig limits the impact

Bitkey is designed so one compromised component is not enough to move funds.

A Bitkey wallet uses a 2-of-3 signing model:

• the app key, held by the mobile app;
• the hardware key, held by the Bitkey hardware device; and
• the server key, exercised through the Bitkey service signing path.

Any spend requires 2 of those 3 keys.

This issue does not expose the hardware key. It does not extract the server key. It does not change the 2-of-3 wallet policy.

In the highest-impact inheritance scenario, a successful attack could expose the app key to a compromised service. The attacker would still need access to the server signing path to move funds without the hardware device. That path is independently protected and monitored.

This is defense in depth. The relationship-enrollment bug is real and we are fixing it urgently. But the wallet still has additional layers between this bug and a completed theft.

What we are doing next

We are submitting the mobile patch to both app stores today. We expect that update will be live in the app stores early next week. We will also continue to investigate the details of the report and will share information with the community through our standard channels. 

Bitkey will never ask you to move bitcoin to an address provided by Support or share private keys, Recovery Contact codes, your Emergency Exit Kit, or other secret information. Confirm security instructions through the Bitkey app or official Help Center.

We will continue investigating and share any additional customer guidance through official Bitkey channels.

How SPAKE2 provides forward secrecy

The SPAKE2 protocol that our inheritance-enrollment procedure uses does not derive its encryption key from the shared SPAKE2 code on its own. Each participant also generates a private, ephemeral session key on top of the SPAKE2 key exchange. This provides the critical security property known as perfect forward secrecy. Even if Block has logged the entire inheritance-enrollment network traffic, it is impossible for Block to decrypt the inheritance payload and key material.

This statement is provided by Block, Inc. for informational purposes only. While Block believes the information contained herein is accurate based on the facts currently available, it does not guarantee its completeness or accuracy. Block reserves the right to revise, amend, supplement, or otherwise update this statement as additional facts or information becomes available.