Relationship-enrollment bug in Bitkey
bitkey-relationship-enrollment-report
https://bitkey.world/blog/relationship-enrollment-bug-in-bitkey
Latest reviewed change
source content difference between and
The page title changed to include a trailing pipe and product name, reading 'Relationship-enrollment bug in Bitkey | Bitkey'.
CountryUnited States
Cart
Your cart is empty
+Relationship-enrollment bug in Bitkey | Bitkey
First lines only. The complete diff is in the timeline below.
- Organisation
- Block
- Evidence role
- Vendor response
- Published
- 2026-08-03
- Source changes
- 8
- Detected differences
- 46
- Unreviewed
- 0
- Copies held
- 47
Block's full vendor report on the Bitkey relationship-enrollment bug reported by 1440000bytes: enrollment secrets and 2nd-generation action-proof nonces came from kotlin.random.Random, a non-cryptographic generator, so a compromised service observing enough related outputs could predict a later SPAKE2 enrollment secret. The report states no evidence of customer impact, scopes the practical path to 2nd-generation devices with inheritance or recovery enrollment, and says a mobile-app patch moving the secrets to a cryptographically secure RNG was submitted to the app stores the same day. Vendor statement about its own product; the bug is distinct from the COLDCARD RNG flaw, and the patch had not shipped or been independently reviewed at capture.
Every check is recorded, including checks that found no text change. A detected edit is therefore bounded between two checks. The publisher's exact save time is not observable from this record. Last checked .
Also held inside a captured conversation
This post is held twice: here, with this project's own note on why it matters, and again as part of the conversation captured at , which is polled for changes. Both copies are the same post; neither is a separate event.
Public privacy boundary
Snapshot and diff bodies for this chain monitor are held in the local evidence archive but withheld from the public site because they can contain the addresses of people who published nothing themselves. Capture times and reviewed change summaries remain available below.
Held captures
-
The page title changed to include a trailing pipe and product name, reading 'Relationship-enrollment bug in Bitkey | Bitkey'.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty +Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
Block's report now displays the title line "Relationship-enrollment bug in Bitkey | Bitkey" after the page header, where the previous capture showed no title.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty +Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The rendered report title now reads 'Relationship-enrollment bug in Bitkey | Bitkey'.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty +Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The page title line 'Relationship-enrollment bug in Bitkey | Bitkey' reappeared after being removed in the preceding capture.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty +Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The source removed the 'Relationship-enrollment bug in Bitkey | Bitkey' title line that the preceding capture had added.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty -Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The page title or heading changed to include the source's own title, 'Relationship-enrollment bug in Bitkey | Bitkey', replacing the previous wording.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty +Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The page title or header now reads 'Relationship-enrollment bug in Bitkey | Bitkey', which was not present in the previous extracted text.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty +Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
The page title was removed or changed by the publisher.
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 1 lines
CountryUnited States Cart Your cart is empty -Relationship-enrollment bug in Bitkey | BitkeyExtracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
-
Recovered from the Internet Archive rather than captured by this project. The row records that third-party provenance separately from captures made by this project.
What changed from the previous capture 0 lines
Extracted text as captured
Bitkey on sale — 15% off Product Resources Learning Hub Self-custody wallets2 chapters How Bitkey Works8 chapters Bitkey Security4 chapters Bitkey Privacy4 chapters **** BlogAll Bitkey related news, development, & updatesLearnOur learning hub guides you through all the Bitkey basicsSupportGetting started, orders, & warranty info **** CheckoutBuy Now Buy Now 08.02.26News 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. Customer ProfileImpacted 1st generation Bitkey (no screen) No 2nd generation Bitkey (w/screen) without inheritance or recovery No 2nd generation Bitkey (w/screen) with inheritance or recovery setup on gen 1 before upgrading No 2nd generation Bitkey (w/screen) customers who have added a recovery contact Technically applicable(no practical risk) 2nd generation Bitkey (w/screen) customers who added an inheritance beneficiary The following conditions are required, which we consider to be highly improbable: (1) attacker has extensive access to hardened Block infrastructure and (2) active interjection into communication channels between app and server during the moment of beneficiary enrollmentExcerpt only. The complete copy is held offline and backs quotations on this site. The original publication remains the canonical public source.
38 presentation-noise differences. Sidebar, ticker and other page chrome churn that our review classified as not being changes to what the source says.
- +0 -1 The trailing page-title line Relationship-enrollment bug in Bitkey | Bitkey toggled off again; the report body was unchanged.
- +1 -0 The trailing page-title line Relationship-enrollment bug in Bitkey | Bitkey toggled on again at the end of the extracted text; the report body was unchanged.
- +0 -1 The trailing page-title line 'Relationship-enrollment bug in Bitkey | Bitkey' toggled off at the end of the extracted text; the report body was unchanged.
- +1 -0 The trailing page-title line 'Relationship-enrollment bug in Bitkey | Bitkey' toggled on again at the end of the extracted text; the report body was unchanged.
- +0 -1 The trailing page-title line Relationship-enrollment bug in Bitkey | Bitkey toggled off again at the end of the extracted text; the report body was unchanged.
- +1 -0 The trailing page-title line 'Relationship-enrollment bug in Bitkey | Bitkey' toggled on again at the end of the extracted text; the report body was unchanged.
- +0 -1 The trailing page-title line 'Relationship-enrollment bug in Bitkey | Bitkey' toggled off again at the end of the extracted text; the report body was unchanged.
- +1 -0 The trailing page-title line 'Relationship-enrollment bug in Bitkey | Bitkey' toggled on again at the end of the extracted text; the report body was unchanged.
- +0 -1 The trailing page-title line 'Relationship-enrollment bug in Bitkey | Bitkey' toggled off again at the end of the extracted text; the report body was unchanged.
- +1 -0 The trailing page-title line 'Relationship-enrollment bug in Bitkey | Bitkey' toggled on again at the end of the extracted text; the report body was unchanged.
- +0 -1 The captured text no longer includes a trailing copy of the HTML title tag; the article heading and body were unchanged.
- +0 -1 The page title tag was no longer extracted at the end of the captured text; the report body was unchanged.
- +1 -0 Only the page title tag was newly extracted at the end of the captured text; the report body was unchanged.
- +0 -1 Only the page title suffix '| Bitkey' was removed; the report text was unchanged.
- +1 -0 The trailing 'Relationship-enrollment bug in Bitkey | Bitkey' page-title line toggled on again after the footer, and the article body was unchanged.
- +0 -1 The trailing 'Relationship-enrollment bug in Bitkey | Bitkey' page-title line toggled off again after the footer, and the article body was unchanged.
- +0 -1 The trailing 'Relationship-enrollment bug in Bitkey | Bitkey' page-title line toggled off again after the footer, and the article body was unchanged.
- +1 -0 The trailing page-title line with the site-name suffix reappeared in the extracted text after the footer, continuing the earlier capture-noise pattern; the article body was unchanged.
- +0 -1 The trailing page-title line with the site-name suffix disappeared from the extracted text again, repeating the earlier capture-noise pattern; the article body was unchanged.
- +1 -0 The trailing page-title line with the site-name suffix reappeared in the extracted text; the article body was unchanged.
- +0 -1 Only the trailing page-title line with the site-name suffix disappeared from the extracted text; the article body was unchanged.
- +0 -1 The trailing page-title line Relationship-enrollment bug in Bitkey | Bitkey toggled off again after the footer, mirroring the preceding capture's toggle-on; the article body was unchanged.
- +1 -0 The trailing page-title line Relationship-enrollment bug in Bitkey | Bitkey toggled on again after the footer, and the article body was unchanged.
- +0 -1 The trailing 'Relationship-enrollment bug in Bitkey | Bitkey' title line toggled off again after the footer; the article body was unchanged.
- +1 -0 The trailing 'Relationship-enrollment bug in Bitkey | Bitkey' title line toggled on again after the footer; the article body was unchanged.
- +0 -1 Only the trailing page-title line with the site-name suffix disappeared from the extracted text; the article body was unchanged.
- +0 -1 The page title or header line that appeared in the preceding capture is absent again; no report body text changed, so this is extraction variance.
- +1 -0 The page title gained a site-name suffix again; no report body text changed.
- +0 -1 The page title lost its site-name suffix; no report body text changed.
- +1 -0 The page title gained a site-name suffix; no report body text changed.
- +0 -1 Rendering artifact: the stray page title line added in the previous capture disappeared again; the article body is unchanged.
- +1 -0 Rendering artifact: the page title line "Relationship-enrollment bug in Bitkey | Bitkey" appeared at the end of the extracted text after the cart chrome; the article body is unchanged.
- +0 -1 The transient document-title line was no longer included by the extractor. No vendor-report content changed.
- +1 -0 The extractor temporarily included the document title. No vendor-report content changed.
- +0 -1 The page-title chrome line ('Relationship-enrollment bug in Bitkey | Bitkey') disappeared from the extracted text again. The vendor report body was unchanged.
- +1 -0 The page-title chrome line ('Relationship-enrollment bug in Bitkey | Bitkey') reappeared in the extracted text. The vendor report body was unchanged.
- +0 -1 The page-title chrome line ('Relationship-enrollment bug in Bitkey | Bitkey') that had newly appeared after the cart footer in the previous capture disappeared again. The report body was unchanged.
- +1 -0 Only the page title chrome ('Relationship-enrollment bug in Bitkey | Bitkey') newly appeared appended at the end of the extracted text after the cart footer. The report body was unchanged.
How to check this yourself
The excerpts and plain unified diffs above show the text this project held and how it changed. To verify a quotation, compare it against the page itself or against the Internet Archive's copies, which are independent of this project.
Complete captures are held offline rather than mirrored here, so this page shows diffs and excerpts. If a quotation is ever disputed, the full copy can be produced. Ask.
How to check this yourself
Compare the screenshot or a quotation against the original while it is available.