[{"id":3774122,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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 informative 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\nThis 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)  / All of UI confirmation screen phishing security controls are bypassed/tampered with at the same time (User has no more warnings about a potential malicious origins)              |\n|                        | **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) / One or more UI confirmation screen phishing security controls are bypassed/tampered with (User still have at least a warning for a potential malicious origin) |\n| 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.                  |\n|                        | **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.  |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":false,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with decentralized applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}","{\"category\":\"Mobile Browser Resource Exhaustion / DoS\",\"details\":\"Reports of sites loaded in the mobile browser that cause MetaMask to crash or become unresponsive are only eligible for a bounty if the user cannot recover through standard actions (e.g., force closing the app/rebooting and clearing browser history in settings).\"}"],"timestamp":"2026-05-13T15:03:19.448Z"},{"id":3774103,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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 informative 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\nThis 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **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.  |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":false,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with decentralized applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}","{\"category\":\"Mobile Browser Resource Exhaustion / DoS\",\"details\":\"Reports of sites loaded in the mobile browser that cause MetaMask to crash or become unresponsive are only eligible for a bounty if the user cannot recover through standard actions (e.g., force closing the app/rebooting and clearing browser history in settings).\"}"],"timestamp":"2026-05-13T09:41:43.961Z"},{"id":3774102,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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 informative 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\nThis 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **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.  |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":false,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}","{\"category\":\"Mobile Browser Resource Exhaustion / DoS\",\"details\":\"Reports of sites loaded in the mobile browser that cause MetaMask to crash or become unresponsive are only eligible for a bounty if the user cannot recover through standard actions (e.g., force closing the app/rebooting and clearing browser history in settings).\"}"],"timestamp":"2026-05-13T09:23:55.582Z"},{"id":3770668,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\nThis 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **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.  |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":false,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}","{\"category\":\"Mobile Browser Resource Exhaustion / DoS\",\"details\":\"Reports of sites loaded in the mobile browser that cause MetaMask to crash or become unresponsive are only eligible for a bounty if the user cannot recover through standard actions (e.g., force closing the app/rebooting and clearing browser history in settings).\"}"],"timestamp":"2026-03-06T13:45:08.432Z"},{"id":3766555,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\nThis 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **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.  |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}","{\"category\":\"Mobile Browser Resource Exhaustion / DoS\",\"details\":\"Reports of sites loaded in the mobile browser that cause MetaMask to crash or become unresponsive are only eligible for a bounty if the user cannot recover through standard actions (e.g., force closing the app/rebooting and clearing browser history in settings).\"}"],"timestamp":"2025-11-25T16:33:31.309Z"},{"id":3763909,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\nThis 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **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.  |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!\n\n# Important Notice\n\nMetaMask leverages HackerOne's managed triage service for initial assessment of reports before they reach the MetaMask team. Due to current internal challenges at HackerOne, their assessment process may **exceed 1 week**. We're actively working with the HackerOne team to identify how we can improve this experience for our hackers. Please be assured that despite the initial delay from the HackerOne team, your report will be reviewed.\n\n","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}","{\"category\":\"Mobile Browser Resource Exhaustion / DoS\",\"details\":\"Reports of sites loaded in the mobile browser that cause MetaMask to crash or become unresponsive are only eligible for a bounty if the user cannot recover through standard actions (e.g., force closing the app/rebooting and clearing browser history in settings).\"}"],"timestamp":"2025-09-30T21:15:08.660Z"},{"id":3762355,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\nThis 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **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.  |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!\n\n# Important Notice\n\nMetaMask leverages HackerOne's managed triage service for initial assessment of reports before they reach the MetaMask team. Due to current internal challenges at HackerOne, their assessment process may **exceed 1 week**. We're actively working with the HackerOne team to identify how we can improve this experience for our hackers. Please be assured that despite the initial delay from the HackerOne team, your report will be reviewed.\n\n","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}","{\"category\":\"Mobile Browser Resource Exhaustion / DoS\",\"details\":\"Reports of sites loaded in the mobile browser that cause MetaMask to crash or become unresponsive are only eligible for a bounty if the user cannot recover through standard actions (e.g., force closing the app/rebooting and clearing browser history in settings).\"}"],"timestamp":"2025-09-04T18:26:51.940Z"},{"id":3761205,"new_policy":"# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe!\n\n# Important Notice\n\nMetaMask leverages HackerOne's managed triage service for initial assessment of reports before they reach the MetaMask team. Due to current internal challenges at HackerOne, their assessment process may **exceed 1 week**. We're actively working with the HackerOne team to identify how we can improve this experience for our hackers. Please be assured that despite the initial delay from the HackerOne team, your report will be reviewed.\n\n","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}"],"timestamp":"2025-08-15T14:39:39.044Z"},{"id":3756187,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope.\"}","{\"category\":\"Malicious RPC Servers\",\"details\":\"Reports requiring malicious RPCs remain out of scope unless the RPC can impact resources beyond its expected scope (e.g., achieving XSS, tampering restricted state).  Misleading data (e.g., faking balances or transactions) remains out of scope.\"}"],"timestamp":"2025-05-23T18:04:22.374Z"},{"id":3750931,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope. Reports involving users configuring a malicious RPC URL are considered to be a form of MITM attack.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}"],"timestamp":"2025-02-26T16:08:31.703Z"},{"id":3750930,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Report Evaluation Methodology\n\n## MetaMask Wallet CVSS Scoring Guide\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope. Reports involving users configuring a malicious RPC URL are considered to be a form of MITM attack.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}"],"timestamp":"2025-02-26T16:06:48.294Z"},{"id":3737268,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Report Evaluation Methodology\n\n## Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\u003e _Inspired by [Chrome's VRP](https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules#update-to-policy-regarding-unactionable-reports-and-duplicates) to promote fairness_\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope. Reports involving users configuring a malicious RPC URL are considered to be a form of MITM attack.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or core browser security features (e.g. address bar, CSP, SOP).\"}"],"timestamp":"2024-08-28T18:45:22.367Z"},{"id":3737089,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Report Evaluation Methodology\n\n## Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\u003e _Inspired by [Chrome's VRP](https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules#update-to-policy-regarding-unactionable-reports-and-duplicates) to promote fairness_\n\nWhen 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.\n\nIn 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.\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope. Reports involving users configuring a malicious RPC URL are considered to be a form of MITM attack.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}"],"timestamp":"2024-08-26T13:44:42.791Z"},{"id":3737088,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\nIn addition to the list of HackerOne's [Core Ineligible Findings](https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings), the following are considered to be out of scope vulnerabilities:\n\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n* User Storage service: Users can upload any type of data to the user storage database. We accept this as a risk at the current deployment so these kind of reports will be out of scope.\n\n# Report Evaluation Methodology\n\n## Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n## First-Submitted vs First-Actionable Reports\n\u003e _Inspired by [Chrome's VRP](https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules#update-to-policy-regarding-unactionable-reports-and-duplicates) to promote fairness_\n\nWhen 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.\n\nIn 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.\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope. Reports involving users configuring a malicious RPC URL are considered to be a form of MITM attack.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}"],"timestamp":"2024-08-26T13:24:20.458Z"},{"id":3737016,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n* User Storage service: Users can upload any type of data to the user storage database. We accept this as a risk at the current deployment so these kind of reports will be out of scope.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"Third-Party Snaps\",\"details\":\"Report third-party snap vulnerabilities to the Snap developer. If no response after a week, report to us for assistance in contacting them. Note: Third-party snap reports are marked as informative and are not bounty eligible.\"}","{\"category\":\"Attacks Requiring MITM or Physical Device Access\",\"details\":\"Requiring MITM or access to a user's device are out of scope. Reports involving users configuring a malicious RPC URL are considered to be a form of MITM attack.\"}","{\"category\":\"Attacks Requiring a Compromised Device\",\"details\":\"This includes attacks requiring the user to install a malicious application, execute malicious scripts, disabling device security settings, or jailbreaking/rooting their device.\"}","{\"category\":\"Vulnerabilities Affecting Outdated or Unpatched Browsers\",\"details\":\"This refers to browsers more than 2 versions behind the latest released stable version\"}","{\"category\":\"Exploits Requiring Seed Phrase Entry\",\"details\":\"User's are consistently reminded that they should never, ever, provide their seed phrase to anyone including the MetaMask team. Reports requiring users to act outside of these guidelines are considered to be out of scope.\"}","{\"category\":\"Perceived Security Weaknesses Without Demonstrable Impact\",\"details\":\"This includes reports regarding missing best practices, functional bugs without security implications, recommended security improvements etc.\"}","{\"category\":\"Secret Recovery Phrase Brute-Forcing\",\"details\":\"Reports attempting to brute forcing seed phrases are not valid or eligible. This exclusion does not exclude reporting legitimate cryptographic weaknesses in MetaMask's seed phrase generation.\"}","{\"category\":\"Reporting a Leaked Token Without Validation\",\"details\":\"Reporters must validate that leaked tokens from our applications are valid and can access sensitive operations. If you can't confirm this via public documentation, do not attempt to use the token, please report it to our team instead. Note that user API keys/SRPs leaked online are not valid.\"}","{\"category\":\"Mobile Browser Issues Without Security or Privacy Impact\",\"details\":\"Mobile browser issues are excluded unless a POC shows potential user fund loss or impacts critical areas such as user privacy (e.g. fingerprinting), wallet functionality (e.g. confirmation screens, wallet connections), or browser security features (e.g. address bar, CSP, SOP).\"}","{\"category\":\"User Storage Service Data Uploads\",\"details\":\"Users are permitted to upload any type of data to the user storage database. This is an accepted risk in the current deployment, and therefore, reports concerning this issue will be considered out of scope.\"}"],"timestamp":"2024-08-23T19:31:30.881Z"},{"id":3732298,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n* User Storage service: Users can upload any type of data to the user storage database. We accept this as a risk at the current deployment so these kind of reports will be out of scope.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":true,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-07-15T14:21:29.829Z"},{"id":3731363,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n* User Storage service: Users can upload any type of data to the user storage database. We accept this as a risk at the current deployment so these kind of reports will be out of scope.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-07-01T10:06:48.661Z"},{"id":3729782,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Privacy Issues\n\nMetaMask is committed to offering an exceptional, privacy-preserving experience that keeps users safe and enables them to configure wallet settings based on their preferences.\n\nWhen all feature toggles in the `Security \u0026 Privacy` settings are disabled, the MetaMask wallet should never send requests to any endpoint other than the user's network RPC server.\n\nTo stand behind our commitment to privacy, we are pleased to begin offering a fixed $100 bounty to any hacker who notices MetaMask making network calls when these optional features are disabled. \n\nWe look forward to continuing to work with the talented HackerOne community to make MetaMask the most secure and privacy-preserving web3 wallet\n\nDiscover the privacy-preserving features of MetaMask by visiting this [informative blog post](https://metamask.io/news/latest/product-spotlight-privacy-preserving-features-in-metamask/).\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-06-18T12:53:01.715Z"},{"id":3722543,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Introducing MetaMask Snaps\n\nSnaps is a feature that allows third party developers to add new functionality to MetaMask. A snap is a JavaScript program that runs in an isolated environment and customizes the wallet experience. Snaps have access to a limited set of capabilities, determined by the permissions the user granted them during installation.\n\n\nVisit our [quickstart guide](https://docs.metamask.io/snaps/get-started/quickstart/) to learn how to build your own snap, or visit https://snaps.metamask.io to see the possibilities that snaps now offer.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely. The application becomes unusable, and the issue persists even after rebooting the device. |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-04-04T17:17:35.247Z"},{"id":3713379,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Introducing MetaMask Snaps\n\nSnaps is a feature that allows third party developers to add new functionality to MetaMask. A snap is a JavaScript program that runs in an isolated environment and customizes the wallet experience. Snaps have access to a limited set of capabilities, determined by the permissions the user granted them during installation.\n\n\nVisit our [quickstart guide](https://docs.metamask.io/snaps/get-started/quickstart/) to learn how to build your own snap, or visit https://snaps.metamask.io to see the possibilities that snaps now offer.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed without [sensitive permissions](https://metamask-consensys.notion.site/Public-Snaps-Permissions-Privileges-Required-4745314a10814a4a9cb7c1dbcf8720e9). |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet or a snap.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely, or key features have degraded functionality. It is not clear to the user how to resolve the issue without re-installing the application. (e.g., sending an NFT to a user causes their wallet to continually crash)                                 |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-02-28T19:35:48.297Z"},{"id":3708311,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Introducing MetaMask Snaps\n\nSnaps is a feature that allows third party developers to add new functionality to MetaMask. A snap is a JavaScript program that runs in an isolated environment and customizes the wallet experience. Snaps have access to a limited set of capabilities, determined by the permissions the user granted them during installation.\n\n\nVisit our [quickstart guide](https://docs.metamask.io/snaps/get-started/quickstart/) to learn how to build your own snap, or visit https://snaps.metamask.io to see the possibilities that snaps now offer.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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`. \n\nReports 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).\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device (e.g. the installation of a malicious app, the execution of a script on the victims device, rooted device, etc.)\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, recommended security improvements etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n* Mobile browser issues that **do not** have a POC demonstrating how it can result in user fund loss, or how it impacts one of the following areas:\n    * User privacy (e.g. Fingerprinting)\n    * The wallet functionality of the application (confirmation screens, signatures, wallet connections)\n    * The integrity of browser security features used to protect users from phishing (e.g The correct rendering of the address bar)\n* Attacks which require the user to add a network with a malicious RPC server\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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 user to perform a specific action at a very specific moment) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has the `network-access`, `rpc`, `transaction-insight`, or `webassembly` permission. |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed with the `cronjob`, `ethereum-provider`, `long-running`, or `eth_accounts` permission |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely, or key features have degraded functionality (e.g., sending an NFT to a user causes their wallet to continually crash)                                 |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-11-30T14:52:19.639Z"},{"id":3703121,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# (NEW) Introducing MetaMask Snaps\n\nSnaps is a feature that allows third party developers to add new functionality to MetaMask. A snap is a JavaScript program that runs in an isolated environment and customizes the wallet experience. Snaps have access to a limited set of capabilities, determined by the permissions the user granted them during installation.\n\n\nVisit our [quickstart guide](https://docs.metamask.io/snaps/get-started/quickstart/) to learn how to build your own snap, or visit https://snaps.metamask.io to see the possibilities that snaps now offer.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet. \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways.\n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization. \n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Demonstrating Impact\nAll 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 may be closed as `Not-Applicable`. \n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\n\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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 user to perform a specific action at a very specific moment) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires a snap installed which has the `network-access`, `rpc`, `transaction-insight`, or `webassembly` permission. |\n|                        | **Low (L)**: The vulnerability requires the webpage to be connected to the wallet, or to have a Snap installed with the `cronjob`, `ethereum-provider`, `long-running`, or `eth_accounts` permission |   \n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely, or key features have degraded functionality (e.g., sending an NFT to a user causes their wallet to continually crash)                                 |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-20T17:51:54.926Z"},{"id":3702905,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Third Party Snaps\nVulnerabilities found in third party snaps should be reported to the developer responsible for the snap itself. You can find their contact information by visiting the snap’s page on https://snaps.metamask.io/. Please be mindful to not report the issue in a public location such as an open discord channel, or a GitHub issue. If you do not hear back from the developer after a week, you may report the issue here as well so that we may assist with getting in contact. Reports involving third party snaps will be marked as informative, and will not be bounty eligible. \n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# (New) Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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 user to perform a specific action at a very specific moment) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires the wallet to be connected to the dApp to be exploited.                                                                                                              |\n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely, or key features have degraded functionality (e.g., sending an NFT to a user causes their wallet to continually crash)                                 |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-18T12:43:40.387Z"},{"id":3699050,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope, and are likely to be closed as Not-Applicable:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n* Secret recovery phrase brute-forcing\n* Reporting a leaked token without first confirming it is valid and has access to sensitive operations\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# (New) Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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 user to perform a specific action at a very specific moment) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires the wallet to be connected to the dApp to be exploited.                                                                                                              |\n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely, or key features have degraded functionality (e.g., sending an NFT to a user causes their wallet to continually crash)                                 |\n\nPlease 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. \n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-07-27T06:52:05.576Z"},{"id":3690143,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Hacking Guides\nExtension hacking guide [https://metamask.github.io/security-blog/](https://metamask.github.io/security-blog/)\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n* Secret recovery phrase brute-forcing\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# (New) Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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 user to perform a specific action at a very specific moment) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires the wallet to be connected to the dApp to be exploited.                                                                                                              |\n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely, or key features have degraded functionality (e.g., sending an NFT to a user causes their wallet to continually crash)                                 |\n\nPlease 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. \n\n### Improvements to how we evaluate Attack Vector (effective June 1st)\n\nThe CVSS specification contains contradicting ideas regarding how to score attack vector for clients like MetaMask who are not capable of receiving requests over the internet. This ambiguity has resulted in frustration for hackers as arguments can be made to support both attack vector `network` or `local` for each report. To improve this experience for our community of hackers, we have decided to provide a clearer and more favorable assessment by classifying all remotely exploitable vulnerabilities as attack vector `network`. To adjust for this change, our `medium` severity bounty has also been modified to $2,500. We believe these changes will have an overall positive impact on bounties hackers can receive. For example, certain impacts that were previously rewarded with $5,000 at a 6.1 score would now receive $15,000 instead under this new evaluation. Thank you to all the hackers who provided us with valuable feedback that resulted in this change.\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-29T14:42:05.071Z"},{"id":3688558,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n* Secret recovery phrase brute-forcing\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# (New) Report Scoring\n\nAt 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.\n\n| Metric                 | Options                                                                                                                                                                                                 |\n|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 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).                                                                  |\n|                        | **Local (L)**: The attack requires local execution by malicious software / user in order to be exploited.                                                                       |\n| 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 user to perform a specific action at a very specific moment) |\n|                        | **Low (L)**: No specialized access conditions or extenuating circumstances exist. The attack can be reliably and repeatedly executed.                                                                     |\n| 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).  |\n|                        | **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).                                          |\n| Privileges Required (PR)   | **High (H)**: The vulnerability requires the wallet to be connected to the dApp to be exploited.                                                                                                              |\n|                        | **None (N)**: The vulnerability can be exploited without being connected to the wallet.                                                                                                                     |\n| User Interaction (UI)  | **Required (R)**: Exploitation of the vulnerability requires some form of user interaction.                                                                                                               |\n|                        | **None (N)**: Exploitation does not require any user interaction (e.g., a supply chain attack).                                                                                                          |\n| Confidentiality Impact (C) | **High (H)**: Attacker can disclose a cryptographic element in custody (Encrypted Vault, Password, Secret Recovery Phrase).                                                                              |\n|                        | **Low (L)**: Attacker can disclose non-critical user information. (e.g., user state logs, stored preferences)                                                                                            |\n| 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)                |\n|                        | **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) |\n| 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.                  |\n|                        | **Low (L)**: MetaMask stops working completely, or key features have degraded functionality (e.g., sending an NFT to a user causes their wallet to continually crash)                                 |\n\nPlease 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. \n\n### Improvements to how we evaluate Attack Vector (effective June 1st)\n\nThe CVSS specification contains contradicting ideas regarding how to score attack vector for clients like MetaMask who are not capable of receiving requests over the internet. This ambiguity has resulted in frustration for hackers as arguments can be made to support both attack vector `network` or `local` for each report. To improve this experience for our community of hackers, we have decided to provide a clearer and more favorable assessment by classifying all remotely exploitable vulnerabilities as attack vector `network`. To adjust for this change, our `medium` severity bounty has also been modified to $2,500. We believe these changes will have an overall positive impact on bounties hackers can receive. For example, certain impacts that were previously rewarded with $5,000 at a 6.1 score would now receive $15,000 instead under this new evaluation. Thank you to all the hackers who provided us with valuable feedback that resulted in this change.\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-02T19:52:47.591Z"},{"id":3688279,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n* Secret recovery phrase brute-forcing\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-05-29T14:09:36.186Z"},{"id":3686546,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction (e.g. Entering their seed phrase into a form)\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-04-25T14:58:57.612Z"},{"id":3686365,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n\n### Additional exclusions\n* We kindly ask that you close any pull requests you open against our public repositories once you have finished testing. Failure to do so, especially in cases where many pull requests are opened, may result in being banned from the MetaMask GitHub organization and render your report ineligible for a bounty.\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-04-19T14:03:38.986Z"},{"id":3685537,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo 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. \n\nOnce 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.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-03-29T18:04:48.269Z"},{"id":3678558,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding Your Wallet\nTo experiment with MetaMask without using your own ETH, you will want to switch your default network from **Ethereum Mainnet** to **Goerli 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. \n\nOnce you are on the Goerli test network, search online for a **reputable** Goerli [faucet](https://academy.binance.com/en/articles/what-is-a-crypto-faucet) which can be used to issue your wallet ETH at no cost.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-10-13T17:59:37.601Z"},{"id":3678555,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Funding your Wallet\nTo experiment with MetaMask without using your own ETH, you will want to switch your default network from **Ethereum Mainnet** to **Goerli 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. \n\nOnce you are on the Goerli test network, search online for a **reputable** Goerli [faucet](https://academy.binance.com/en/articles/what-is-a-crypto-faucet) which can be used to issue your wallet ETH at no cost.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-10-13T16:55:27.157Z"},{"id":3678442,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction\n* Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-10-11T20:49:10.494Z"},{"id":3673206,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 5 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Missing best practices in SSL/TLS configuration.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Missing best practices in Content Security Policy.\n* Missing HttpOnly or Secure flags on cookies\n* Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-06-22T16:24:09.192Z"},{"id":3672547,"new_policy":"MetaMask is one of the most widely used wallets for interacting with distributed applications. We look forward to working with the security community to find vulnerabilities in order to keep our users safe and are especially interested in reports related to our focus areas.\n\n# Prioritized Focus Areas\n* Reports demonstrating how an attacker could extract the secret recovery phrase or a private key from a wallet \n* Reports demonstrating how an attacker could make a users wallet behave in unexpected ways \n\n# Response Targets\nMetaMask will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 1 day |\n| Time to Triage | 1 day |\n| Time to Bounty | 14 days |\n| Time to Resolution | Depends on severity \u0026 complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Program Rules\nPlease 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.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing, fraudulent dapps or tokens) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and reward decisions are up to the discretion of MetaMask.\n\nWe use CVSS as a baseline but appreciate the impact edge cases can have so we intend to pay out fairly for reports that have a realistic impact.\n\n# Out of Scope Vulnerabilities\n### When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:\n\n* Clickjacking on pages with no sensitive actions\n* Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions\n* Attacks requiring MITM or physical access to a user's device.\n* Attacks requiring a compromised victim device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Comma Separated Values (CSV) injection without demonstrating a vulnerability.\n* Missing best practices in SSL/TLS configuration.\n* Any activity that could lead to the disruption of our service (DoS).\n* Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS\n* Rate limiting or bruteforce issues on non-authentication endpoints\n* Missing best practices in Content Security Policy.\n* Missing HttpOnly or Secure flags on cookies\n* Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)\n* Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.\n* Tabnabbing\n* Open redirect - unless an additional security impact can be demonstrated\n* Issues that require unlikely user interaction\n\n# Safe Harbor\nBy responsibly submitting your findings to MetaMask in accordance with these guidelines, MetaMask agrees not to pursue legal action against you. MetaMask reserves all legal rights in the event of noncompliance with these guidelines. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will state there was a bug bounty program and be willing to explain its general contours and requirements.\n\nThank you for helping keep MetaMask and our users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-06-09T13:26:25.722Z"}]