[{"id":3765483,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- magisto.com \n- livestream.com — **out-of-scope\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Vulnerabilities affecting subdomains that resolve to third‑party or externally hosted services (e.g., billing.vimeo.com, help.vimeo.com).\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-11-04T05:05:20.378Z"},{"id":3764250,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- magisto.com \n- livestream.com — **out-of-scope\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n**October Bounty Boost @ Vimeo**\n\nTo celebrate **Cybersecurity Awareness Month**, Vimeo is enhancing bounty rewards throughout October.  All valid, in-scope, and accepted submissions during this period will receive an **additional severity-based bonus**, with an extra **$100 reward** for vulnerabilities that align with the weekly campaign theme.\n\n**Program Details**\n**Severity-Based Bonuses (October 2025):**\n- **Critical : +33%**\n- **High : +25%**\n- **Medium : +10%**\n- **Low : +5%**\n\n**Weekly Theme Bonus:**  **$100** for each **triaged report** that matches the theme (any severity level).\n**Campaign Duration:**  **October 6 – November 2, 2025 **  \nAll reports must be submitted during this window. Standard scope and policy rules apply for eligibility.\n\n** Weekly Themes**\n- **Week 1 — Oct 6–12:** Authentication \u0026 Session Handling  \n- **Week 2 — Oct 13–19:** Access Control \u0026 IDOR  \n- **Week 3 — Oct 20–26:** Cross-Site Scripting (XSS)  \n- **Week 4 — Oct 27–Nov 2:** Path Traversal, Race Conditions, SSRF \u0026 Injection\n\n**Terms \u0026 Notes**\n- Bonuses apply **only to Triaged, in-scope(Vimeo.com and vhx.tv) reports**.  \n- Each report may qualify for **one weekly theme bonus** in addition to the severity multiplier.  \n- Submission timestamps ( based on region of submission) determine eligibility for the weekly theme.  \n- Scope, safe-testing guidelines, and exclusion rules remain unchanged.  \n- Duplicates and out-of-scope reports are **not eligible** for bonuses.\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Vulnerabilities affecting subdomains that resolve to third‑party or externally hosted services (e.g., billing.vimeo.com, help.vimeo.com).\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-10-07T04:50:45.736Z"},{"id":3763851,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- magisto.com \n- livestream.com — **out-of-scope\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Vulnerabilities affecting subdomains that resolve to third‑party or externally hosted services (e.g., billing.vimeo.com, help.vimeo.com).\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-09-30T12:24:29.223Z"},{"id":3759623,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com \n- magisto.com \n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Livestream: https://livestream.com/platform/pricing\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Vulnerabilities affecting subdomains that resolve to third‑party or externally hosted services (e.g., billing.vimeo.com, help.vimeo.com).\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\n\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-07-22T06:13:41.371Z"},{"id":3757343,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com \n- magisto.com \n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Livestream: https://livestream.com/platform/pricing\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-06-11T16:24:24.486Z"},{"id":3754414,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n*[Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com \n- magisto.com \n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n| Enterprise                       | 180 Days       | 1 Critical submission or 2 High submission      |\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Livestream: https://livestream.com/platform/pricing\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-04-26T10:10:03.371Z"},{"id":3754413,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n*[Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com \n- magisto.com \n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n| Enterprise                       | 180 Days       | 1 Critical submission or 2 High submission      |\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Livestream: https://livestream.com/platform/pricing\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-04-26T10:09:11.019Z"},{"id":3754412,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers are committed to ensuring the safety and security of our site and users. We greatly respect the work of security experts and strive to stay up-to-date with the latest security techniques. However, we acknowledge that no system is infallible. If you identify a security vulnerability in one of our products, we encourage you to report it to us.\n\nBefore submitting a report, please review our guidelines below to understand what constitutes a security vulnerability and our preferred reporting methods. We are committed to evaluating and resolving all valid bugs promptly after a report is filed.\n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n*[Recommended features for increased focus](#recommended-features)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a platform for video creation, hosting, sharing, and streaming, with features like a Video Player, Live Streaming, and Vimeo OTT. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.). \n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com \n- magisto.com \n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n# Dont's\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- **Do NOT attempt to conduct post-exploitation**: modification or destruction of data, interruption or degradation of services, and pivoting with access not normally granted.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n\n| Plan Tier                        | Access Period  | Qualification Criteria                          |\n|----------------------------------|----------------|-------------------------------------------------|\n| Advanced ( standard or starter)  | 180 Days       | 2 Medium or 1 High severity submissions         |\n| Enterprise                       | 180 Days       | 1 Critical submission or 2 High submission      |\n\n\nNote: The plan will be activated only on a 2 HackerOne alias account. If you believe you have met the criteria, please submit the form and await our response.\nForm link : https://forms.gle/88UEMuwVKfyuGpeVA \n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                         | Bug Examples                                                                                              |\n|--------------------|--------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                                                 |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                                     |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF                     |\n| Medium             | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                                         |\n| Medium             | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                                    |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                                      |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                                       |\n| Low                | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                                            |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                                      |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure                                   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                                            |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal                                   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                                        |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                                                |\n| Low                | High               | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                                     |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                                              |\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Recommended features for increased focus\n We recommend that researchers prioritize their efforts on the core features provided within our upgrade plans. You can find more information about these features at the following links:\n - Vimeo: https://vimeo.com/upgrade-plan\n - Vimeo enterprise\n - Livestream: https://livestream.com/platform/pricing\n - Magisto: https://www.magisto.com/account/upgrade\n - Vimeo AI features ( Enterprise tier)\n\n# Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering and Man-in-the-Middle attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them.\n- 3rd party sites used by Vimeo.\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo.\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n- Google Maps API key exposure, unless it is allowing you to interact with any other google services.\n- Stack traces or path disclosures (without sensitive data).\n- Banner and Version grabbing.\n- CSV injection and Host header Injection ( without any server side impact ).\n- Broken link hijacking on customer's VHX subdomains.( for eg: `customername.vhx.tv`).\n- Login spoofing with @vimeo.com or @vhx.tv.\n- Autologin token reuse.\n- Public 0-day/1-day vulnerabilities known to team within 15 days of the disclosure.\n- IDOR on UUID (or randomly generated alphanumeric IDs with a length of 16+ characters), unless there is a proven method to retrieve Vimeo asset UUIDs or random generated id's.\n- Fake card or BIN-based payment bypass.\n- Pre-account signup and account lockout.\n- Credential leaks from personal/external sources.( unless there is an exposure of @vimeo.com and @vhx.tv)\n- Username and userid exposure (  private mode )\n- No Lockout on Login/Forget Password bruteforce.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-04-26T10:06:53.979Z"},{"id":3682853,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, `.webm`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission accepted\nOR \n- 2 High or higher severity submissions accepted\nOR\n- 3 Medium or higher severity submissions accepted\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-01T15:40:13.268Z"},{"id":3682302,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n- We strongly encourage providing a video POC for each finding, although it is not required. If you do provide one, please upload the video in a file format that is supported by the [H1 embedded player](https://docs.hackerone.com/programs/using-markdown.html#inline-images-and-video) (e.g. `.mp4`, `.mov`, etc, but not `.avi`).\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission accepted\nOR \n- 2 High or higher severity submissions accepted\nOR\n- 3 Medium or higher severity submissions accepted\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-01-20T15:56:40.540Z"},{"id":3675421,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission accepted\nOR \n- 2 High or higher severity submissions accepted\nOR\n- 3 Medium or higher severity submissions accepted\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties.\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T17:13:26.082Z"},{"id":3675419,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n \u0026nbsp;\n \u0026nbsp;\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n \u0026nbsp;\n \u0026nbsp;\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto).\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \u0026nbsp;\n \u0026nbsp;\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T17:11:00.446Z"},{"id":3675418,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com*  email address. [Learn more here](https://docs.hackerone.com/hackers/hacker-email-alias.html). This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto).\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T16:50:27.905Z"},{"id":3675417,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request permission for disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto).\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T16:47:38.557Z"},{"id":3675416,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto).\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T16:47:16.224Z"},{"id":3675415,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T16:46:35.969Z"},{"id":3675410,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities-in-scope)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities-out-of-scope)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T15:56:10.932Z"},{"id":3675409,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#user-content-about-vimeo)\n* [Rules](#user-content-rules)\n* [Rules for us](#user-content-rules-for-us)\n* [Triage and Payout Process](#user-content-triage-and-payout-process)\n* [Criteria for premium accounts](#user-content-criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#user-content-qualifying-vulnerabilities--in-scope-)\n* [Non-qualifying vulnerabilities (out-of-scope)](#user-content-non-qualifying-vulnerabilities--out-of-scope-)\n* [Disclosure Policy](#user-content-disclosure-policy)\n* [Safe Harbor](#user-content-safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T15:55:10.681Z"},{"id":3675408,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#about-vimeo)\n* [Rules](#rules)\n* [Rules for us](#rules-for-us)\n* [Triage and Payout Process](#triage-and-payout-process)\n* [Criteria for premium accounts](#criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#qualifying-vulnerabilities--in-scope-)\n* [Non-qualifying vulnerabilities (out-of-scope)](#non-qualifying-vulnerabilities--out-of-scope-)\n* [Disclosure Policy](#disclosure-policy)\n* [Safe Harbor](#safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n# Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T15:54:00.372Z"},{"id":3675407,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# Table of Contents\n* [About Vimeo](#about-vimeo)\n* [Rules](#rules)\n* [Rules for us](#rules-for-us)\n* [Triage and Payout Process](#triage-and-payout-process)\n* [Criteria for premium accounts](#criteria-for-premium-accounts)\n* [Qualifying vulnerabilities (in-scope)](#qualifying-vulnerabilities--in-scope-)\n* [Non-qualifying vulnerabilities (out-of-scope)](#non-qualifying-vulnerabilities--out-of-scope-)\n* [Disclosure Policy](#disclosure-policy)\n* [Safe Harbor](#safe-harbor)\n \n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T15:52:57.676Z"},{"id":3675406,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\nHowever, note that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T15:44:10.694Z"},{"id":3675405,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n .\n .\n .\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n\n .\n .\n .\n\n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n .\n .\n .\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n\n .\n .\n .\n\n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n\n .\n .\n .\n\n#Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF: Vimeo’s backend is full of microservices that communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL, etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n\n .\n .\n .\n\n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n\n .\n .\n .\n\n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n\n .\n .\n .\n\n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n .\n .\n .\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n .\n .\n .\n\n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T15:38:30.903Z"},{"id":3675400,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n\n# About Vimeo\n\nVimeo is a website for creating, hosting, sharing, and publishing videos for audiences to stream. We have many similarities to YouTube, but our revenue model is completely different (eg. our videos are ad-free, we charge content creators, etc.).\n\nOur company has 6 different components:\n- vimeo.com\n- vhx.tv (also known as \"OTT\")\n- livestream.com\n- magisto.com\n- wirewax.com — **out-of-scope**\n- wibbitz.com — **out-of-scope**\n\nPlease note that, previously, Vhx, Magisto, and Livestream each had their own separate bug bounty programs within HackerOne. We have now merged those three programs into the main Vimeo program.\n \n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing and contracts out for pentests often. As such, we often find and fix issues on our own. If our internal security team or our pentesters or our developers happen to find the same issue before you find it, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n#Rules for us\nVimeo and HackerOne will make their best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete the final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n#Triage and Payout Process\nVimeo is a HackerOne-managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish the initial triage, they will pass the report back to Vimeo so that we may conduct the final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide not to fix the issue. Further note that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n#Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF: Vimeo’s backend is full of microservices that communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL, etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote that your report does not necessarily need to include a full exploit. Did you come across a spicy bug that has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by the scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email-related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing/text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) has been rooted, malwared, bot'd, etc.\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne, and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n\n \n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-07-29T15:13:11.768Z"},{"id":3663827,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n \n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing, contracts out for pentests, developers fixing issues on their own, etc. If they happen to file the same issue before yours, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n#Rules for us\nVimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n#Triage and Payout Process\nVimeo is a HackerOne managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish initial triage, they will pass the report back to Vimeo so that we may conduct final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide to not fix the issue. Further note, that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n#Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF : Vimeo’s backend is full of microservices which communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote, that you report does not necessarily need to include a full exploit. Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n\n \n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-01-05T21:50:52.796Z"},{"id":3663329,"new_policy":"#We are running a promotion on findings related to log4j!\n\nVimeo has recently taken ample measures to protect ourselves and our customers against the recent log4j vulnerabilities: we’ve upgraded code dependencies, we’ve deprecated repos, we’ve patched services, we’ve uninstalled tools, we’ve reinforced our tin-foil hats with a fresh new layer of aluminum, etc. We are confident in our remediation efforts.\n\nHowever, as is the case with even the best security engineers, we’re still paranoid. Therefore, we are hereby announcing a two-week promotion in which we will pay dramatically higher bounties for any findings related to log4j.\n\n**Promotion start date**: December 22, 2021\n\n**Promotion end date**: January 5, 2022 at 5pm US Eastern Standard Time (10pm UTC)\n\n**Rewards:**\n- Leverage log4j for RCE: $5k USD\n- Leverage log4j for callback (without any RCE): $2k USD\n- Leverage log4j for Denial of Service (without any RCE): $1k USD\n\n**Happy holiday hunting!**\n\n#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n \n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing, contracts out for pentests, developers fixing issues on their own, etc. If they happen to file the same issue before yours, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n#Rules for us\nVimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n#Triage and Payout Process\nVimeo is a HackerOne managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish initial triage, they will pass the report back to Vimeo so that we may conduct final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide to not fix the issue. Further note, that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n#Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF : Vimeo’s backend is full of microservices which communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote, that you report does not necessarily need to include a full exploit. Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n\n \n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-12-22T19:27:27.926Z"},{"id":3658649,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n \n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing, contracts out for pentests, developers fixing issues on their own, etc. If they happen to file the same issue before yours, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n#Rules for us\nVimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n#Triage and Payout Process\nVimeo is a HackerOne managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish initial triage, they will pass the report back to Vimeo so that we may conduct final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide to not fix the issue. Further note, that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n#Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF : Vimeo’s backend is full of microservices which communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote, that you report does not necessarily need to include a full exploit. Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n\n \n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-09-21T08:56:16.756Z"},{"id":3649014,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion.\n \n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing, contracts out for pentests, developers fixing issues on their own, etc. If they happen to file the same issue before yours, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n#Rules for us\nVimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n#Triage and Payout Process\nVimeo is a HackerOne managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish initial triage, they will pass the report back to Vimeo so that we may conduct final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\n\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide to not fix the issue. Further note, that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n#Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF : Vimeo’s backend is full of microservices which communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote, that you report does not necessarily need to include a full exploit. Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Thumbnail / Description metadata leakage or similar\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n\n \n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\n\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-23T18:48:13.484Z"},{"id":3649012,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \nBounties are awarded based on merit at our discretion.\n \n#Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing, contracts out for pentests, developers fixing issues on their own, etc. If they happen to file the same issue before yours, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n#Rules for us\nVimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n#Triage and Payout Process\nVimeo is a HackerOne managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish initial triage, they will pass the report back to Vimeo so that we may conduct final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide to not fix the issue. Further note, that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n#Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF : Vimeo’s backend is full of microservices which communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote, that you report does not necessarily need to include a full exploit. Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n#Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n#Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n#Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Thumbnail / Description metadata leakage or similar\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.\n\n#Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n\n \n#Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-23T18:44:57.237Z"},{"id":3648494,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \nBounties are awarded based on merit at our discretion.\n \n##Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing, contracts out for pentests, developers fixing issues on their own, etc. If they happen to file the same issue before yours, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n**DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n\n**DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n\n**DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n\n**DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n##Rules for us\nVimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n##Triage and Payout Process\nVimeo is a HackerOne managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish initial triage, they will pass the report back to Vimeo so that we may conduct final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide to not fix the issue. Further note, that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n##Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF : Vimeo’s backend is full of microservices which communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote, that you report does not necessarily need to include a full exploit. Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n##Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n##Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n##Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Thumbnail / Description metadata leakage or similar\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.\n\n##Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \n##Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-08T14:50:10.824Z"},{"id":3648281,"new_policy":"#Vimeo's Bug Bounty Program Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you.\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \nBounties are awarded based on merit at our discretion.\n \n##Rules\n\n**Requirements for your submission to be eligible for a bounty reward:**\n- **You must demonstrate a vulnerability with proof/evidence.** When hunting for bugs and when providing evidence, please only use your own accounts. Do not use or access other people’s data or accounts at any time.\n- **You must be the “first reporter.”** Please understand that we have an active security team that does regular internal testing, contracts out for pentests, developers fixing issues on their own, etc. If they happen to file the same issue before yours, they will count as the “first reporter” and your report will be considered a duplicate.\n- **The underlying issue must be unique**, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n- **Your report must be in scope.** Please look over the scope table at the end of this policy before submitting a report. We want to help reduce your risk of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n\n-**Suggestions to ensure fast processing and maximum bounty:**\n- Communicate respectfully and professionally at all times**\n- Provide detailed reproducible steps. This is important.\n- Explain the potential impact\n- Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n\n-**Your report does not necessarily need to include a full exploit.** Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way, we’d be happy to take a look and might even consider it without it being fully complete.\n\n- **DO NOT use automated tools or scanners.** Reports as such will be closed as N/A.\n- **DO NOT DDoS** or otherwise attack us in a way that would disrupt service for our customers.\n- **DO NOT disclose** or discuss any vulnerability, even resolved ones, outside of the program at any time without express consent from Vimeo. Please see our Disclosure Policy below for instructions on requesting permission for disclosure. \n- **DO NOT attempt to access other people's private data or accounts.** Basic Vimeo accounts are free, so setting up example cases with throwaway accounts should be easy.\n- We highly recommend that you sign up for any throwaway accounts using your *@wearehackerone.com* [learn more](https://docs.hackerone.com/hackers/hacker-email-alias.html) email address. This helps us distinguish between bug bounty hunters and actual malicious actors. We’ll be less likely to flag or suspend your Vimeo account(s).\n\n##Rules for us\nVimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:\n- HackerOne aims to complete initial triage within 2 days after you submit your report\n- Vimeo will complete final triage within 3 business days after the H1 triage\n- Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it\n \n##Triage and Payout Process\nVimeo is a HackerOne managed program. HackerOne currently has a commitment to complete initial triage within 2 days after you submit your report. Once they finish initial triage, they will pass the report back to Vimeo so that we may conduct final triage. Items in the *Triaged* state alone will NOT be considered accepted until Vimeo makes a final decision, which we will signify with a full bounty payout.\nPlease be aware that, even if the HackerOne team has triaged a ticket, the Vimeo team may potentially close the ticket at any time with no payout, eg. if we discover that it is a duplicate or if we decide to not fix the issue. Further note, that if the report is a duplicate, we may potentially not provide any links to the original ticket, especially if the original reporter would prefer that their report be kept private or if the original ticket exists within our internal ticketing system.\n \n##Focus areas\nWe’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:\n- SSRF : Vimeo’s backend is full of microservices which communicate to each other and sometimes with partial or full control over the HTTP requests thus making us prone to this type of attack. \n- Injection (OS, SQL etc)\n- Authentication \u0026 OAuth Vulnerabilities \n- XSS\n- Video privacy bypass\n\nNote, that you report does not necessarily need to include a full exploit. Did you come across a spicy bug which has a good impact, but you’re missing one or two pieces needed to complete the exploit? Send it our way — we’d be happy to take a look and might even consider it without it being fully complete.\n \n##Criteria for premium accounts\nBasic Vimeo accounts are free, but Vimeo offers additional features to our customers via our [paid plans](https://vimeo.com/upgrade). We’d like to give our bug bounty researchers access to these paid plans free of charge so that they may test all the extra functionality that is available only in those plans.\n\nTo be eligible for a paid account, you must meet at least one of the following qualifications:\n- 1 Critical severity submission in Vimeo\nOR \n- 2 High or higher severity submissions in Vimeo\nOR\n- 3 Medium or higher severity submissions in Vimeo\n \n##Qualifying vulnerabilities (in-scope) \nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable. You must be able to reproduce the issue on request with your account(s). Use the following table to categorize security issues. \n\n*Note: Non-listed vulnerabilities may also be eligible. Some vulnerability types may fall under a variety of severity ratings determined by scope/scale of exploitation and impact.*\n\n| Severity (Minimum) | Severity (Maximum) | Vulnerability Type                                       | Bug Examples                                                                            |   |\n|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|\n| Critical           | Critical           | OS Shell Execution                                       | Remote Code Execution; Code Injection; OS Command Injection                             |   |\n| Medium             | Critical           | SQL Injection                                            | SQL Injection (Inband SQLi; Blind SQLi)                                                 |   |\n| Medium             | Critical           | Server-Side Request Forgery                              | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF |   |\n| Low                | Critical           | Incorrect Permission Assignment                          | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation                    |   |\n| High               | Critical           | Improper Restriction of XML External Entity Reference    | XXE                                                                                     |   |\n| High               | Critical           | Uncontrolled Format String                               | Insecure Deserialisation                                                                |   |\n| Medium             | High               | Inconsistent Interpretation of HTTP Requests             | HTTP Request Smuggling                                                                  |   |\n| Low                | Critical           | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal               |   |\n| Low                | Critical           | Missing Authentication for Critical Function             | Exposed Administrative Interface                                                        |   |\n| Low                | Critical           | Information Exposure                                     | Exposure of PII; Credentials on GitHub; Confidential Information Exposure               |   |\n| Low                | Critical           | Incorrect Authorization                                  | Authorization Bypass; Account Takeover                                                  |   |\n| Medium             | Medium             | Download of Code Without Integrity Check                 | S3 Bucket Upload                                                                        |   |\n| Medium             | High               | Cross-Site Scripting                                     | Different type of XSS                                                                   |   |\n| Low                | High               | Cross-Site Request Forgery                               | State-Changing CSRF; Non-State-Changing CSRF                                            |   |\n| Low                | Medium             | Misconfiguration                                         | Subdomain Takeover; Dangling DNS Record                                                 |   |\n| Low                | Medium             | CRLF Injection                                           | CRLF Injection                                                                          |   |\n \n##Non-qualifying vulnerabilities (out-of-scope)\n- User enumeration\n- Open redirect (Unless chained to show an impact)\n- Thumbnail / Description metadata leakage or similar\n- Reports from automated tools or scans\n- Missing rate limits, unless it can lead to account takeover\n- Missing cookie flags on non-sensitive cookies\n- Logout CSRF attacks (unless chained to show an impactful exploit)\n- Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n- Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)\n- Reports of window.opener redirects\n- Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS \n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)\n- Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.\n\n##Disclosure Policy\nVimeo understands that disclosure helps the infosec community and strengthens your professional reputation.\n \n###Rules\n \n- If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.\n- Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.\n \n###How to request permission\nPlease request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.\n \n###Restrictions\n- Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.\n- Only Resolved reports requested by the original reporter are eligible for disclosure. All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.-\n- Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure\n \nShould a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .\n \nIn addition to these rules, please also follow [HackerOne's disclosure guidelines](https://www.hackerone.com/disclosure-guidelines)\n\n \n##Safe Harbor\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities.\nWe authorize access to our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities.\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n**Thanks for helping us fight the good fight!**\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-01T19:10:55.426Z"},{"id":3640958,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\n#All vulnerabilities must be tagged by asset \n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues. (These are guidelines, the CVSS score will determine its ultimate rating)\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything on `*.magisto.com` - these reports belong over at https://hackerone.com/magisto\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n## Google Play Security Rewards Program\n\nCertain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the [Google Play Security Rewards Program](https://www.google.com/about/appsecurity/play-rewards/). To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s [Scope and Vulnerability Criteria](https://www.google.com/about/appsecurity/play-rewards/).\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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-08-04T20:14:33.067Z"},{"id":3634813,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\n#All vulnerabilities must be tagged by asset \n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues. (These are guidelines, the CVSS score will determine its ultimate rating)\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything on `*.magisto.com` - these reports belong over at https://hackerone/magisto (Please email bugbounty@vimeo.com with high level details as this is currently a private program)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n## Google Play Security Rewards Program\n\nCertain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the [Google Play Security Rewards Program](https://www.google.com/about/appsecurity/play-rewards/). To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s [Scope and Vulnerability Criteria](https://www.google.com/about/appsecurity/play-rewards/).\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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-04-09T15:10:03.949Z"},{"id":3634502,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues. (These are guidelines, the CVSS score will determine its ultimate rating)\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything on `*.magisto.com` - these reports belong over at https://hackerone/magisto (Please email bugbounty@vimeo.com with high level details as this is currently a private program)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n## Google Play Security Rewards Program\n\nCertain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the [Google Play Security Rewards Program](https://www.google.com/about/appsecurity/play-rewards/). To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s [Scope and Vulnerability Criteria](https://www.google.com/about/appsecurity/play-rewards/).\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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-04-02T13:44:23.807Z"},{"id":3633505,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything on `*.magisto.com` - these reports belong over at https://hackerone/magisto (Please email bugbounty@vimeo.com with high level details as this is currently a private program)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n## Google Play Security Rewards Program\n\nCertain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the [Google Play Security Rewards Program](https://www.google.com/about/appsecurity/play-rewards/). To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s [Scope and Vulnerability Criteria](https://www.google.com/about/appsecurity/play-rewards/).\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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-03-20T13:12:23.062Z"},{"id":3620849,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything on `*.magisto.com` - these reports belong over at https://hackerone/magisto (Please email bugbounty@vimeo.com with high level details as this is currently a private program)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n## Google Play Security Rewards Program\n\nCertain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the [Google Play Security Rewards Program](https://hackerone.com/googleplay). To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s [Scope and Vulnerability Criteria](https://hackerone.com/googleplay).\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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":"2019-10-09T11:59:30.437Z"},{"id":3618513,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Please hold off on anything for Magisto.com unless you think it is HIGH/CRITICAL. We are undergoing a pen test and as soon as its done we'll open /magisto .\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n## Google Play Security Rewards Program\n\nCertain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the [Google Play Security Rewards Program](https://hackerone.com/googleplay). To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s [Scope and Vulnerability Criteria](https://hackerone.com/googleplay).\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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":"2019-09-09T13:12:40.561Z"},{"id":3612954,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything in any way/shape/form with `Magisto`. Once we close and get them under the Vimeo Security Engineering umbrella we will announce Bug Bounty for them. We will mark any report before that time in any Vimeo (Vimeo/VHX/Livestream) program as spam and ban the user. (Legal issues, sorry)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n## Google Play Security Rewards Program\n\nCertain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the [Google Play Security Rewards Program](https://hackerone.com/googleplay). To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s [Scope and Vulnerability Criteria](https://hackerone.com/googleplay).\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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":"2019-06-28T14:23:28.369Z"},{"id":3610023,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything in any way/shape/form with `Magisto`. Once we close and get them under the Vimeo Security Engineering umbrella we will announce Bug Bounty for them. We will mark any report before that time in any Vimeo (Vimeo/VHX/Livestream) program as spam and ban the user. (Legal issues, sorry)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n - Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n - Missing security headers including (content security policy) which do not lead directly to a vulnerability\n - Clickjacking on static websites\n - Content spoofing / text injection\n - Use of a known-vulnerable library (without evidence of exploitability)\n - Vulnerabilities affecting users of outdated browsers or platforms\n - Social engineering attacks including self-xss\n - Homoglyph Attack, we feel this is a browser issue\n - Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n - Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n - Denial of service attacks, do not perform them\n - 3rd party sites used by Vimeo\n - Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n - RCE on sites that link or are redirected from Vimeo\n - Brute forcing\n - Re-reports due to improper verification \n - Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n - Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n - Downloading or installing mobile versions from anywhere other than their associated official stores.\n - If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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":"2019-05-22T19:59:41.786Z"},{"id":3609986,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. We greatly respect the work of security experts everywhere, and strive to stay up to date with the latest security techniques. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nBounties are awarded based on merit at our discretion. After 3 medium or higher code based fixes, you can request to get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security). (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **RESOLVED** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX) .\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action at our discretion.\n\n# Scope Priorities and Disclaimer\nPlease read this section before submitting a report. We want to help reduce your chance of submitting an out-of-scope report that could hurt your Signal, as well as reduce noise in our inbox.\n  \n\n# Rules\n\n - To be considered the original reporter of a vulnerability :\n   - You must be able to prove that there is a vulnerability using your own account(s). \n   - Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact. \n   - Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n   - Please provide detailed reports with reproducible steps. \n   - If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last. \n   - HackerOne and Vimeo must be able to reproduce it\n   - It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100\n    (Reporting first without meeting the rest of the requirements or just having a lower ticket number does not qualify as being the original reporter. Please note we have an active security team that does scans, contracts out for pentests, developers fixing issues on their own, etc. While not in HackerOne they will count as being “first reporter”)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners. Reports will be close as N/A.\n - **Don't** DDoS or otherwise attack us in a way that would disrupt service for our customers\n\n# Qualifying vulnerabilities\n\nPlease take the time to provide a clear proof of concept that shows how a particular vulnerability is exploitable.  You must be able to reproduce the issue on request with your account(s). Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nWont fix: information disclosure, see also other non qualifying vulnerabilities\n\nWe do appreciate reports containing CVSSv3 formatted scores (https://www.first.org/cvss/calculator/3.0)\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways that fit the rest of our rules and don't conflict with the non-qualifying vulnerabilities.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n- Thumbnail / Description metadata leakage or similar\n - Anything on `*.livestream.com’ (Unless its is an LS\u003c\u003eVimeo Integration or chained issue)- Otherwise these reports belong over at https://hackerone.com/livestream\n - Anything on `*.vhx.tv’ - these reports belong over at https://hackerone.com/vhx\n- Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com`\n - Anything in any way/shape/form with `Magisto`. Once we close and get them under the Vimeo Security Engineering umbrella we will announce Bug Bounty for them. We will mark any report before that time in any Vimeo (Vimeo/VHX/Livestream) program as spam and ban the user. (Legal issues, sorry)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)\n- Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)\n- Denial of service attacks, do not perform them\n- 3rd party sites used by Vimeo\n- Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised\n- RCE on sites that link or are redirected from Vimeo\n- Brute forcing\n- Re-reports due to improper verification \n- Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)\n- Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n- Downloading or installing mobile versions from anywhere other than their associated official stores.\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n# SLA\nVimeo will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days  (unless more information is needed from the hacker)\n\nWe’ll try to keep you informed about our progress throughout the process. We welcome cases where you've retested and find it has been fixed, as another ticket may have been the source. \n\n# Triage\n\nVimeo  is a HackerOne managed program. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an post triage acceptance bounty payout ($100). This initial payout will be deducted from the final bounty payout, if any. Tickets may be triaged by HackerOne, but later marked duplicate or other by Vimeo. Where developers have already begun remedying the problem before ticket submission, triage, or even post triage acceptance bounty award are deemed to be ineligible for triage. (The can be self closed or marked duplicate with no links as the tickets will be in our internal ticket system). \n\n# Bounties/Bonuses\n\nPast the initial post triage acceptance bounty award, an additional bounty/bonus/both, at our discretion, may be awarded at ticket completion. Only tickets that have been paid the post triage acceptance bounty award, have been picked up and worked by a developer and have been verified by the researcher are eligible to be put into a \"RESOLVED\" state signaling completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to: Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another.\n\n# Disclosure Policy \n* Please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization at any time.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor \n\nThank you for helping Vimeo, Inc. and its subsidiaries (“Vimeo”). Vimeo provides this Safe Harbor Statement to encourage and facilitate research using HackerOne’s bug bounty program to help us identify bugs and vulnerabilities. \n\nWe authorize to access our owned-and-operated systems, services, and applications for the purpose of conducting research consistent with HackerOne’s then-current policies. We will not consider your good faith activities in this regard to violate applicable criminal or civil laws (even if those activities inadvertently exceed the scope of our authorization), such as the Digital Millennium Copyright Act or Computer Fraud and Abuse Act, and we will not commence legal action with respect to such activities. \n\nIf legal action is commenced against you as a result of your good faith activities, Vimeo will take steps to make it known to parties commencing such action that your activities were conducted in accordance with this Safe Harbor Statement.\n\nTo the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control. \n\nPlease note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control. \n\nWe encourage you to contact us if you have questions regarding the scope of this Safe Harbor Statement. You may do so through HackerOne or by emailing us at bugbounty@vimeo.com.\n\n***Thanks for helping us fight the good fight!**\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":"2019-05-22T13:19:59.584Z"},{"id":3608256,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. You can ask to be added to our [Bug Hall of Fame](https://vimeo.com/about/security) after 3 medium or higher resolved issues. (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **Resolved** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban.\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action.\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Anything in any way/shape/form with `Magisto`. Once we close and get them under the Vimeo Security Engineering umbrella we will announce Bug Bounty for them. We will mark any report before that time in any Vimeo (Vimeo/VHX/Livestream) program as spam and ban the user. (Legal issues, sorry)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- Re-reports of tickets recently fixed where the author did not properly validate\n- Downloading or installing mobile versions from anywhere other than their associated official stores. \n- Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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":"2019-04-25T19:11:30.338Z"},{"id":3608200,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. You can ask to be added to our [Bug Hall of Fame](https://vimeo.com/about/security) after 3 medium or higher resolved issues. (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **Resolved** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban.\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action.\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Anything in any way/shape/form with `Magisto`. Once we close and get them under the Vimeo Security Engineering umbrella we will announce Bug Bounty for them. We will mark any report before that time in any Vimeo (Vimeo/VHX/Livestream) program as spam and ban the user. (Legal issues, sorry)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- Re-reports of tickets recently fixed where the author did not properly validate\n- Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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":"2019-04-24T18:00:01.703Z"},{"id":3608128,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. You can ask to be added to our [Bug Hall of Fame](https://vimeo.com/about/security) after 3 medium or higher resolved issues. (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **Resolved** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban.\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action.\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Anything in any way/shape/form with `Magisto`. Once we close and get them under the Vimeo Security Engineering umbrella we will announce Bug Bounty for them. We will mark any report before that time in any Vimeo (Vimeo/VHX/Livestream) program as spam and ban the user. (Legal issues, sorry)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- Re-reports of tickets recently fixed where the author did not properly validate\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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":"2019-04-23T12:35:38.202Z"},{"id":3608061,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. You can ask to be added to our [Bug Hall of Fame](https://vimeo.com/about/security) after 3 medium or higher resolved issues. (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **Resolved** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban.\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action.\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Anything in any way/shape/form with `Magisto`. Once we close and get them under the Vimeo Security Engineering umbrella we will announce Bug Bounty for them. We will mark any report before that time in any Vimeo (Vimeo/VHX/Livestream) program as spam and ban the user. (Legal issues, sorry)\n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- EFFECTIVE IMMEDIATELY XSS on themes is no longer acceptable. We are doing a major overhaul and will not be accepting reports at this time.\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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":"2019-04-22T13:41:16.670Z"},{"id":3596746,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. You can ask to be added to our [Bug Hall of Fame](https://vimeo.com/about/security) after 3 medium or higher resolved issues. (Please note this page is not currently accessible via Vimeo.com, we are working on that)\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **Resolved** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban.\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action.\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- EFFECTIVE IMMEDIATELY XSS on themes is no longer acceptable. We are doing a major overhaul and will not be accepting reports at this time.\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-12-03T17:59:19.032Z"},{"id":3595383,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n# Public Disclosure Process and Policy\n* Vimeo reserves the right to approve or deny any request for disclosure.\n* Vimeo has a multi-level internal approval process for all valid disclosure requests.\n* ONLY **Resolved** reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).\n* All other reports (Informative, NA, Spam) are not eligible for disclosure of any kind, in or outside the HackerOne platform.  Failure to comply with these rules may result in a program ban.\n* Should a researcher break any disclosure or program policies, that researcher shall no longer be protected under Safe Harbor and will be subject to legal action.\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- EFFECTIVE IMMEDIATELY XSS on themes is no longer acceptable. We are doing a major overhaul and will not be accepting reports at this time.\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-11-21T18:49:55.617Z"},{"id":3594050,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Thumbnail / Description metadata leakage or similar\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- EFFECTIVE IMMEDIATELY XSS on themes is no longer acceptable. We are doing a major overhaul and will not be accepting reports at this time.\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-11-08T16:12:44.194Z"},{"id":3591927,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n- EFFECTIVE IMMEDIATELY XSS on themes is no longer acceptable. We are doing a major overhaul and will not be accepting reports at this time.\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-10-19T20:49:30.517Z"},{"id":3590010,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n- **checkout.vimeo.com** - This is subject to things we have control over.\n- *.vimeo.com (Except for 3rd party sites, and subject to realizing we forgot to exclude one)\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-09-27T20:55:09.341Z"},{"id":3588219,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n- If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program\n\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-09-08T17:19:44.742Z"},{"id":3582139,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n# Triage\n\n**EFFECTIVE July 5,2018 Vimeo is now a HackerOne managed program, and as such triage and acceptance flow has changed. HackerOne currently has a 2 day commitment to initial triage. Once they do triage, they will pass it back to Vimeo. PLEASE NOTE that no longer being marked \"Triaged\" is considered it being accepted by Vimeo. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Vimeo, which will be denoted by an initial bounty payout ($100). This initial payout will be deducted from the final bounty payout.\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-07-10T17:38:06.279Z"},{"id":3581792,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\n### We are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report as this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\n**Critical**: most impactful, Remote code execution, SQLi, root access to any systems\n\n**High**: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\n**Medium**: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\n**Low**: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\n**wont fix**: information disclosure, see also other non-qualifying vulnerabilities\n\n***Reports from automated scanners will not be accepted.***\n\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-07-06T19:37:30.422Z"},{"id":3581786,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update please\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities get a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non-qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!***\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-07-06T18:39:35.748Z"},{"id":3581610,"new_policy":"# Vimeo's Responsible Bug Disclosure Policy\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n# Scope\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n# Rules\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n# Qualifying vulnerabilities\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n# Non-qualifying vulnerabilities\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n# Bounties/Bonuses\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!**\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-07-05T13:34:49.304Z"},{"id":3581426,"new_policy":"(VIMEO WILL NOT BE TRIAGING ON JULY 3 AND JULY 4 2018. ENJOY!)\n**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n**Bounties/Bonuses**\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!**\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-07-03T15:22:26.270Z"},{"id":3579175,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits, unless it can lead to account takeover\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n**Bounties/Bonuses**\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!**\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-06-04T14:05:30.895Z"},{"id":3573068,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.  You MUST be able to reproduce the issue on request with your account(s). Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits on non-sensitive functions\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n**Bounties/Bonuses**\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!**\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-04-05T15:58:00.438Z"},{"id":3571873,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.   Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `ott.vimeo.com` - these reports belong over at https://hackerone.com/vhx\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits on non-sensitive functions\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n**Bounties/Bonuses**\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!**\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-03-22T20:52:31.398Z"},{"id":3568523,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.   Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits on non-sensitive functions\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n**Bounties/Bonuses**\n\nA bounty/bonus/both, at our discretion, will only be awarded at ticket completion. Each ticket starts out at the bottom of a baseline range that takes into account initial perceived severity, as well as type. From there, it goes up (rarely down) given various factors (Including but not limited to : Actual final perceived severity, completeness of report, ease of working with the researcher, etc). All payouts are suggested by at least one person, approved by another. \n\n***Thanks for helping us fight the good fight!**\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-02-08T13:58:55.985Z"},{"id":3567222,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.   Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `labs.vimeo.com` - subdomain takeover is not possible, the app is configured.\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits on non-sensitive functions\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n\n\n***Thanks for helping us fight the good fight!**\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-22T18:19:31.593Z"},{"id":3563570,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. Having to go through \"Update pleaae\" only clutters our queue.\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.   Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits on non-sensitive functions\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n- Homoglyph Attack, we feel this is a browser issue\n\n\n\n***Thanks for helping us fight the good fight!**\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-11-17T17:02:05.853Z"},{"id":3545257,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.   Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: stored or reflected cross site scripting,  other novel bugs that have a security impact to many users\n\nLow: CSRF missing from non excluded functions, other security issues that impact only a small subset of users\n\nwont fix: information disclosure, see also other non qualifying vulnerabilities\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits on non-sensitive functions\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n\n\n\n***Thanks for helping us fight the good fight!**\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-01-19T16:19:50.548Z"},{"id":3545256,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable.   Please include a severity rating with your report this will help us price your bounty in a timely fashion.  Use the following guidelines to categorize security issues.\n\nCritical: most impactful, Remote code execution, SQLi, root access to any systems\n\nHigh: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)\n\nMedium: cross site scripting,  \n\nLow:\n\n**Reports from automated scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits on non-sensitive functions\n - Missing cookie flags on non-sensitive cookies\n - Logout CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n- Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC\n- Missing security headers including (content security policy) which do not lead directly to a vulnerability\n- Clickjacking on static websites\n- Content spoofing / text injection\n- Use of a known-vulnerable library (without evidence of exploitability)\n- Vulnerabilities affecting users of outdated browsers or platforms\n- Social engineering attacks including self-xss\n\n\n\n***Thanks for helping us fight the good fight!**\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-01-19T15:30:44.677Z"},{"id":3541752,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. \n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n** Please note as of Nov 2016 we are behind on responding to findings — please be patient, we are working through the backlog **\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable. **Reports from scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits (at this point we don't consider these security problems)\n - Missing cookie flags on non-sensitive cookies\n - Missing CSRF tokens on forms (unless you have a proof of concept, many forms either don't need CSRF or are mitigated in other ways) and \"logout\" CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n\n\n***Thanks for helping us fight the good fight!***\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":"2016-11-14T23:15:05.521Z"},{"id":2407022,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. **Please note that due to this being a new program, we are receiving a very high volume of reports, most of which are duplicates. It may take us several days to respond while we work through them.**\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - Vimeo's official **Mobile apps**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable. **Reports from scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - User enumeration\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits (at this point we don't consider these security problems)\n - Missing cookie flags on non-sensitive cookies\n - Missing CSRF tokens on forms (unless you have a proof of concept, many forms either don't need CSRF or are mitigated in other ways) and \"logout\" CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n\n\n***Thanks for helping us fight the good fight!***\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":"2016-03-24T19:22:38.398Z"},{"id":1432166,"new_policy":"**Vimeo's Responsible Bug Disclosure Policy**\n\nVimeo engineers work hard to ensure that our site and users are 100% safe and sound. But nobody's perfect. Should you encounter a security vulnerability in one of our products, we want to hear from you. \n\nBefore submitting a report, please review our guidelines below as to what constitutes a security vulnerability, and how we'd like you to go about finding them. Once you've filed a report, we promise to work expeditiously to evaluate and resolve any valid bugs. **Please note that due to this being a new program, we are receiving a very high volume of reports, most of which are duplicates. It may take us several days to respond while we work through them.**\n\nAt the moment we are awarding bounties on merit, at our discretion. Any patched vulnerabilities gets a mention on our [Bug Hall of Fame](https://vimeo.com/about/security).\n\n**Scope**\n\n - The Vimeo website at **vimeo.com**\n - The Vimeo embedded player hosted at **player.vimeo.com**\n - The [Vimeo API](https://developer.vimeo.com/api) hosted at **api.vimeo.com**\n - Vimeo Pro portfolios hosted on **vimeopro.com**\n - Upload endpoints such as **\\*.cloud.vimeo.com**\n - [Vimeo On Demand](https://vimeo.com/ondemand) hosted sites \n - Legacy API endpoints such as vimeo.com/api\n\n**Rules**\n\n - To receive credit, you must be the first reporter of a vulnerability\n - Follow the [HackerOne Vulnerability Disclosure Guidelines](https://hackerone.com/disclosure-guidelines)\n - **Don't** attempt to access other people's private data. **Basic Vimeo accounts are free**, as well as the privacy  features, so **setting up example cases with throwaway accounts should be easy**\n - **Don't** use automated tools or scanners\n - **Don't** DDoS us\n\n**Qualifying vulnerabilities**\n\nPlease take the time to make a proof of concept that shows how a particular vulnerability is exploitable. **Reports from scanners will not be accepted.**\n\nWe are primarily interested in exploits that could compromise user privacy or expose content in unintended ways.\n\n**Non-qualifying vulnerabilities**\n\n - **Mobile apps**\n - User enumeration\n - Anything on `pages.email.vimeo.com` \n - Reports from automated tools or scans\n - Presence of autocomplete attribute on web forms\n - Missing rate limits (at this point we don't consider these security problems)\n - Missing cookie flags on non-sensitive cookies\n - Missing CSRF tokens on forms (unless you have a proof of concept, many forms either don't need CSRF or are mitigated in other ways) and \"logout\" CSRF attacks\n - Missing http security headers (unless you deliver a proof of concept that leverages their absence)\n - Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept -- and not just a report from a scanner)\n - Reports of `window.opener`redirects\n - Open SMTP redirects (just because it _looks_ like you can use our servers doesn't mean its true-- unless you have a PoC)\n\n\n***Thanks for helping us fight the good fight!***\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":"2015-05-05T20:05:53.241Z"},{"id":1415582,"new_policy":"\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":"2015-04-28T20:13:51.923Z"}]