b-Aware
bWallet and bWalletX are non-custodial. If you find a way to take or spend someone's money, read their keys or recovery phrase, or make the wallet sign something its owner did not approve, tell us first. We fix it, we credit you, and we pay for it in BSV.
Report Rewards Scope Safe harbour Known and accepted Advisories Credits
How to report
-
Email support@bwalletx.com with the subject line
b-Aware. Put the report in the mail itself: the edition and version (Settings › About), the steps, what happens, and why it matters. Steps we can run beat a video. - If it lets an attacker move funds or read keys, say so in the subject so it is read first.
- Do not open a public GitHub issue or a public bug report for a security finding. Ordinary bugs go to Bugs (tell b in the app) or github.com/bitcoin-corp/bwallet/issues.
- Never send us a recovery phrase, private key, password or key file. Use a throwaway wallet to demonstrate.
What you can expect from us: an acknowledgement within 2 working days, a severity and a fix plan within 7 days, and a note when the fix ships. Our machine-readable contact is at /.well-known/security.txt; the policy also lives in the repository as SECURITY.md.
What we pay
Rewards are paid in BSV to an address you give us, within 14 days of the fix shipping or 30 days of triage, whichever is first.
| Severity | What it looks like in bWallet | Reward |
|---|---|---|
| Critical | Steal or spend funds, extract keys or the recovery phrase, sign without the owner's approval | 10 BSV |
| High | Bypass an approval or permission, forge a pairing or connection, drain through a dApp endpoint | 3 BSV |
| Medium | Leak private data, defeat the safety filter, deny a user their own wallet | 0.5 BSV |
| Low | Real but contained | Credit |
The rules that bound it
- A pool, not an open tap. The reward pool is 20 BSV per calendar quarter. When it is spent, valid reports still earn credit and are paid from the next quarter's pool, in the order they were triaged. We are a small company and would rather say this than quietly stop paying.
- First valid report wins. Duplicates, issues we already know about and anything listed under Known and accepted earn credit, not money.
- Proof required. A working reproduction against a wallet you control. Scanner output or an AI-written report with no reproduction is closed politely.
- Severity is by impact on users' money and keys, not by CVSS alone. We set it and explain the reasoning in writing; if you disagree, say so and we will look again.
- One reward per root cause, even where it shows up in several places.
Scope
In scope (the code is open at github.com/bitcoin-corp/bwallet):
- Key handling, signing and approvals: the background wallet, the approval sheets and the USB key flow.
- Storage, backup and the remote storage provider.
- The BRC-100 dApp bridge: the injected provider, the content script, the extension side panel and in-page sheet, the mobile dApp browser and its per-origin endpoints, pairing of computers and the CLI.
- Paymail, OpNS names, the Name Store, pots and subscriptions, agent accounts.
- The iOS and Android apps, the Chrome extension, and the web wallet.
Out of scope:
- The marketing sites and this page.
- Rate limiting, missing security headers, best-practice notes with no exploit.
- Self-XSS, clickjacking on pages with nothing to click, anything that needs a rooted or jailbroken device or physical access to an unlocked phone.
- Social engineering of our staff or users.
- Services we do not run: indexers, exchanges, HandCash, the Yours Wallet upstream.
Safe harbour
Research done in good faith under this policy is authorised. We will not pursue, or support, legal action against you for it, and if a third party does, we will say publicly that you acted under this policy. Good faith means: you test against your own wallets and your own funds; you do not access, change or destroy anyone else's data or money; you do not degrade the service for other people; and you give us a reasonable time to fix before you publish. We will not ask you to sign anything to be paid.
Known and accepted
Things we already know about. Reports of these earn credit only.
- DNS rebinding of an app's own origin. In browser runtimes the wallet cannot pre-resolve DNS, so a site could point its own hostname at a private address after we verify it. The fetch is still limited to that site's HTTPS origin with no redirects; the same limitation is documented by the upstream reference wallet (see the 20 October advisory below).
- Connected wallets hold operating balances. A BRC-100 wallet signs what its owner approves; it cannot judge intent. Keep savings in a wallet that is not connected to apps.
Advisories and our responses
Published advisories that touch BRC-100 wallets, the BSV TypeScript stack or our dependencies, with what bWallet does about each. Newest first.
20 October 2026 · SSRF hardening of BRC-100 manifest fetching (bsv-desktop)
What it is. A BRC-100 wallet fetches https://<app>/manifest.json to show an app's
declared permissions in one grouped prompt. In the Electron reference wallet that fetch ran in the privileged
main process on a URL the renderer supplied, which is a server-side request forgery surface: a page could make
the wallet process reach localhost or a private network. The pull request requires HTTPS on the default port
with a manifest.json path, rejects localhost, private, reserved and non-public IP addresses
including DNS results, refuses redirects, caps the body at 1 MiB, restricts the IPC handler to the main frame
and removes the renderer's fallback to an unrestricted fetch.
bWallet's position. bWallet does not have the mechanism the fix addresses. There is no privileged
"fetch this URL" channel between a page and the wallet: the background never fetches a URL a page supplies.
The manifest fetch happens inside the wallet toolbox's permissions manager (we ship wallet-toolbox-client
2.14.5 and @bsv/sdk 2.8.11), which builds the URL from the originator rather than accepting one, goes through
the SDK's public-HTTPS fetch (HTTPS only, no credentials, pinned to that origin, IP literals must be public),
refuses redirects, caps the body at 256 KiB and times out after 10 seconds. The originator itself is not
chosen by the page: the extension rejects any message whose originator does not match the browser's
sender.origin, and the mobile app derives it from the verified origin of the per-site endpoint.
The only host a site can make the wallet contact is therefore its own.
Residual and shared. In browser runtimes the SDK cannot resolve DNS before the request, so a site could
rebind its own hostname to a private address; the reference wallet notes the same gap. Plain HTTP is used only
for an originator of localhost, for local development, as upstream does. We will adopt DNS and IP
checks in our toolbox fork if upstream lands them, and we track the fix.
Action for users: none.
23 September 2026 · Coordinated ts-stack trust-boundary advisory (GHSA-qp3j-h5xf-p2p7)
A broad set of findings across the stack: storage-supplied output scripts not verified against the requested
outputs in createAction, action references not bound to the originator that was authorised, abort
refusals reported as success, negative signature verdicts treated as success, originator spoofing over the
wallet wire transport, and tenant isolation gaps in remote storage.
bWallet's position. bWallet ships @bsv/sdk 2.8.11, wallet-toolbox-client 2.14.5 and @bsv/message-box-client 2.5.4, all past the patched versions. Separately from the stack fixes, the wallet checks every message's originator against the browser-reported sender origin before any wallet call, verifies the OpNS covenant locally before broadcast, and refuses to abort an action the network may already have.
Action for users: be on the current release (bWalletX 5.2.38 or later, or the current store build).
6 July 2026 · createAction output redirection with remote storage (GHSA-36f9-7rg5-cpf8 / CVE-2026-56744)
A malicious or compromised remote storage server could return output scripts different from the ones the caller asked for, redirecting a payment. bWallet ships wallet-toolbox-client 2.14.5, which verifies returned outputs against the authorised request. The remote storage provider is a setting you can change in Settings › Wallet Backup.
Credits
No reports yet. Yours could be the first name here.
Changes to this policy
- 20 October 2026: version 1. Policy, reward table, 20 BSV quarterly pool, safe harbour, first three advisory responses.