[{"id":3770292,"new_policy":"# Bumble \u0026 Badoo Vulnerability Disclosure Program\n\nWe reward security researchers for reporting **impactful vulnerabilities** affecting Bumble, Badoo, BFF (including Geneva), and related products.\n\nVulnerabilities are ranked based on **real-world impact**. Final severity and rewards are determined by the Bumble security team. We do not rely on rigid scoring systems—the more damage a vulnerability can realistically cause, the higher its severity.\n\n\u003e We value high-quality, well-researched reports with clear proof of impact.  Avoid duplicate submissions, copy-pasted reports, or reports without a working PoC.  Respecting each other’s time helps us respond faster and reward impactful findings.\n\n**High-interest assets**\n- Bumble mobile application (iOS \u0026 Android)\n- Bumble For Friends (BFF) mobile application (iOS \u0026 Android)\n- bumble.com (including mobile web)\n- www.bumble.com\n- bma.bumble.com  \n\nFor the full scope, please refer to the assets list.\n\n\u003e Note: Geneva Web is a limited interface. Most impactful findings are in the **mobile applications**. If you cant access the staging applications listed in the programme due capacity being reached, please submit an informational ticket to the program asking for access to the latest APK. \n\nGeneva staging credentials (OTP `000000` for both):\n* Member: `+1 880 999 0001`\n* Owner: `+1 880 999 0009`\n\n## Out-of-scope / non-qualifying reports\n\n**Information disclosure \u0026 inference issues**\nWhen reporting inferred information (e.g. “Has this specific user liked me?”), consider:\n  - **Scalability**\n    - Can the technique be automated at scale?\n    - Does it rely on predictable identifiers?\n    - If it only works in isolated or manual cases, it is unlikely to qualify\n  - **Equivalent in-app behaviour**\n    - Could the same information be obtained through intended app functionality (e.g. swiping and matching)?\n    - If yes, the report likely duplicates expected behaviour rather than exposing sensitive data\n\nReports that do not demonstrate scalable access to information not otherwise obtainable via normal app use are typically closed as Informative or Not Applicable\n\n## How severity is assessed (examples)\nThese examples hopefully clarify some of the thinking when assigning risk.\n\n| Severity | Example impact |\n|---------|----------------|\n| Low | HTML injection or XSS that only affects page output with no meaningful user impact |\n| Low | Cosmetic UI manipulation without data access or state change |\n| Medium | SQL injection or logic flaw that alters application behaviour but does not expose user data |\n| Medium | Limited unauthorised actions affecting a single account without escalation |\n| High | Unauthorised access to sensitive user data |\n| High | Modification of sensitive profile or account data |\n| Critical | Account takeover |\n| Critical | Scalable abuse impacting multiple users or systems |\n\n\n## Personal data handling\nLimit access to personal data strictly to what is necessary; All applicable data protection laws must be followed.\n- Use personal data only for investigation purposes\n- Securely delete any personal data after testing\n- Confirm deletion when submitting your report  \n\n\n\n### Public disclosure\nPublic disclosure is generally not permitted; Exceptions may be granted on a case-by-case basis—please ask before publishing \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":["{\"category\":\"Low-impact or non-exploitable findings\",\"details\":\"Theoretical issues without a working proof of concept; reports generated solely by automated scanners; missing security headers or cookie flags without demonstrated exploitability or user impact; non-implemented “best practices” (e.g. missing HSTS, soft token invalidation rules)\"}","{\"category\":\"Expected or accepted behaviour\",\"details\":\"Clickjacking on static pages with no meaningful user interaction; one-click authorisation from emails or login CSRF via these links; captcha bypass using OCR; behaviour equivalent to intended in-app functionality\"}","{\"category\":\"Environmental or third-party issues\",\"details\":\"Issues in third-party services or applications; mail infrastructure configuration (SPF, DMARC, etc.); issues that require a rooted or jailbroken device and are not exploitable on stock devices\"}","{\"category\":\"Abuse patterns without real impact\",\"details\":\"Data enumeration without sensitive data exposure, account compromise, or realistic abuse at scale; generic brute-force or rate-limiting issues (bypasses of existing controls should be reported)\"}","{\"category\":\"Dangling Domains / Domain Takeover\",\"details\":\"Although these issues are accepted, valid findings will receive a fixed bounty of $100.\"}","{\"category\":\"Prohibited testing\",\"details\":\"Social engineering or phishing attacks; denial-of-service or traffic flooding; any activity that risks user privacy or service stability\"}"],"timestamp":"2026-02-26T16:08:58.482Z"},{"id":3769390,"new_policy":"# Bumble \u0026 Badoo Vulnerability Disclosure Program\n\nWe reward security researchers for reporting **impactful vulnerabilities** affecting Bumble, Badoo, BFF (including Geneva), and related products.\n\nVulnerabilities are ranked based on **real-world impact**. Final severity and rewards are determined by the Bumble security team. We do not rely on rigid scoring systems—the more damage a vulnerability can realistically cause, the higher its severity.\n\n\u003e We value high-quality, well-researched reports with clear proof of impact.  Avoid duplicate submissions, copy-pasted reports, or reports without a working PoC.  Respecting each other’s time helps us respond faster and reward impactful findings.\n\n**High-interest assets**\n- Bumble mobile application (iOS \u0026 Android)\n- Bumble For Friends (BFF) mobile application (iOS \u0026 Android)\n- bumble.com (including mobile web)\n- www.bumble.com\n- bma.bumble.com  \n\nFor the full scope, please refer to the assets list.\n\n\u003e Note: Geneva Web is a limited interface. Most impactful findings are in the **mobile applications**. If you cant access the staging applications listed in the programme due capacity being reached, please submit an informational ticket to the program asking for access to the latest APK. \n\nGeneva staging credentials (OTP `000000` for both):\n* Member: `+1 880 999 0001`\n* Owner: `+1 880 999 0009`\n\n## Out-of-scope / non-qualifying reports\nPlease review before starting the hunt:\n\n| Category | Examples |\n|--------|----------|\n| **Low-impact or non-exploitable findings** | Theoretical issues without a working proof of concept; reports generated solely by automated scanners; missing security headers or cookie flags without demonstrated exploitability or user impact; non-implemented “best practices” (e.g. missing HSTS, soft token invalidation rules) |\n| **Expected or accepted behaviour** | Clickjacking on static pages with no meaningful user interaction; one-click authorisation from emails or login CSRF via these links; captcha bypass using OCR; behaviour equivalent to intended in-app functionality |\n| **Environmental or third-party issues** | Issues in third-party services or applications; mail infrastructure configuration (SPF, DMARC, etc.); issues that require a rooted or jailbroken device and are not exploitable on stock devices |\n| **Abuse patterns without real impact** | Data enumeration without sensitive data exposure, account compromise, or realistic abuse at scale; generic brute-force or rate-limiting issues (bypasses of existing controls should be reported) |\n| **Dangling Domains / Domain Takeover**|Although these issues are accepted, valid findings will receive a fixed bounty of $100.|\n| **Prohibited testing** | Social engineering or phishing attacks; denial-of-service or traffic flooding; any activity that risks user privacy or service stability |\n\n**Information disclosure \u0026 inference issues**\nWhen reporting inferred information (e.g. “Has this specific user liked me?”), consider:\n  - **Scalability**\n    - Can the technique be automated at scale?\n    - Does it rely on predictable identifiers?\n    - If it only works in isolated or manual cases, it is unlikely to qualify\n  - **Equivalent in-app behaviour**\n    - Could the same information be obtained through intended app functionality (e.g. swiping and matching)?\n    - If yes, the report likely duplicates expected behaviour rather than exposing sensitive data\n\nReports that do not demonstrate scalable access to information not otherwise obtainable via normal app use are typically closed as Informative or Not Applicable\n\n## How severity is assessed (examples)\nThese examples hopefully clarify some of the thinking when assigning risk.\n\n| Severity | Example impact |\n|---------|----------------|\n| Low | HTML injection or XSS that only affects page output with no meaningful user impact |\n| Low | Cosmetic UI manipulation without data access or state change |\n| Medium | SQL injection or logic flaw that alters application behaviour but does not expose user data |\n| Medium | Limited unauthorised actions affecting a single account without escalation |\n| High | Unauthorised access to sensitive user data |\n| High | Modification of sensitive profile or account data |\n| Critical | Account takeover |\n| Critical | Scalable abuse impacting multiple users or systems |\n\n\n## Personal data handling\nLimit access to personal data strictly to what is necessary; All applicable data protection laws must be followed.\n- Use personal data only for investigation purposes\n- Securely delete any personal data after testing\n- Confirm deletion when submitting your report  \n\n\n\n### Public disclosure\nPublic disclosure is generally not permitted; Exceptions may be granted on a case-by-case basis—please ask before publishing \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-09T09:26:52.462Z"},{"id":3769193,"new_policy":"# Bumble \u0026 Badoo Vulnerability Disclosure Program\n\nWe reward security researchers for reporting **impactful vulnerabilities** affecting Bumble, Badoo, BFF (including Geneva), and related products.\n\nVulnerabilities are ranked based on **real-world impact**. Final severity and rewards are determined by the Bumble security team. We do not rely on rigid scoring systems—the more damage a vulnerability can realistically cause, the higher its severity.\n\n\u003e We value high-quality, well-researched reports with clear proof of impact.  Avoid duplicate submissions, copy-pasted reports, or reports without a working PoC.  Respecting each other’s time helps us respond faster and reward impactful findings.\n\n**High-interest assets**\n- Bumble mobile application (iOS \u0026 Android)\n- Bumble For Friends (BFF) mobile application (iOS \u0026 Android)\n- bumble.com (including mobile web)\n- www.bumble.com\n- bma.bumble.com  \n\nFor the full scope, please refer to the assets list.\n\n\u003e Note: Geneva Web is a limited interface. Most impactful findings are in the **mobile applications**. If you cant access the staging applications listed in the programme due capacity being reached, please do contact us!\n\n## Out-of-scope / non-qualifying reports\nPlease review before starting the hunt:\n\n| Category | Examples |\n|--------|----------|\n| **Low-impact or non-exploitable findings** | Theoretical issues without a working proof of concept; reports generated solely by automated scanners; missing security headers or cookie flags without demonstrated exploitability or user impact; non-implemented “best practices” (e.g. missing HSTS, soft token invalidation rules) |\n| **Expected or accepted behaviour** | Clickjacking on static pages with no meaningful user interaction; one-click authorisation from emails or login CSRF via these links; captcha bypass using OCR; behaviour equivalent to intended in-app functionality |\n| **Environmental or third-party issues** | Issues in third-party services or applications; mail infrastructure configuration (SPF, DMARC, etc.); issues that require a rooted or jailbroken device and are not exploitable on stock devices |\n| **Abuse patterns without real impact** | Data enumeration without sensitive data exposure, account compromise, or realistic abuse at scale; generic brute-force or rate-limiting issues (bypasses of existing controls should be reported) |\n| **Dangling Domains / Domain Takeover**|Although these issues are accepted, valid findings will receive a fixed bounty of $100.|\n| **Prohibited testing** | Social engineering or phishing attacks; denial-of-service or traffic flooding; any activity that risks user privacy or service stability |\n\n**Information disclosure \u0026 inference issues**\nWhen reporting inferred information (e.g. “Has this specific user liked me?”), consider:\n  - **Scalability**\n    - Can the technique be automated at scale?\n    - Does it rely on predictable identifiers?\n    - If it only works in isolated or manual cases, it is unlikely to qualify\n  - **Equivalent in-app behaviour**\n    - Could the same information be obtained through intended app functionality (e.g. swiping and matching)?\n    - If yes, the report likely duplicates expected behaviour rather than exposing sensitive data\n\nReports that do not demonstrate scalable access to information not otherwise obtainable via normal app use are typically closed as Informative or Not Applicable\n\n## How severity is assessed (examples)\nThese examples hopefully clarify some of the thinking when assigning risk.\n\n| Severity | Example impact |\n|---------|----------------|\n| Low | HTML injection or XSS that only affects page output with no meaningful user impact |\n| Low | Cosmetic UI manipulation without data access or state change |\n| Medium | SQL injection or logic flaw that alters application behaviour but does not expose user data |\n| Medium | Limited unauthorised actions affecting a single account without escalation |\n| High | Unauthorised access to sensitive user data |\n| High | Modification of sensitive profile or account data |\n| Critical | Account takeover |\n| Critical | Scalable abuse impacting multiple users or systems |\n\n\n## Personal data handling\nLimit access to personal data strictly to what is necessary; All applicable data protection laws must be followed.\n- Use personal data only for investigation purposes\n- Securely delete any personal data after testing\n- Confirm deletion when submitting your report  \n\n\n\n### Public disclosure\nPublic disclosure is generally not permitted; Exceptions may be granted on a case-by-case basis—please ask before publishing \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-03T18:16:15.075Z"},{"id":3768883,"new_policy":"# Bumble \u0026 Badoo Vulnerability Disclosure Program\n\nWe reward security researchers for reporting **impactful vulnerabilities** affecting Bumble, Badoo, BFF (including Geneva), and related products.\n\nVulnerabilities are ranked based on **real-world impact**. Final severity and rewards are determined by the Bumble security team. We do not rely on rigid scoring systems—the more damage a vulnerability can realistically cause, the higher its severity.\n\n\u003e We value high-quality, well-researched reports with clear proof of impact.  Avoid duplicate submissions, copy-pasted reports, or reports without a working PoC.  Respecting each other’s time helps us respond faster and reward impactful findings.\n\n**High-interest assets**\n- Bumble mobile application (iOS \u0026 Android)\n- Bumble For Friends (BFF) mobile application (iOS \u0026 Android)\n- bumble.com (including mobile web)\n- www.bumble.com\n- bma.bumble.com  \n\nFor the full scope, please refer to the assets list.\n\n**Test accounts (BFF / Geneva)**\n- Phone numbers: `+1 880 999 0000` → `+1 880 999 0009`\n- Login code: `000000` (always)\n- These test accounts work for Geneva assets as well  \n\n\u003e Note: Geneva Web is a limited interface. Most impactful findings are in the **mobile applications**. If you cant access the staging applications listed in the programme due capacity being reached, please do contact us!\n\n## Out-of-scope / non-qualifying reports\nPlease review before starting the hunt:\n\n| Category | Examples |\n|--------|----------|\n| **Low-impact or non-exploitable findings** | Theoretical issues without a working proof of concept; reports generated solely by automated scanners; missing security headers or cookie flags without demonstrated exploitability or user impact; non-implemented “best practices” (e.g. missing HSTS, soft token invalidation rules) |\n| **Expected or accepted behaviour** | Clickjacking on static pages with no meaningful user interaction; one-click authorisation from emails or login CSRF via these links; captcha bypass using OCR; behaviour equivalent to intended in-app functionality |\n| **Environmental or third-party issues** | Issues in third-party services or applications; mail infrastructure configuration (SPF, DMARC, etc.); issues that require a rooted or jailbroken device and are not exploitable on stock devices |\n| **Abuse patterns without real impact** | Data enumeration without sensitive data exposure, account compromise, or realistic abuse at scale; generic brute-force or rate-limiting issues (bypasses of existing controls should be reported) |\n| **Dangling Domains / Domain Takeover**|Although these issues are accepted, valid findings will receive a fixed bounty of $100.|\n| **Prohibited testing** | Social engineering or phishing attacks; denial-of-service or traffic flooding; any activity that risks user privacy or service stability |\n\n**Information disclosure \u0026 inference issues**\nWhen reporting inferred information (e.g. “Has this specific user liked me?”), consider:\n  - **Scalability**\n    - Can the technique be automated at scale?\n    - Does it rely on predictable identifiers?\n    - If it only works in isolated or manual cases, it is unlikely to qualify\n  - **Equivalent in-app behaviour**\n    - Could the same information be obtained through intended app functionality (e.g. swiping and matching)?\n    - If yes, the report likely duplicates expected behaviour rather than exposing sensitive data\n\nReports that do not demonstrate scalable access to information not otherwise obtainable via normal app use are typically closed as Informative or Not Applicable\n\n## How severity is assessed (examples)\nThese examples hopefully clarify some of the thinking when assigning risk.\n\n| Severity | Example impact |\n|---------|----------------|\n| Low | HTML injection or XSS that only affects page output with no meaningful user impact |\n| Low | Cosmetic UI manipulation without data access or state change |\n| Medium | SQL injection or logic flaw that alters application behaviour but does not expose user data |\n| Medium | Limited unauthorised actions affecting a single account without escalation |\n| High | Unauthorised access to sensitive user data |\n| High | Modification of sensitive profile or account data |\n| Critical | Account takeover |\n| Critical | Scalable abuse impacting multiple users or systems |\n\n\n## Personal data handling\nLimit access to personal data strictly to what is necessary; All applicable data protection laws must be followed.\n- Use personal data only for investigation purposes\n- Securely delete any personal data after testing\n- Confirm deletion when submitting your report  \n\n\n\n### Public disclosure\nPublic disclosure is generally not permitted; Exceptions may be granted on a case-by-case basis—please ask before publishing \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-01-28T13:23:06.347Z"},{"id":3768023,"new_policy":"# Bumble \u0026 Badoo Vulnerability Disclosure Program\n\nWe reward security researchers for reporting **impactful vulnerabilities** affecting Bumble, Badoo, BFF (including Geneva), and related products.\n\nVulnerabilities are ranked based on **real-world impact**. Final severity and rewards are determined by the Bumble security team. We do not rely on rigid scoring systems—the more damage a vulnerability can realistically cause, the higher its severity.\n\n\u003e We value high-quality, well-researched reports with clear proof of impact.  Avoid duplicate submissions, copy-pasted reports, or reports without a working PoC.  Respecting each other’s time helps us respond faster and reward impactful findings.\n\n**High-interest assets**\n- Bumble mobile application (iOS \u0026 Android)\n- Bumble For Friends (BFF) mobile application (iOS \u0026 Android)\n- bumble.com (including mobile web)\n- www.bumble.com\n- bma.bumble.com  \n\nFor the full scope, please refer to the assets list.\n\n**Test accounts (BFF / Geneva)**\n- Phone numbers: `+1 880 999 0000` → `+1 880 999 0009`\n- Login code: `000000` (always)\n- These test accounts work for Geneva assets as well  \n\n\u003e Note: Geneva Web is a limited interface. Most impactful findings are in the **mobile applications**. If you cant access the staging applications listed in the programme due capacity being reached, please do contact us!\n\n## Out-of-scope / non-qualifying reports\nPlease review before starting the hunt:\n\n| Category | Examples |\n|--------|----------|\n| **Low-impact or non-exploitable findings** | Theoretical issues without a working proof of concept; reports generated solely by automated scanners; missing security headers or cookie flags without demonstrated exploitability or user impact; non-implemented “best practices” (e.g. missing HSTS, soft token invalidation rules) |\n| **Expected or accepted behaviour** | Clickjacking on static pages with no meaningful user interaction; one-click authorisation from emails or login CSRF via these links; captcha bypass using OCR; behaviour equivalent to intended in-app functionality |\n| **Environmental or third-party issues** | Issues in third-party services or applications; mail infrastructure configuration (SPF, DMARC, etc.); issues that require a rooted or jailbroken device and are not exploitable on stock devices |\n| **Abuse patterns without real impact** | Data enumeration without sensitive data exposure, account compromise, or realistic abuse at scale; generic brute-force or rate-limiting issues (bypasses of existing controls should be reported) |\n| **Prohibited testing** | Social engineering or phishing attacks; denial-of-service or traffic flooding; any activity that risks user privacy or service stability |\n\n**Information disclosure \u0026 inference issues**\nWhen reporting inferred information (e.g. “Has this specific user liked me?”), consider:\n  - **Scalability**\n    - Can the technique be automated at scale?\n    - Does it rely on predictable identifiers?\n    - If it only works in isolated or manual cases, it is unlikely to qualify\n  - **Equivalent in-app behaviour**\n    - Could the same information be obtained through intended app functionality (e.g. swiping and matching)?\n    - If yes, the report likely duplicates expected behaviour rather than exposing sensitive data\n\nReports that do not demonstrate scalable access to information not otherwise obtainable via normal app use are typically closed as Informative or Not Applicable\n\n## How severity is assessed (examples)\nThese examples hopefully clarify some of the thinking when assigning risk.\n\n| Severity | Example impact |\n|---------|----------------|\n| Low | HTML injection or XSS that only affects page output with no meaningful user impact |\n| Low | Cosmetic UI manipulation without data access or state change |\n| Medium | SQL injection or logic flaw that alters application behaviour but does not expose user data |\n| Medium | Limited unauthorised actions affecting a single account without escalation |\n| High | Unauthorised access to sensitive user data |\n| High | Modification of sensitive profile or account data |\n| Critical | Account takeover |\n| Critical | Scalable abuse impacting multiple users or systems |\n\n\n## Personal data handling\nLimit access to personal data strictly to what is necessary; All applicable data protection laws must be followed.\n- Use personal data only for investigation purposes\n- Securely delete any personal data after testing\n- Confirm deletion when submitting your report  \n\n\n\n### Public disclosure\nPublic disclosure is generally not permitted; Exceptions may be granted on a case-by-case basis—please ask before publishing \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-01-06T16:09:14.688Z"},{"id":3768022,"new_policy":"# Bumble \u0026 Badoo Vulnerability Disclosure Program\n\nWe reward security researchers for reporting **impactful vulnerabilities** affecting Bumble, Badoo, BFF (including Geneva), and related products.\n\nVulnerabilities are ranked based on **real-world impact**. Final severity and rewards are determined by the Bumble security team. We do not rely on rigid scoring systems—the more damage a vulnerability can realistically cause, the higher its severity.\n\n\u003e We value high-quality, well-researched reports with clear proof of impact.  Avoid duplicate submissions, copy-pasted reports, or reports without a working PoC.  Respecting each other’s time helps us respond faster and reward impactful findings.\n\n**High-interest assets**\n- Bumble mobile application (iOS \u0026 Android)\n- Bumble For Friends (BFF) mobile application (iOS \u0026 Android)\n- bumble.com (including mobile web)\n- www.bumble.com\n- bma.bumble.com  \n\nFor the full scope, please refer to the assets list.\n\n**Test accounts (BFF / Geneva)**\n- Phone numbers: `+1 880 999 0000` → `+1 880 999 0009`\n- Login code: `000000` (always)\n- These test accounts work for Geneva assets as well  \n\n\u003e Note: Geneva Web is a limited interface. Most impactful findings are in the **mobile applications**.\n\n## Out-of-scope / non-qualifying reports\nPlease review before starting the hunt:\n\n| Category | Examples |\n|--------|----------|\n| **Low-impact or non-exploitable findings** | Theoretical issues without a working proof of concept; reports generated solely by automated scanners; missing security headers or cookie flags without demonstrated exploitability or user impact; non-implemented “best practices” (e.g. missing HSTS, soft token invalidation rules) |\n| **Expected or accepted behaviour** | Clickjacking on static pages with no meaningful user interaction; one-click authorisation from emails or login CSRF via these links; captcha bypass using OCR; behaviour equivalent to intended in-app functionality |\n| **Environmental or third-party issues** | Issues in third-party services or applications; mail infrastructure configuration (SPF, DMARC, etc.); issues that require a rooted or jailbroken device and are not exploitable on stock devices |\n| **Abuse patterns without real impact** | Data enumeration without sensitive data exposure, account compromise, or realistic abuse at scale; generic brute-force or rate-limiting issues (bypasses of existing controls should be reported) |\n| **Prohibited testing** | Social engineering or phishing attacks; denial-of-service or traffic flooding; any activity that risks user privacy or service stability |\n\n**Information disclosure \u0026 inference issues**\nWhen reporting inferred information (e.g. “Has this specific user liked me?”), consider:\n  - **Scalability**\n    - Can the technique be automated at scale?\n    - Does it rely on predictable identifiers?\n    - If it only works in isolated or manual cases, it is unlikely to qualify\n  - **Equivalent in-app behaviour**\n    - Could the same information be obtained through intended app functionality (e.g. swiping and matching)?\n    - If yes, the report likely duplicates expected behaviour rather than exposing sensitive data\n\nReports that do not demonstrate scalable access to information not otherwise obtainable via normal app use are typically closed as Informative or Not Applicable\n\n## How severity is assessed (examples)\nThese examples hopefully clarify some of the thinking when assigning risk.\n\n| Severity | Example impact |\n|---------|----------------|\n| Low | HTML injection or XSS that only affects page output with no meaningful user impact |\n| Low | Cosmetic UI manipulation without data access or state change |\n| Medium | SQL injection or logic flaw that alters application behaviour but does not expose user data |\n| Medium | Limited unauthorised actions affecting a single account without escalation |\n| High | Unauthorised access to sensitive user data |\n| High | Modification of sensitive profile or account data |\n| Critical | Account takeover |\n| Critical | Scalable abuse impacting multiple users or systems |\n\n\n## Personal data handling\nLimit access to personal data strictly to what is necessary; All applicable data protection laws must be followed.\n- Use personal data only for investigation purposes\n- Securely delete any personal data after testing\n- Confirm deletion when submitting your report  \n\n\n\n### Public disclosure\nPublic disclosure is generally not permitted; Exceptions may be granted on a case-by-case basis—please ask before publishing \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-01-06T16:06:41.010Z"},{"id":3751743,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, BFF, Badoo and Geneva products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n- Geneva web and mobile applications both android and IOS\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n**Test Accounts for Geneva**\nPlease use the below test accounts for Geneva testing:-\nUse phone numbers in the range of: +1 880 999 000  \u003e +1 880 999 0000 \nlogin code will always be 000000 for these numbers\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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-03-14T11:08:35.551Z"},{"id":3751742,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, BFF, Badoo and Geneva products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n- Geneva web and mobile applications both android and IOS\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n**Test Accounts for Geneva**\nPlease use the below test accounts for Geneva testing:-\nUse phone numbers in the range of: +1 880 999 0000  \u0026 +1 880 999 000\nlogin code will always be 000000 for these numbers\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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-03-14T10:51:02.791Z"},{"id":3751669,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, BFF, Badoo and Geneva products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n- Geneva web and mobile applications both android and IOS\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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-03-13T12:05:50.916Z"},{"id":3751668,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, BFF, and Badoo roducts. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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-03-13T11:48:36.897Z"},{"id":3751667,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Official products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, Fruitz, and Official products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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-03-13T11:47:42.367Z"},{"id":3749958,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Official products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Official:\n- Official mobile applications (App Store, Google Play, Web app)\n\n## Important note!\n- While testing the _Official_ apps, include a custom HTTP header for all your HTTP traffic. \nX-Bug-Bounty:hackerone-\u003cyour__h1__username\u003e\nE.g.: X-Bug-Bounty:hackerone-warrior_bee\n\n- When creating an account on the _Official_ app, please use your HackerOne Email Alias (e.g., username@wearehackerone.com), so that we can identify you.\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, Fruitz, and Official products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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-02-11T15:25:57.841Z"},{"id":3749957,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Official products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Official:\n- Official mobile applications (App Store, Google Play, Web app)\n\nImportant note!\n- While testing Official apps, include a custom HTTP header for all your HTTP traffic. \nX-Bug-Bounty:hackerone-\u003cyour_h1_username\u003e\nE.g.: X-Bug-Bounty:hackerone-warrior_bee\n\n- When creating an account on Official app, please use your HackerOne Email Alias (e.g., username@wearehackerone.com), so that we can identify you.\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, Fruitz, and Official products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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-02-11T15:23:05.735Z"},{"id":3731903,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Official products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n**In scope**:\n Vulnerabilities will be evaluated based on impact to Bumble systems and certain assets may be of higher impact.\n\n We currently consider the following assets to be of greater interest:\n\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Official:\n- Official mobile applications (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags, missing HttpOnly or Secure flags on cookies.\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration.\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n- Any activity that could lead to the disruption of our service (DoS) or a violation of the privacy of any user, employee or contractor of Bumble/Badoo or any of its affiliates or business partners.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, Fruitz, and Official products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2024-07-10T10:42:44.992Z"},{"id":3713997,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Official products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\n# Where to look for vulnerabilities for Badoo:\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Official:\n- Official mobile applications (App Store, Google Play, Web app)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, Fruitz, and Official products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2024-03-12T11:01:38.917Z"},{"id":3713470,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Official products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\n# Where to look for vulnerabilities for Badoo:\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Official:\n- Official mobile applications (App Store, Google Play, Web app)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, Fruitz, and Official products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2024-03-01T09:29:31.016Z"},{"id":3699093,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, Zodia, and Official products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n- Bumble For Friends mobile application (App Store, Google Play)\n\n# Where to look for vulnerabilities for Badoo:\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Zodia:\n- Zodia mobile applications (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Official:\n- Official mobile applications (App Store, Google Play, Web app)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, Fruitz, and Official products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-07-27T18:38:01.064Z"},{"id":3687290,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, Fruitz, and Zodia products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\n# Where to look for vulnerabilities for Zodia:\n- Zodia mobile applications (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, and Fruitz products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-05-08T08:16:50.895Z"},{"id":3687286,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, and Fruitz products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-05-08T07:53:29.661Z"},{"id":3684111,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- blendr.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data (as defined by applicable data protection laws) in your discovery. In the event that this is not possible, and you do process personal data coming from Bumble, Badoo, and Fruitz products, you will abide by applicable data protection laws. As such, you must strictly limit the processing of such personal data to the purposes of the investigation. You must promptly and securely dispose of any personal data you may have processed and will confirm in writing, when reaching out to us, that you have done this.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-02-27T08:57:51.299Z"},{"id":3684044,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- blendr.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal information in your discovery. In the event that this is not possible and you do access personal information, you will abide by applicable data protection laws, and where applicable shall act as an independent data controller. As such, you must strictly limit data usage for the purposes of the investigation. You must promptly and securely dispose of any personal information you may have collected and will confirm, when reaching out to us, that you have securely deleted the personal information you may have accessed in the context of your discovery.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-02-24T15:43:35.619Z"},{"id":3684027,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- blendr.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data in your discovery. In the event that is not possible and you do access personal data, you will abide by applicable data protection laws and where applicable shall as as independent controller. As such, you need to strictly limit it to use for purposes of the investigation. You should promptly dispose of any personal data you may have collected and will confirm, when reaching out to us, that you have securely deleted the personal data you may have accessed in the context of your discovery.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-02-24T10:55:57.770Z"},{"id":3684026,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- blendr.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Personal Data \n\nYou should limit access to personal data in your discovery. In the event that is not possible and you do access personal data, you will abide by applicable data protection laws and where applicable shall as as independent controller. As such, you need to strictly limit it to use for purposes of the investigation. You should promptly dispose of any personal data you may have collected and will confirm, when reaching out to us, that you have securely deleted the personal data you may have accessed in the context of his discovery. \n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-02-24T10:55:26.821Z"},{"id":3683534,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- blendr.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play, Web app)\n\nFor more information please take a look into the assets list.\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that a static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such a vulnerability could receive a reward in the Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2023-02-13T11:40:51.380Z"},{"id":3673263,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- heyfiesta.com\n- blendr.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play)\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2022-06-23T21:57:50.213Z"},{"id":3669140,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble, Badoo, and Fruitz products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\n# Where to look for vulnerabilities for Fruitz:\n- Fruitz mobile application (App Store, Google Play)\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2022-04-05T13:43:40.303Z"},{"id":3660066,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (+mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com (+mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- chatdate.app\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-10-15T13:38:40.187Z"},{"id":3656749,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com\n- badoo.com (mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- hotornot.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-08-12T15:44:18.972Z"},{"id":3656748,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nWe are happy to announce that Badoo bug bounty program  will join with Bumble from 22nd February 2021. We hope it will be easier for you to report findings for both our products in one place. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- (www).bumble.com\n- bumble.com (mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com\n- badoo.com (mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- hotornot.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-08-12T15:43:51.421Z"},{"id":3656747,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nWe are happy to announce that Badoo bug bounty program  will join with Bumble from 22nd February 2021. We hope it will be easier for you to report findings for both our products in one place. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- www.bumble.com\n- bumble.com (mobile web version)\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com\n- badoo.com (mobile web version)\n- eu1.badoo.com\n- us1.badoo.com\n- corp.badoo.com\n- m.badoo.com\n- meu1.badoo.com\n- mus1.badoo.com\n- hotornot.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-08-12T15:42:11.468Z"},{"id":3648683,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nWe are happy to announce that Badoo bug bounty program  will join with Bumble from 22nd February 2021. We hope it will be easier for you to report findings for both our products in one place. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com,\n- eu1.badoo.com,\n- us1.badoo.com,\n- corp.badoo.com,\n- m.badoo.com,\n- meu1.badoo.com,\n- mus1.badoo.com,\n- hotornot.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a discovered vulnerability can cause, the more valuable it is to us, and the higher the category we will assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-02-12T12:53:57.627Z"},{"id":3648682,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nWe are happy to announce that Badoo bug bounty program  will join with Bumble from 22nd February 2021. We hope it will be easier for you to report findings for both our products in one place. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com,\n- eu1.badoo.com,\n- us1.badoo.com,\n- corp.badoo.com,\n- m.badoo.com,\n- meu1.badoo.com,\n- mus1.badoo.com,\n- hotornot.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-02-12T12:20:00.432Z"},{"id":3648679,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nWe are happy to announce that Badoo bug bounty program  will join with Bumble since 22nd February 2021. We hope it will be easier for you to report findings for both our products in one place. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com,\n- eu1.badoo.com,\n- us1.badoo.com,\n- corp.badoo.com,\n- m.badoo.com,\n- meu1.badoo.com,\n- mus1.badoo.com,\n- hotornot.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-02-12T11:03:31.534Z"},{"id":3648675,"new_policy":"# Bumble and Badoo vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities in Bumble and Badoo products. \n\nWe are happy to announce that Badoo bug bounty program  will join with Bumble since 22 February 2021. We hope it will be easier for you to report findings for both our products in one place. \n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities for Bumble:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n# Where to look for vulnerabilities for Badoo:\n\n- badoo.com,\n- eu1.badoo.com,\n- us1.badoo.com,\n- corp.badoo.com,\n- m.badoo.com,\n- meu1.badoo.com,\n- mus1.badoo.com,\n- hotornot.com\n- bma.badoo.com\n- badoocdn.com\n- translate.badoo.com\n- ccardseu1.badoo.com \n- ccardsus1.badoo.com\n- Badoo Mobile Applications (App Store, Google Play).\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise.\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (Low).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability could receive a reward in Medium category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to Critical category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to Critical.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-02-12T10:21:33.149Z"},{"id":3647771,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-01-15T10:44:53.497Z"},{"id":3647770,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£3000) to category 1 (£300), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-01-15T10:33:46.563Z"},{"id":3647769,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£3000) to category 1 (£300), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 3000\n- Category 4 - £ 2000\n- Category 3 - £ 1000\n- Category 2 - £ 600\n- Category 1 - £ 300\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2021-01-15T09:06:34.178Z"},{"id":3646515,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£3000) to category 1 (£300), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 3000\n- Category 4 - £ 2000\n- Category 3 - £ 1000\n- Category 2 - £ 600\n- Category 1 - £ 300\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2020-12-07T09:35:51.214Z"},{"id":3636925,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£1000) to category 1 (£100), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 1000\n- Category 4 - £ 600\n- Category 3 - £ 300\n- Category 2 - £ 200\n- Category 1 - £ 100\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2020-06-02T09:40:42.150Z"},{"id":3629499,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£1000) to category 1 (£100), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 1000\n- Category 4 - £ 600\n- Category 3 - £ 300\n- Category 2 - £ 200\n- Category 1 - £ 100\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration via registration or account recovery forms;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n- Brute-force and rate-limiting attacks. We are aware of some non-optimal implementations on our side and working on the fix.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2020-01-30T11:14:29.699Z"},{"id":3567187,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£1000) to category 1 (£100), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n- thebeehive.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 1000\n- Category 4 - £ 600\n- Category 3 - £ 300\n- Category 2 - £ 200\n- Category 1 - £ 100\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration via registration or account recovery forms;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2018-01-22T12:13:05.344Z"},{"id":3555381,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£1000) to category 1 (£100), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n- honey.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 1000\n- Category 4 - £ 600\n- Category 3 - £ 300\n- Category 2 - £ 200\n- Category 1 - £ 100\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration via registration or account recovery forms;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2017-06-09T09:48:57.099Z"},{"id":3555329,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£1000) to category 1 (£100), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 1000\n- Category 4 - £ 600\n- Category 3 - £ 300\n- Category 2 - £ 200\n- Category 1 - £ 100\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickjacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration via registration or account recovery forms;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2017-06-08T13:26:19.964Z"},{"id":3555328,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£1000) to category 1 (£100), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 1000\n- Category 4 - £ 600\n- Category 3 - £ 300\n- Category 2 - £ 200\n- Category 1 - £ 100\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- Clickhacking. We understand the OWASP explanation of this but don't think that static page with no user interaction can lead to security compromise. If you can \n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration via registration or account recovery forms;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2017-06-08T13:25:43.426Z"},{"id":3555305,"new_policy":"# Bumble vulnerability disclosure program\n\nWe pay for all newfound vulnerabilities.\n\nVulnerabilities will be ranked from category 5 (£1000) to category 1 (£100), depending on their severity. The Bumble jury determines the severity of the vulnerability.\n\n# Where to look for vulnerabilities:\n\n**In scope**:\n- www.bumble.com\n- bma.bumble.com\n- Bumble mobile application (App Store, Google Play)\n\n**Out of scope**:\n- blog.bumble.com\n- shop.bumble.com\n\n\n# Award categories\n\n- Category 5 - £ 1000\n- Category 4 - £ 600\n- Category 3 - £ 300\n- Category 2 - £ 200\n- Category 1 - £ 100\n\nWe don’t want to tie our categories to traditional systems of vulnerability assessment. The more damage a found vulnerability can cause, the more valuable it is to us and the higher the category we assign to it.\n\n# Non-qualifying vulnerabilities\n\n- “Theoretical” vulnerabilities without any proof or demonstration of the real presence of the vulnerability\n- Vulnerabilities requiring physical access to a user’s browser, or a smartphone, or email account, as well as issues on rooted or jailbroken smartphones; \n- Reports from security scanners and other testing tools\n- Reports about non-implemented security “best practices” (like a lack of HSTS mechanism on client or server side, or soft token invalidation rules);\n- Reports about issues in third-party applications and services\n- Reports about missed headers or cookie flags;\n- Reports about configuration of our mail infrastructure (incorrect SPF records, DMARK policies, and other)\n- Data enumeration via registration or account recovery forms;\n- One-click authorization from emails and login CSRF via these links; \n- Captcha bypass using OCR;\n- Content injection issues;\n- Attacks based on social engineering or phishing.\n\nAnd another one important note: we'll respect your karma 'til you respect our time and work: do not send reports without precise and clear PoC; do not create several reports about one vulnerability on a different domains or different mobile platform (if it's not domain-dependant vulnerability or platform-dependent bug of course); do not send generic reports that were copied from other disclosed reports  without any check that these reports at least suitable for our services and apps. In other words: be kind!  \n\nTo make it easier, we’ll give you a number of examples and tell you which category they would be assigned to:\n\n- In our experience, most vulnerabilities are classified as HTML-injection or XSS. If the found vulnerability can generally not cause any damage (for example, you can only change the output of the page), then it will get the lowest category (1).\n\n- More dangerous: SQL-injection. Let's say you've found a vulnerability that \"breaks\" an SQL-query, but the only result is an incorrect display of content on the site. Such vulnerability will receive a rewardin the 2nd category. However, if using SQL-vulnerability an attacker can gain access to the data of one or more users, this vulnerability would rise up to the 5th category.\n\n- If a vulnerability can update data in the user profile, depending on how critical the data, we may assign a higher category, up to the 5th.\n\nWe can also award a super-reward above £1000, if you find something very serious.\n\n# Public disclosure\n\nWe're more than happy to publicly disclose your interesting issue once it has been fixed and agreed with us to do so. Public disclosure without our permission can lead to immediate forfeiture of any reward.\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":"2017-06-08T08:58:44.903Z"}]