[{"id":3776083,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, public disclosure of your findings via a blog post, social media, or any other type of medium is not allowed.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout.\n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\nPlease note that no MongoDB employees and contractors may submit vulnerabilities via HackerOne, and are ineligible for bounties. Please report any findings to the Product Security Team. \n\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":"2026-06-16T21:20:37.281Z"},{"id":3776082,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, public disclosure of your findings via a blog post, social media, or any other type of medium is not allowed.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. Authenticated resource exhaustion (OOM) are considered as \"Low\" severity findings.\n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\nPlease note that no MongoDB employees and contractors may submit vulnerabilities via HackerOne, and are ineligible for bounties. Please report any findings to the Product Security Team. \n\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":"2026-06-16T21:16:55.737Z"},{"id":3772725,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, public disclosure of your findings via a blog post, social media, or any other type of medium is not allowed.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\nPlease note that no MongoDB employees and contractors may submit vulnerabilities via HackerOne, and are ineligible for bounties. Please report any findings to the Product Security Team. \n\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":"2026-04-16T16:52:59.272Z"},{"id":3771826,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, public disclosure of your findings via a blog post, social media, or any other type of medium is not allowed.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\n\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":"2026-03-27T22:04:22.714Z"},{"id":3769780,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, public disclosure of your findings via a blog post, social media, or any other type of medium is not allowed.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\n\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":"2026-02-17T20:17:56.072Z"},{"id":3769695,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, public disclosure of your findings via a blog post or any other type of medium is not allowed.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\n\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":"2026-02-13T19:06:02.198Z"},{"id":3765072,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\n\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":"2025-10-23T18:46:42.055Z"},{"id":3762045,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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":"2025-08-28T17:59:20.127Z"},{"id":3759606,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **few MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Test/Demo credentials that intentionally exposed for specific use-cases\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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":"2025-07-21T18:14:41.859Z"},{"id":3756623,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **few MongoDB Shipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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":"2025-05-30T14:40:26.469Z"},{"id":3755900,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , **MongoDB Free Tier Atlas** and a **few MongoDB Sipped Products** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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":"2025-05-19T14:21:47.242Z"},{"id":3755899,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is **MongoDB Owned Domains** , MongoDB Free Tier Atlas and a few MongoDB Sipped Products with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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":"2025-05-19T14:17:08.472Z"},{"id":3701745,"new_policy":"{F1894478}\n\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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-08T08:20:54.730Z"},{"id":3700573,"new_policy":"{F1894478}\n\nHello, \n\nThanks for participating in our program. \n\nWe have received some great issues since we launched and appreciate the time and effort taken to find vulnerabilities and report them to us. \n\nIn preparation for new scopes and in order to appropriately manage the influx of reported issues we’re temporarily disabling submissions for our program. This will ensure that we can stay on top of the existing reports. While this page has been disabled, we will still keep our VDP running which is open to all submissions.\n\nThanks in advance for your understanding; when submissions are re-enabled, we’ll update the policy page to let you know.\n\nThanks,\n\nMongoDB Security Team\n\n----------------------------------\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n   * Information Disclosure on /secure/QueryComponent!Default.jspa endpoint\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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-08-29T08:59:09.964Z"},{"id":3680876,"new_policy":"{F1894478}\n\nHello, \n\nThanks for participating in our program. \n\nWe have received some great issues since we launched and appreciate the time and effort taken to find vulnerabilities and report them to us. \n\nIn preparation for new scopes and in order to appropriately manage the influx of reported issues we’re temporarily disabling submissions for our program. This will ensure that we can stay on top of the existing reports. While this page has been disabled, we will still keep our VDP running which is open to all submissions.\n\nThanks in advance for your understanding; when submissions are re-enabled, we’ll update the policy page to let you know.\n\nThanks,\n\nMongoDB Security Team\n\n----------------------------------\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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-12-09T14:26:13.660Z"},{"id":3679307,"new_policy":"{F1894478}\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be rewarded at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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-11-01T17:13:07.040Z"},{"id":3679306,"new_policy":"{F1894478}\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\nPLEASE NOTE eligible subdomain takeover reports will be reward at a percentage of the severity reward payout. \n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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-11-01T17:12:05.427Z"},{"id":3678868,"new_policy":"{F1894478}\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n* Any reports on our forums page(https://www.mongodb.com/community/forums/*)\n\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-21T10:24:46.306Z"},{"id":3676977,"new_policy":"{F1894478}\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Public Jira Projects - We have multiple Jira Projects that have been intentionally made public. Please only submit jira related reports that involves sensitive information disclosure.\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n\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-09-02T13:42:45.440Z"},{"id":3676904,"new_policy":"{F1894478}\n\nAt MongoDB, our mission is to empower investors to create, transform, and disrupt industries by unleashing the power of software and data. We are a leading modern, general purpose database platform and our open-source model provides transparency to our users. As such we take security seriously and if you believe you have discovered a security vulnerability in one of our products, we encourage you to disclose it to us as quickly as possible. We look forward to working with the security community to find vulnerabilities in order to keep our business and customers safe.\n\n# Table of Contents\n* Rules of Engagement\n   * Program Rules\n   * Disclosure Policy\n   * Safe Harbor\n  * Response Targets\n* Eligibility\n   * Testing\n   * Program Scope\n   * Out of Scope and Non Qualifying Reports\n    * *Do Not Report*\n\n\n# Rules of Engagement\nThis program should be a collaborative effort and we would ask that you allow time for our teams to process reports through to resolution. By participating in this program, you will be agreeing to the [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct), [Finder’s T\u0026C](https://www.hackerone.com/terms/finder), [MongoDB’s Privacy Policy](https://www.mongodb.com/legal/privacy-policy) and the Program Rules outlined below.\n\n\n## Program Rules\nPlease provide detailed reports with reproducible steps. Eligibility is discussed further in the following section however, **if the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.**\n* Without explicit and written consent, researchers may not attempt to perform any activity that will cause disruption to accounts that they do not own or already have access to.\n* Submitted reports must be one vulnerability per report, unless multiple vulnerabilities must be demonstrated to prove impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n   * This may apply to reports of similar nature i.e. same vulnerability but different proof of concept provided.\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Avoid privacy violations, destruction of data, and interruption or degradation of our service. \n\n\n## Disclosure Policy\nPlease follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines). In addition, do not disclose reports publicly until they have been resolved and coordinated disclosure has been agreed upon.\n\n\n## Safe Harbor\nMongoDB will not initiate a lawsuit or law enforcement investigation against a researcher in response to reporting a vulnerability if the researcher fully complies with this policy. Please understand that if your security research involves the networks, systems, information, applications, products, or services of another party (which is not us), that third party may determine whether to pursue legal action. \n\n**You are expected, as always, to comply with all applicable laws and regulations.**\n\n\n## Response Targets\nMongoDB 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 | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 14 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\nThank you for helping keep MongoDB and our users safe!\n\n\n# Eligibility\nWe will attempt to provide as much information as possible in the sections below in order to increase the chances of researchers submitting eligible reports. Therefore, we request you to go through the scoping section to ensure that reports are eligible for bounty. Only reports affecting assets listed explicitly in the ‘In Scope’ section are eligible for bounty reward.\n\n\n## Testing\nOur security team and tooling are constantly monitoring for attacks on our systems, therefore, a lot of traffic may be coming in and out. In order for our team to quickly identify testing by HackerOne researcher and not a malicious attacker, we ask that you provide an identifier in your testing process. Some examples include:\n* Suggested header to requests: “X-HackerOne-Research: [H1 username]”\n   * This could further help us identify your eligibility for bounty\n* Provide your testing IP when applicable in your reports. \n   * This could further help us identify your eligibility for bounty\n   * We will only retain your IP for investigative purposes of the submitted report\n* Avoid using automatic scanners when possible as these usually bombard our systems and we are usually not able to provide eligible reports in the past.\n* Always refrain from causing damage or disruption. Researchers can provide proof of concept up to this point and can request for MongoDB to provide confirmation for testing or we can confirm the vulnerability on our end first.\n\nP.S. Please do not hesitate to contact us via the HackerOne support channels.  \n**Attacks on accounts you do not own or have permissions to is strictly prohibited.**\n\n\n## Program Scope\nThe scope of this program is solely **MongoDB Owned Domains** with exceptions (please refer to the Out of Scope section). For a list of our scopes please refer below for a detailed list. When submitting a report, if the asset involved is not explicitly called out in scope, it will not be eligible for bounty.\n\n\n## Out of Scope and Non Qualifying Reports\nAs we continuously mature this program, we identify issues that are not valuable to the overall security of our domains. A rule of thumb is, non-security related or outdated best practices are generally not accepted. The following report types are also not accepted:\n* **Please note that all evergreen endpoints (including staging) are out of scope of this program and not eligible for bounty**\n* Subdomain takeovers for out of scope domains\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* 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* Artifactory issues\n* Known false positives:\n   * Content injection\n   * Error Message\n   * SCRAM-SHA1 authentication mechanism's login credentials disclosure\n   * SPF record configuration on 10gen.com or mongodb.com\n   * Server version disclosure\n* Accepted Risks: \n   * CSRF with minimal security implications i.e. CSRF on logout\n   * CSRF Token Leak\n   * JavaScript error\n* Good practice settings: \n   * CSP uses unsafe-inline, Missing Certificate Authority, Authorization Rule, Missing HSTS, Missing security headers, No X-Frame Options Header on developer.mongodb.com, Open redirect using Host header. \n   * No X-Frame Options Header on developer.mongodb.com \n\n### Do Not Report\nThe following is strictly not eligible for bounty and we will not accept any reports regarding the following:\n* Evergreen endpoints (including staging) \n* Any MongoDB Products i.e. Atlas\n* Any reports on our artifactory instance\n\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-09-01T09:04:29.405Z"}]