Trezor bug bounty program: scope, rules, and rewards

At Trezor, transparency and security are our top priorities. Our source code is publicly available, having undergone audits by independent security researchers for many years. By embracing open-source principles and actively collaborating with our community, we continually strengthen the safeguards protecting Trezor devices, software, and infrastructure.

If you believe you’ve discovered a vulnerability that could significantly affect Trezor devices, software, or infrastructure, please report it to [email protected]. Our Security Team will verify the issue, work with you on a fix, and reward the first valid submission.

Scope

Our Bug Bounty Program covers our hardware, software, and related infrastructure. We are particularly interested in vulnerabilities that could potentially allow attackers to compromise the security of crypto assets managed by Trezor devices.

Trezor devices and firmware

Vulnerabilities related to Trezor hardware devices, firmware, physical device security, and device-level supply chain integrity.

Protected properties

The firmware is designed to protect the following properties.

Device authenticity. Firmware contributes to establishing that the device is genuine Trezor hardware, for instance through device attestation.

Firmware integrity. The device runs only genuine Trezor firmware and bootloader. Unauthorized or modified code cannot execute without the user being warned.

PIN protection. The PIN cannot be bypassed, and the number of PIN attempts is limited.

Seed confidentiality. The wallet seed and derived keys cannot be extracted from the device, except through the deliberate backup mechanism initiated by the user.

Confirmation integrity. What the device shows the user is accurate, and security-critical actions require confirmation on the device that cannot be bypassed. This covers transaction details, the receiving address, and the spending policy established at setup, such as a passphrase or a multisig cosigner set.

Plausible deniability. After reboot, the device gives no external indication of how many passphrases it has been used with.

Declared privacy. Where the firmware is written to require user confirmation before disclosing data, the user confirmation cannot be bypassed.

Availability. A remote attacker cannot render the device permanently and unrecoverably unusable.

Assumed attacker capabilities

Malicious host. The host (computer, USB or Bluetooth stack, or connected software) can be fully malicious.

Physical possession. An attacker may take physical possession of a device and may perform invasive attacks such as disassembly, decapping, and direct probing of components.

Evil maid. An attacker may replace the user's device or return it to the user's possession after tampering with it, without the user's knowledge.

Supply chain. An attacker may tamper with a device before it reaches the user.

Trezor Suite and Trezor Connect

Vulnerabilities affecting Trezor Suite, Trezor Connect (same repository as Suite), and any related software components.

• Cross-site scripting (XSS): Injection of malicious scripts into Trezor Suite or Trezor Connect.
• Third-party library and supply chain vulnerabilities: Malicious modifications or vulnerabilities in third-party JavaScript libraries and dependencies integrated into Trezor Suite with clear impact on the product’s security.
• Trezor Suite integrity: Persistent compromise of an installed Trezor Suite Desktop or Mobile instance achieved by remote means — e.g., XSS or RCE within the application, or subversion of the update channel (signature verification bypass, unauthenticated or spoofable update source). Includes modification of application files, stored state, or configuration that survives a restart and affects security-relevant behaviour, such as silently repointing the backend.
• Modifications of data sent to or received from Trezor: Any vulnerabilities that can lead to modification of data (e.g. transactions and addresses) sent to or received from Trezor. Please note that in our threat model we assume the host can be fully malicious and transactions need to be confirmed on Trezor’s display. Any vulnerabilities in Suite will be treated with that in mind.
• Bypassing the Suite authentication checks: New exploits that highlight the limitations or demonstrate methods of circumventing Trezor Suite’s recommended authentication checks in the Trezor Safe series. We are particularly interested in clever or novel attacks.
• Vulnerabilities in our trading section: Any exploits or security issues in our buy/sell/swap interfaces and staking offerings, including its backend implementations operated by us.
• UI redressing against the Connect popup. Framing, overlaying, or otherwise manipulating the Connect popup so that the user's consent is obtained for a different origin than the one displayed, or so that an action Connect performs without on-device confirmation is triggered without genuine consent. Because Connect is invoked from third-party origins by design, we treat its origin display and consent prompts as a security boundary. The attack must be demonstrable from an ordinary, non-privileged web origin. Anything that requires privileged access to the user's system or browser — local malware, or software that can read or modify browser chrome — is out of scope, since an attacker at that level can cloak or spoof the popup regardless of what Connect does.

Blockbook and other backend infrastructure

Vulnerabilities in the Blockbook servers and other backend infrastructure critical to the Trezor ecosystem.

• Blockbook server exploitation: Unauthorized access or privilege escalation on Blockbook servers, remote code execution vulnerabilities specifically targeting Blockbook servers, cross-site scripting (XSS) in Blockbook-served interfaces or API responses, misconfigurations (e.g., Nginx server misconfigurations) allowing unauthorized access to internal resources or unintended actions.
• Backend infrastructure misconfigurations: Firewall misconfigurations or significant backend server settings issues exposing internal services beyond intended restrictions, proven vulnerabilities enabling unauthorized access or remote code execution via endpoints.

Trezor.io

Issues related to our e-commerce solution and related pages located at trezor.io.

• Cross-site scripting (XSS): Injection of malicious scripts into Trezor.io.
• Third-party library and supply chain vulnerabilities: Malicious modifications or vulnerabilities in third-party JavaScript libraries and dependencies integrated into Trezor.io that can lead to provable security exploits.
• Broken Access Control: Any attacks that enable an attacker to access the administration interface.
• Sensitive Data Exposure: Leakage of any personal information, sensitive API keys or credentials.
• SQL Injection: SQL injection flaws that allow attackers to obtain sensitive data.
• Server misconfiguration: Misconfigurations allowing unauthorized access to internal resources or unintended actions. For example, Nginx or Cloudflare misconfigurations. Please also see the “out of scope” section below.
• Payment & Order Tampering: Price manipulation, discount/coupon abuse, or free products through cart/request tampering. Any abuse of loyalty programs, gift cards, or referral schemes, or any checkout anomalies.
• Reverse tabnabbing and open redirects. Links or redirects on trezor.io that allow an attacker to control or rewrite the originating tab, or to launder a phishing destination through our domain. A working proof of concept is required.

What is eligible

A report is eligible only if it passes all of the following.

Fixable within the target product. An attack that no code change in the target product can prevent or make meaningfully costlier is out of scope.

Example — A hidden camera with a view of the device reads anything shown on the screen, including the PIN as it is entered. No firmware change can prevent this.

Superior to unpreventable attacks. An attack is out of scope if some unpreventable attack achieves the same goal while requiring no stronger preconditions and no greater cost.

Example — An electromagnetic probe hidden under the table that detects the PIN as it is entered captures the same information as the hidden camera and requires comparable physical access, so it is not eligible. By contrast, a malicious host that obtains the entered PIN remotely by exploiting a device-protocol bug to dump part of the device's memory remains eligible, since its preconditions are weaker.

Flawed safeguard. Some safeguards are best-effort and their defeatability given sufficient resources is part of the threat model. Defeating such a safeguard by the anticipated means is not a finding. A report against a best-effort safeguard is eligible only if it shows one of the following.

• A route substantially cheaper than the level of resources, expertise, and effort the safeguard is designed to withstand.
• An implementation error that makes the safeguard fall short of its intended strength.

Example — some checks that establish device authenticity can be defeated with sufficient resources. Demonstrating this is not a finding. However, a substantially cheaper bypass or an error in how the checks are implemented is eligible. Such a bypass must arise from the firmware's role in establishing authenticity, not from an attack on the hardware as such.

Active in production or planned for release. We encourage reporters to report vulnerabilities even in unused or unreleased code on the main branch. However, if a functionality is clearly unfinished or not planned to be used in production, a report may be rejected or receive a reduced reward.

Demonstrated, not merely theoretical. A report must demonstrate that the claimed attack can be carried out, not merely argue that it could exist. The evidence required to demonstrate the attack depends on its nature.

• For example, for exploits that can be carried out through the device protocol, the report must include a device test demonstrating it. A device test is a Python function under trezor-firmware/tests/device_tests/, run against the emulator through trezorlib, that demonstrates the incorrect behavior by asserting on what the device shows or returns, such as an unexpected acceptance, a missing or wrong confirmation screen, or an incorrect result on valid input.
• For a side channel, empirical evidence is required, such as an oscilloscope capture of the secret-dependent signal together with a working extraction. An argument that a channel may exist is not sufficient.
• If an attack requires covert deployment in the victim's environment, the report must also show the attack can be deployed without the victim noticing, for instance, a probe concealed near the device. This does not apply where the attacker operates the device, since there is no victim to deceive.

A report that does not demonstrate the claimed behavior may receive a reduced reward or be rejected at our discretion. As an exception, code that is written to enforce a security invariant but demonstrably fails to do so requires no attack demonstration. For example, a constant-time implementation containing a defect such as a data-dependent branch or memory access is eligible without physical measurement, since the failure is verifiable in the source code.

Out-of-Scope Issues

• Phishing or social engineering attacks: Attacks that rely on deceiving users, without exploiting technical vulnerabilities. While these are out of scope for the bug bounty program, we still encourage and appreciate reports of phishing or fraudulent websites to help protect the community.
• Missing security headers without proof of concept: Reports of missing HTTP security headers unless accompanied by a working, exploitable proof of concept.
• Reports from automated vulnerability scanners: Automated reports without manual verification or demonstrated exploitability.
• Insecure SSL/TLS cipher suites unless exploitable: Reports of weak SSL/TLS configurations unless they have a proven security impact.
• Outdated libraries: Reports of outdated dependencies unless they are linked to significant, exploitable vulnerabilities.
• Denial-of-service attacks: All DoS reports are out of scope and not eligible for any reward.
• Vulnerabilities in third-party services we do not operate, including domains at *.trezor.io run by partners
• Self-XSS and issues that require the victim to paste content into their own browser console.
• Inaccurate clear-signing descriptors. For clear signing, we parse call data using the ERC-7730 registry, which is hosted and recommended by the Ethereum Foundation and used by several wallet providers across the Ethereum ecosystem. We do not control its contents. An exploit arising solely from an inaccurate or misleading contract description in the registry is not eligible for a reward. Please report such discrepancies to the Ethereum Foundation through the registry's own issue process, and tell us as well so we can follow up. Defects on our side remain in scope. This includes inadvertent mismatches between a descriptor and the call data actually being signed that we fail to detect, incorrect rendering of an accurate descriptor, unsafe handling of a malformed descriptor, and unsafe fallback behaviour where no descriptor is available.
• Vulnerabilities in outdated firmware: Reports must demonstrate the issue against the latest released firmware. An attack that only works on an older firmware version is out of scope. However, a downgrade path is in scope: if a High or Critical vulnerability was fixed in a firmware release and an attacker running against the current version can induce or force a user to downgrade to the still-vulnerable version, that is a valid report — the failure to prevent the downgrade is the vulnerability.

Rewards

Trezor devices are designed on the assumption that the host machine may be fully compromised. Signing and confirmation happen on the device itself, so a malicious host alone should never be sufficient to move a user's funds. This is a meaningfully different threat model from most software wallets, where compromising the host can lead directly to theft. We take host-side and application-layer findings seriously, but because the device remains the final line of defense, rewards in these areas may be lower than what a comparable finding would earn from a software-only wallet.

Each product category has its own reward ceiling. The reward for a valid report is determined by the severity of the finding, up to that ceiling.

*In exceptionally critical cases, there is no upper reward limit

How severity translates into a reward

Rewards rise disproportionately with severity: the difference between a high-severity and a critical finding is much larger than the difference between a low and a medium one. We assess each report on how severe and how practically exploitable it is, and the resulting reward follows a steep exponential curve toward the category ceiling.

In practice, this means the top of the range is reserved for genuinely critical findings — a realistic, remotely exploitable attack that puts user funds directly at risk. Theoretical findings, require unrealistic preconditions, or have limited impact land much lower on the curve. Each step up in severity is worth substantially more than the step below it:

The more severe the finding, the closer to the full reward.

Final reward amounts are determined by the Trezor security team at its discretion and are not subject to re-evaluation or negotiation. Should you later identify additional impact not covered by your original report, submit it as a new report rather than requesting a review of an existing decision.

You may be eligible for a reward for reporting a vulnerability if the following conditions are met:

