Trust Wallet Core
By Trust Wallet Bug bounty on Sorona trustwallet.com
- Top reward
- $10,000
- Top severity paid
- Critical
- Assets in scope
- 9
- Public CVEs
- 3
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays up to $10,000
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical |
|
$10,000 from $5,000 |
| High |
|
$5,000 from $1,500 |
| Medium |
|
$1,500 from $600 |
| Low |
|
$600 from $200 |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
9 assets you may test, 7 excluded.
Web 1
- https://trustwallet.com
Products and areas 8
- Binance lists the library by literal repository URL as a first-group bounty-eligible target, and its Trust Wallet section names four things in scope: github.com/trustwallet/wallet-core, the Android app, the iOS app and the Chrome extension. The hosted web properties are carved out, so the open-source library is the paying surface here
- Key material handling: mnemonic generation and validation, BIP-39 seed derivation, HD derivation across paths and curves, and how private keys are held and cleared in memory
- Per-chain address derivation, encoding and validation for the hundred-plus supported blockchains, including the checksum and format checks applied to an address a user pastes in
- Per-chain transaction construction, serialisation and signing, together with the decoding of chain data and transaction payloads that feeds it
- The cryptographic primitives underneath all of that: the signature schemes, hashes and encodings the core implements or wraps
- The keystore format, covering encryption, decryption, password handling and wallet import and export
- The Trust Wallet Android and iOS applications and the Chrome extension, which the program names in the same in-scope list, including the lock-screen path the brief calls out
- wallet-core as a whole: the C++ and Rust core, the protobuf-defined interfaces around it, and the generated Kotlin, Swift, TypeScript and Go bindings that downstream wallets actually call
Out of scope (7)
- Address-bar spoofing in the dApp browser
- Anything that requires the device to be rooted or jailbroken, which earns points rather than money
- Automated scanner output, which the engagement prohibits outright
- The standard Bugcrowd ineligible list: SPF, DKIM and DMARC record complaints, clickjacking with minimal impact, password-policy objections and email-verification deficiencies
- The *.trustwallet.com and *.trustwalletapp.com web properties, excluded both from scope and again in the ineligible list
- Third-party library dependencies, which pay nothing even where wallet-core links against them
- TWT referral-programme issues
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Submit through sorona.xyz first.
-
Automated scanners are prohibited on this engagement
-
Findings that depend on a rooted or jailbroken device earn reputation points only, not cash
-
Third-party library dependencies pay nothing: the defect has to be in wallet-core or in the Trust Wallet applications themselves
-
Do not publicly disclose the vulnerability until it has been patched, per the project's own security policy
Not accepted
-
Third-party library dependencies, which pay nothing even where wallet-core links against them
-
Address-bar spoofing in the dApp browser
-
Anything that requires the device to be rooted or jailbroken, which earns points rather than money
-
TWT referral-programme issues
-
Automated scanner output, which the engagement prohibits outright
-
SPF, DKIM and DMARC record complaints
-
clickjacking with minimal impact
-
password-policy objections
-
email-verification deficiencies
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2025-66692 | A buffer over-read in the PublicKey::verify() method of Binance - Trust Wallet Core before commit 5668c67 allows attackers to cause a Denial of Service (DoS) via a crafted input. | High 7.5 | 20 Jan 2026 |
| CVE-2023-31290 | Trust Wallet Core before 3.1.1, as used in the Trust Wallet browser extension before 0.0.183, allows theft of funds because the entropy is 32 bits, as exploited in the wild in December 2022 and March 2023. This occurs because the mt19937 Mersenne Twister takes a single 32-bit value as an input seed, resulting in only four billion possible mnemonics. The affected versions of the browser extension a | Medium 5.9 | 27 Apr 2023 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz P1 (wallet-core reachable ceiling; the star-marked $100,000 exceptional band belongs to the Binance exchange targets, not to this library) │ $5,000 - $10,000 │ $6,000 - $11,000 P2 │ $1,500 - $5,000 │ $1,875 - $6,000 P3 │ $600 - $1,500 │ $750 - $1,875 P4 │ $200 - $600 │ $250 - $750 Submit a vulnerability CVE history 1 Last 12 months 3 Lifetime Info disclosure 35 % Memory safety 25 % Parsing/validation 25 % Auth bypass 10 % Latest advisories Loading the feed Overview wallet-core is one of the most widely embedded key-management libraries in the industry and is considerably more ubiquitous than the Trust Wallet app itself. It implements HD derivation, mnemonic handling, address encoding and transaction signing for well over a hundred blockchains behind a single cross-platform interface — a C++ and Rust core with Kotlin, Swift, TypeScript and Go bindings — and it is consumed by third-party wallets, exchanges and custody products that never ship any Trust Wallet UI. That makes it structurally a crypto primitive library rather than an application: a signing or derivation defect is a defect in every downstream integrator simultaneously, and those integrators update on their own schedules. Trust Wallet itself has a user base in the tens of millions and is the default wallet surfaced inside the Binance ecosystem. Its single published advisory is instructive about what matters here — GHSA-7g72-jxww-q9vq, critical, "Key exposure attack in secret.rs", December 2024 — because key exposure is precisely the impact class the Binance brief names. Binance pays through Bugcrowd on a P1-to-P4 ladder: $5,000 to $10,000 at P1, down to $200 to $600 at P4. The programme also advertises a star-marked $100,000 for exceptionally severe issues, but that is a programme-wide discretionary figure on an engagement built around the exchange, and nothing attaches it to this library, so treat $10,000 as the reachable ceiling. sorona.xyz adds 1.25× on top of whatever Binance awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope Binance lists the library by literal repository URL as a first-group bounty-eligible target, and its Trust Wallet section names four things in scope: github.com/trustwallet/wallet-core , the Android app, the iOS app and the Chrome extension. The hosted web properties are carved out, so the open-source library is the paying surface here wallet-core as a whole: the C++ and Rust core, the protobuf-defined interfaces around it, and the generated Kotlin, Swift, TypeScript and Go bindings that downstream wallets actually call Key material handling: mnemonic generation and validation, BIP-39 seed derivation, HD derivation across paths and curves, and how private keys are held and cleared in memory The keystore format, covering encryption, decryption, password handling and wallet import and export Per-chain address derivation, encoding and validation for the hundred-plus supported blockchains, including the checksum and format checks applied to an address a user pastes in Per-chain transaction construction, serialisation and signing, together with the decoding of chain data and transaction payloads that feeds it The cryptographic primitives underneath all of that: the signature schemes, hashes and encodings the core implements or wraps The Trust Wallet Android and iOS applications and the Chrome extension, which the program names in the same in-scope list, including the lock-screen path the brief calls out Out of scope The *.trustwallet.com and *.trustwalletapp.com web properties, excluded both from scope and again in the ineligible list Third-party library dependencies, which pay nothing even where wallet-core links against them Address-bar spoofing in the dApp browser Anything that requires the device to be rooted or jailbroken, which earns points rather than money TWT referral-programme issues Automated scanner output, which the engagement prohibits outright The standard Bugcrowd ineligible list: SPF, DKIM and DMARC record complaints, clickjacking with minimal impact, password-policy objections and email-verification deficiencies Most-valued findings Remote exposure of a private key or the mnemonic seed phrase. It is the impact the brief names first, the exact shape of the library's one published advisory, and the only reliable route to the P1 band at $5,000 to $10,000 A signing defect that makes a transaction commit to different terms than the ones the user was shown, which is remote loss of funds by another name and the second impact the brief names Key-derivation flaws in HD path or mnemonic handling that yield predictable, colliding or cross-chain-reused keys, because the failure is silent and every wallet built on the library inherits it Chain-specific signer and address-derivation errors in the per-blockchain modules: with a hundred-plus chains supported, the long tail is where review attention is thinnest and where "vulnerabilities in chain-related implementations" is explicitly priced Memory-safety defects in the C++ and Rust core reachable from attacker-supplied transaction, address or key-material bytes. That is 25% of the expected distribution, and the class most likely to turn a parsing bug into key disclosure Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Automated scanners are prohibited on this engagement Findings that depend on a rooted or jailbroken device earn reputation points only, not cash Third-party library dependencies pay nothing: the defect has to be in wallet-core or in the Trust Wallet applications themselves The hosted web properties are out entirely: *.trustwallet.com and *.trustwalletapp.com are excluded, which is the reverse of the usual arrangement and means the open-source library is the paying surface Do not publicly disclose the vulnerability until it has been patched, per the project's own security policy Disclosure Bugcrowd triages on Binance's behalf, and wallet-core's own SECURITY.md sends reporters there rather than to a project address. The project's policy is a straightforward embargo until a patch exists, and because the library ships into third-party wallets and custody products on their own release cadences, expect the practical hold to run past Trust Wallet's own update. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability