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.

1. Trezor device and its firmware
2. Trezor Suite and Trezor Connect
3. Blockbook and related infrastructure
4. Trezor.io e-shop.
5. Other websites running at trezor.io operated by us.

Trezor devices and firmware

This category includes vulnerabilities specifically related to Trezor hardware devices, firmware, physical device security, and device-level supply chain integrity. This category is by far the most important to us as Trezor is after all the ultimate point of security in our threat model.

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.

Conditions

What is eligible

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

Fixable in firmware. An attack that no firmware change 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.

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 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.

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.

How findings are assessed

For reports that pass the eligibility tests above, the following factors are taken into consideration when assessing their severity.

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 benefit such as theft is 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.

Rewards

Hardware and firmware vulnerabilities are the most important to us. When discussing their severity we always take scalability into account as a very important aspect. Vulnerability that may not lead to coin loss directly but scales very well and somehow decreases the product’s security can be more critical than difficult to scale hardware attack where Trezor needs to be in a physical possession.

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

Trezor Suite and Trezor Connect

This section covers vulnerabilities affecting Trezor Suite, Trezor Connect (same repository as Suite) and any related JavaScript libraries and 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.
• 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.

Rewards

Trezor device operates with the assumption that the host can be fully malicious. We still take these issues seriously but our threat model is different from what it is usually to other software wallets. That’s why our potential rewards might be lower than SW wallets as in their case this can lead to theft. In our case, we always have the Trezor device as the ultimate protection.

Blockbook and other backend infrastructure

This category includes 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, 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.

Rewards

As we do not store any users’ data (except for logs for very limited time), any potential backend exploits can’t really interfere with users' funds.

Trezor.io

Issues related to our e-commerce solution 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 product through cart/request tampering. Any abuse of loyalty programs, gift cards, or referral schemes or any checkout anomalies.

Rewards

Other

Any other issues that are not listed above and at the same time not excluded below. Usually these are websites running at *.trezor.io operated by us.

Out-of-Scope Issues

The following types of issues are not considered in scope for reporting:

• Clickjacking & Tabnabbing: Techniques that rely solely on deceptive interfaces or redirects, without posing a direct security impact on the Trezor device.
• 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 without major vulnerabilities: 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.

Responsible Disclosure Guidelines

By submitting a vulnerability, you agree to provide us time to diagnose and resolve the issue before sharing details with third parties or the public.

Reporting Rules

• Use exploits solely to verify the existence of vulnerabilities.
• Vulnerabilities must demonstrate clear exploitability and practical impact to be eligible for rewards.
• Non-exploitable theoretical vulnerabilities or routine scanning results without demonstrated practical impact are not eligible for rewards.
• 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.
• Do not engage in testing that degrades our systems or impacts users, results in unauthorized access, storage, sharing, or destruction of data, involves social engineering or spam.
• Do not exploit vulnerabilities beyond what is necessary to confirm their existence.
• Avoid phishing and social engineering of our employees or collaborators.

Rewards

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

• You are the first person to report the vulnerability.
• The vulnerability is confirmed by the security team.
• You have complied with the rules outlined above.

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. In some special circumstances we may consider paying out in EUR if requested.

Reward Amounts

Possible rewards are noted above in each section. The reward amount is determined by:

• Severity classification
• The impact on crypto assets managed by Trezor.
• The completeness of your report.

Please note that our main interest is in attacks lowering the security of the Trezor device itself. Other vulnerabilities are therefore treated as lower impact. The final reward amount is determined solely by Trezor.

Submission Process

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.

Report Requirement

Include:

• A detailed description of the vulnerability and its potential impact.
• Clear steps to reproduce the issue (proof-of-concept scripts or screenshots recommended).
• An explanation of how it affects crypto assets managed by Trezor.
• English language reports are required.

Communication

All further communications, including any exchange of sensitive information, should occur through [email protected]. If enhanced security is needed, we agree on a more secure channel, typically a Signal group chat.

Remediation & Disclosure

We will verify and prioritize your report, then work to remediate the vulnerability promptly. We will keep you informed of progress. Refrain from public disclosure until the issue is fully resolved.

Acknowledgment Program

With your consent, we will display your name or pseudonym as the discoverer of the reported vulnerability on our website’s acknowledgment page. If desired, we can also include an optional attribution link.