• The vulnerability was not already known to us. (Although we won’t usually be able to prove this).
• The vulnerability is confirmed by the security team.
• You have complied with the reporting rules.

We reserve the right to change the code or behavior that a report concerns without implying the report is eligible. We may do so for defense in depth, future-proofing, or to reduce report volume.

Multiple reports of the same issue

Where more than one report describes the same underlying issue and all of them reach us before the fix is publicly released, the reward for that issue is shared between the reporters rather than awarded to whoever wrote in first. A report that took longer to prepare is often the better report, and we would rather not penalise the care that went into it.

• The reward is determined once for the issue, on the basis of the fullest picture the reports give us together, and then divided. It is not calculated separately for each report.
• Reports of equivalent substance share equally. Where one report contributes materially more — wider impact, a working exploit under weaker preconditions, a clearer identification of the root cause — the split reflects that contribution rather than the order of arrival.
• Reports concern the same issue where they share a root cause, even if they reach it through different vectors or describe different symptoms.

Payment

Rewards will be paid directly to the researcher in Bitcoin, based on the USD/BTC exchange rate at the time of payment. To receive the reward, you must provide a valid Lightning Network (LN) invoice or Bitcoin address after we confirm the vulnerability. We will notify you when it’s time to submit your invoice. Upon request, we can pay out the reward in EUR.

How findings are assessed

The following factors are taken into consideration when assessing the severity of the findings and the resulting reward.

Impact and scalability. Severity is driven primarily by the impact on crypto assets and by the scalability of the attack. An attack that has medium impact on the security of the device, but scales well, may rate higher than an attack requiring physical possession of a single device that does not scale, even where the latter has higher direct impact.

Attack cost. The cost of an attack affects its severity, not its eligibility. An expensive attack is rated lower than a cheap one with the same impact.

Attacker benefit. Severity reflects what an attacker gains. Direct benefits such as theft are most severe. An attacker who cannot steal the funds but can deny the user access to them and extract payment for restoring it, a ransom attack, is also strongly motivated and rated accordingly. Damage to the victim with no benefit to any attacker is least severe.

Defense in depth. Where a property is protected by several safeguards such that defeating one does not by itself breach the property, defeating a single safeguard is reduced in severity in proportion to the protection that remains.

Demonstrated exploitability. A finding whose exploitation is not demonstrated, such as a constant-time defect visible in the source but not shown to be exploitable, is rated at the low end. Severity rises with the extent to which exploitation is shown to be practical.

Responsible Disclosure

Reporting Rules

• Use exploits solely to verify the existence of vulnerabilities.
• Avoid phishing and social engineering of our employees or collaborators.
• When submitting a vulnerability report, you agree to allow us the opportunity to diagnose and remedy the vulnerability before disclosing its details to third parties or the public. We will coordinate the disclosure together.
• A report that does not meet the eligibility requirements may be closed without detailed review. We are not able to provide a full explanation for every out-of-scope or unsubstantiated report.
  • We may close without notice: unverified output of automated scanners or language models, reports without a working proof of concept, reports that restate our documented threat model as though it were a finding, reports covering items we list as out of scope, and template or mass-submitted reports.
  • Where a reporter repeatedly submits reports of this kind, we may decline to review their further submissions.
  • We may also decline to work with anyone who threatens early disclosure, makes a report conditional on a payment, or otherwise acts in bad faith.

Submission

• To report a vulnerability, please email us at [email protected]. In case you consider this a sensitive manner we will provide instructions on how to set up a Signal encrypted channel.
• English language reports are required.
• Reports should be sent as .md files, optionally supported with code or video/image evidence.

Remediation

• We will verify and prioritise the finding and work to remediate it promptly, keeping you informed as we go.
• We reserve three months from the date of your report to develop and release a fix, unless we agree a different period with you.
• Most of our code is public. Where a fix could reveal the vulnerability, we develop and review it in a private repository and merge it to the public repository shortly before release. The public repository will therefore show no work on the issue while it is being fixed.

Acknowledgments

With your consent, we will display your name or pseudonym with an attribution link as the discoverer of the reported vulnerability on our website’s acknowledgment page, along with the bounty amount. Reports awarded less than $100 are not published.

Publication timing is at our discretion and is coordinated with the release of the fix.