Last updated Aug 4, 2026

Bitkey security updates

How Bitkey approaches security research

Bitkey is open-source so researchers can inspect our code, test ideas, and help us make the product more secure. We also use AI-assisted tools in our own security research, code review, and investigations.

Whether a bug report comes from an independent researcher or our internal research, Bitkey engineers verify it. We reproduce the behavior, confirm that it affects the released product, assess its potential impact, and test the fix.

This page provides a record of confirmed bugs after they have been fixed and are safe to disclose. Each update identifies whether the bug was reported externally, found through internal security research, or identified by both.

Report a security bug

Email [email protected] with:

the affected component and version
what you observed
steps to reproduce it safely
your assessment of the potential impact

Do not access customer data, move funds, disrupt production, or test accounts you don’t own.

How we review reports

Review: We examine the report and determine whether the behavior affects the released product.
Verify: We reproduce the bug and identify the conditions required for it to occur.
Assess: We evaluate the potential customer impact and check for related bugs.
Fix: We develop, test, and release a fix.
Disclose: After the risk is evaluated, we publish an update and credit researchers with their permission. We don't currently award bounties but in light of recent events we are reconsidering that and will update this page if we make a change to that policy.

Several reports may identify the same underlying problem, and automated tools may flag code that is unreachable, used only for testing, or working as intended.

We don’t publish details that could increase risk while a bug remains unresolved. If you need to take action, we’ll communicate that through official Bitkey channels.

Stay informed

We update this page when a confirmed security bug has been fixed and is safe to disclose. If you need to take action, we’ll also contact you through official Bitkey channels.

Principles of Reporting

We will report all relevant security-related Bitkey bugs that we believe may be of interest to our customers.

The descriptions and customer impact of each bug are described based on our full assessment of any actions made possible by the findings. Impact is determined by the possible outcomes of those actions, without assuming additional attacker capabilities from outside the scope of the assessment.

We will continuously evolve these principles as needed.

Resolved bugs

Description: We fixed an bug where a beneficiary using a modified app and a separate test-account relationship could shorten the delay period of an inheritance claim. This did not allow an unrelated account to receive funds directly, but it could have reduced the time available for the benefactor to cancel the claim. Block has verified that no inheritance claim has advanced before its intended delay period ended.
Customer impact: None. Block has verified that no inheritance claim has ever advanced faster than its intended delay window. Block has received no reports of shortened inheritance delays.
Required customer action: None
Fix: We now bind the inheritance claim, beneficiary account, and recovery relationship together, requiring that they match before the claim’s waiting period can be changed.
Github: source/2026-08-02-0031

Fixed in [Version or deployment date]

Description: We fixed a bug where a test-account-only endpoint could be used to shorten the review period for another account’s active Delay & Notify window. This on its own does not provide any mechanism for exploitation.
Customer impact: None. There is no path where this exploit results in any negative impact on the customer. We reviewed all Delay & Notify privileged actions ever created in production, including completed and canceled ones. Every one still carries its full policy window of seven days for real customers with no evidence that any delay was ever shortened.
Required customer action: None
Fix: We now verify that the privileged action and authenticated account match before the waiting period can be changed.
Github: source/2026-08-02-0031

Fixed in [Version or deployment date]

Description: We fixed a bug that could cause short-lived mobile app bearer tokens to be recorded in observability tools. Access to these tokens would require privileged access to logging systems. Although an attacker with access to these tokens could use the tokens to impersonate an account, they could not change its security settings without cryptographically authenticating using the account’s registered Bitkey hardware . The tokens, and internal access required to read the tokens did not provide access to any cryptographic keys, including spending keys, so no funds were at risk.
Customer impact: None. We exhaustively analyzed all tokens present in log archives and found that there was no reuse of any of those tokens. Nor have we received any customer reports that would indicate unauthorized access to tokens.
Required customer action: No action required
Fix: We stopped exporting these tokens to telemetry and reduced exposure of sensitive authorization material in monitoring data overall.
Github: source/2026-08-02-0031

Fixed in [Version or deployment date]

Description: We fixed a bug where Recovery Contact and Beneficiary enrollment used standard randomness instead of cryptographically secure randomness. To exploit this bug, an attacker would need to compromise Block’s internal systems and monitor an enrollment flow in real time. The attacker could then potentially guess the secret required to impersonate the intended recipient while an inheritance enrollment was live in-flight.
Customer impact: None. A specific circumstance is required for an attacker to be able to guess the secret. Block confirmed that this circumstance never occurred for any customer.
Required customer action: Update app to version 2026.11.2.
Fix: We updated nonce generation to use a cryptographically secure random source.
Github: app/2026.11.2

Fixed in [Version or deployment date]

Description: We fixed a bug where release automation workflows could have been altered by someone with write access to the repository. In practice, the execution of bitkey-release-automation was limited to protected release refs and there was no evidence found that the automation secret was ever exposed. Bitkey uses github actions to manage release automation, including the creation of release branches, tags and downstream build triggers.
Customer impact: None. We verified that the affected workflows only ran from expected release refs. And no workflows, refs, or release targets were unexpectedly modified.
Required customer action: No action required
Fix: We removed the affected GitHub App integration and changed release automation so privileged Github App credentials are no longer available to workflows loaded from branch- or tag-controlled refs.
Github: source/2026-08-02-0031

Fixed in [Version or deployment date]

Description: We fixed an authentication configuration bug affecting an internal service used to review and apply infrastructure changes. A third-party infrastructure module created broader exceptions to company sign-in than intended; the public integration endpoint could be reached from any IP address, while requests from the integration provider’s network could reach paths beyond that endpoint. Under these conditions, an unauthenticated request could reach the service and potentially expose status and software-version information useful to support further investigation by an attacker. Requests that triggered infrastructure workflows still required a valid cryptographic signature from the authorized integration provider.
Customer impact: None. We found no evidence of exploitation or impact to customer funds.
Required customer action: No action required
Fix: We replaced the module’s broad authentication exceptions with a rule requiring requests to match both the intended integration endpoint and the provider’s published IP ranges. We also added a web application firewall that blocks public access to the status endpoint, independently enforces the integration restrictions, and accounts for encoded URL paths.
Github: source/2026-08-02-0031

Fixed in [Version or deployment date]