MetaMask
External Program
Submit bugs directly to this organization
MetaMask
MetaMask will make a best effort to meet the following SLAs for hackers participating in our program:
| Type of Response | SLA in business days |
|---|---|
| First Response | 1 day |
| Time to Triage | 5 day |
| Time to Bounty | 14 days |
| Time to Resolution | Depends on severity & complexity |
We’ll try to keep you informed about our progress throughout the process.
Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
All reports must be accompanied with a working proof-of-concept or clear reproduction steps that demonstrates the impact described by the submission. This helps our triage team better investigate your finding, and ensures the full impact of your report is considered for a bounty. Reports which claim to have a specified impact that is later proven false (and does not result in action from the MetaMask security team) may be closed as Not-Applicable.
Reports which do not meet our severity threshold for a bounty, but still result in meaningful action amongst our security team, will no longer be marked as triaged. Instead they will be immediately closed as resolved when the ticket is added to our backlog (e.g. reporting an issue which highlights a risk that our team commits to addressing in the future).
To experiment with MetaMask without using your own ETH, you will want to switch your default network from Ethereum Mainnet to Sepolia test network. This network is hidden by default, so you will need to go to your account settings and enable "Show test networks" to include it as a selectable option.
Once you are on the Sepolia test network, visit https://www.infura.io/faucet and enter your wallet address to get funds sent to your account. If you do not already have an infura account, you will be required to create on at this time. If you come across any vulnerabilities within infura, please report them to us at https://hackerone.com/consensys.
At MetaMask, we are deeply committed to ensuring a fair and objective assessment of report severities. While we rely on the CVSS framework for severity decisions, we recognize its potential limitations in fully capturing the impact, and can sometimes introduce ambiguity in its interpretation. To maintain consistency and address these challenges, our team uses an internal CVSS scoring guide tailored to MetaMask. In the spirit of transparency, we have provided a simplified version of this guide below, granting our hackers a clearer understanding of how we assess each metric.
This scoring framework applies to reports impacting the MetaMask wallet. Reports impacting other assets (e.g, our APIs), will be scored according to CVSS 3.1.
| Metric | Options |
|---|---|
| Attack Vector (AV) | Network (N): The attack can be executed over a network connection (e.g., a MetaMask user visits a page that triggers an XSS payload). |
| Local (L): The attack requires local execution by malicious software / user in order to be exploited. | |
| Attack Complexity (AC) | High (H): A successful exploit requires overcoming specific conditions beyond the attacker's control, necessitating significant preparatory or execution effort. (e.g., requiring the attacker to exploit a particular race condition) |
| Low (L): No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed. | |
| Scope (S) | Changed (C): The vulnerability impacts resources beyond capabilities provided by its authorizing scope. (e.g., a dApp is able to change the users password by interacting with the ethereum provider API). |
| Unchanged (U): The vulnerability only impacts resources within its authorized scope (e.g., a dApp is able to change the origin of transaction it requests). | |
| Privileges Required (PR) | High (H): The vulnerability requires a snap installed which has sensitive permissions. |
| Low (L): The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without sensitive permissions. | |
| None (N): The vulnerability can be exploited without being connected to the wallet or a snap. | |
| User Interaction (UI) | Required (R): Exploitation of the vulnerability requires some form of user interaction. |
| None (N): Exploitation does not require any user interaction (e.g., a supply chain attack). | |
| Confidentiality Impact (C) | High (H): Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase). |
| Low (L): Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences) | |
| Integrity Impact (I) | High (H): A cryptographic asset or key security control loses its integrity (e.g., spoofing the origin of a transaction, tampering the wallets keys to an attacker controlled value) |
| Low (L): A user interface element meant to be a security control loses its integrity (e.g., making a signature request display in a non-human readable format rather than using one of the MetaMasks custom confirmation UI's) | |
| Availability Impact (A) | High (H): Due to MetaMask being a decentralized client and non-custodial wallet, availability impact is generally not as severe. A:H is awarded selectively on a case-by-case basis. |
| Low (L): MetaMask stops working completely. The application becomes unusable, the issue persists even after rebooting the device, and the only recovery is by reinstalling MetaMask. |
Please note that as this guide evolves, changes will only ever apply new reports. The MetaMask team will not be making adjustments retroactively to past bounties.
When multiple reports are received for a vulnerability, the MetaMask team will prioritize the First-Actionable report over the First-Submitted report. This means that instead of using the submission timestamp to determine which report to triage, we will focus on the report that first provides adequate details, allowing our team to reproduce and confirm the vulnerability.
In most cases, the First-Submitted report will also be the First-Actionable report. However, this change ensures that researchers are not penalized for taking the time to submit a thorough and complete report, while another researcher may submit a quick but incomplete report, with un-reproducible instructions or missing key information that is only provided later.