Vimeo's Bug Bounty Program Policy

Vimeo 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.

Before 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.

Bounties are awarded based on merit at our discretion.

Rules

Requirements for your submission to be eligible for a bounty reward:

• 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.

• 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.

• The underlying issue must be unique, ie. multiple vulnerabilities caused by one underlying issue will be awarded one bounty.

• 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.

Suggestions to ensure fast processing and maximum bounty:

• Communicate respectfully and professionally at all times**

• Provide detailed reproducible steps. This is important.

• Explain the potential impact

• Submit only one vulnerability per report, unless you need to chain vulnerabilities to provide impact.

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.

DO NOT use automated tools or scanners. Reports as such will be closed as N/A.

DO NOT DDoS or otherwise attack us in a way that would disrupt service for our customers.

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.

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.

• We highly recommend that you sign up for any throwaway accounts using your @wearehackerone.com learn more 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).

Rules for us

Vimeo and HackerOne will make best efforts to meet the following SLAs for hackers participating in our program:

• HackerOne aims to complete initial triage within 2 days after you submit your report

• Vimeo will complete final triage within 3 business days after the H1 triage

• Vimeo will award the full bounty immediately once we confirm that it’s not a duplicate and we intend to fix it

Triage and Payout Process

Vimeo 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.

Please 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.

Focus areas

We’re open to accepting any valid in-scope security issue, but we’re especially interested in the following issues:

• 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.

• Injection (OS, SQL etc)

• Authentication & OAuth Vulnerabilities

• XSS

• Video privacy bypass

Note, 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.

Criteria for premium accounts

Basic Vimeo accounts are free, but Vimeo offers additional features to our customers via our paid plans. 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.

To be eligible for a paid account, you must meet at least one of the following qualifications:

• 1 Critical severity submission in Vimeo

OR

• 2 High or higher severity submissions in Vimeo

OR

• 3 Medium or higher severity submissions in Vimeo

Qualifying vulnerabilities (in-scope)

Please 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.

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.

| Severity (Minimum) | Severity (Maximum) | Vulnerability Type | Bug Examples | |

|--------------------|--------------------|----------------------------------------------------------|-----------------------------------------------------------------------------------------|---|

| Critical | Critical | OS Shell Execution | Remote Code Execution; Code Injection; OS Command Injection | |

| Medium | Critical | SQL Injection | SQL Injection (Inband SQLi; Blind SQLi) | |

| Medium | Critical | Server-Side Request Forgery | SSRF (unrestricted); Content-Restricted SSRF; Error-based SSRF (true/false); Blind SSRF | |

| Low | Critical | Incorrect Permission Assignment | IDOR; Horizontal Privilege Escalation; Vertical Privilege Escalation | |

| High | Critical | Improper Restriction of XML External Entity Reference | XXE | |

| High | Critical | Uncontrolled Format String | Insecure Deserialisation | |

| Medium | High | Inconsistent Interpretation of HTTP Requests | HTTP Request Smuggling | |

| Low | Critical | Inclusion of Functionality from Untrusted Control Sphere | Server Side Includes Injection; Local File Inclusion; Directory Traversal | |

| Low | Critical | Missing Authentication for Critical Function | Exposed Administrative Interface | |

| Low | Critical | Information Exposure | Exposure of PII; Credentials on GitHub; Confidential Information Exposure | |

| Low | Critical | Incorrect Authorization | Authorization Bypass; Account Takeover | |

| Medium | Medium | Download of Code Without Integrity Check | S3 Bucket Upload | |

| Medium | High | Cross-Site Scripting | Different type of XSS | |

| Low | High | Cross-Site Request Forgery | State-Changing CSRF; Non-State-Changing CSRF | |

| Low | Medium | Misconfiguration | Subdomain Takeover; Dangling DNS Record | |

| Low | Medium | CRLF Injection | CRLF Injection | |

Non-qualifying vulnerabilities (out-of-scope)

• User enumeration

• Open redirect (Unless chained to show an impact)

• Reports from automated tools or scans

• Missing rate limits, unless it can lead to account takeover

• Missing cookie flags on non-sensitive cookies

• Logout CSRF attacks (unless chained to show an impactful exploit)

• Reports of insecure SSL/TLS ciphers (unless you have a working proof of concept -- and not just a report from a scanner)

• Reports of insecure crossdomain.xml configuration (again, unless you have a working proof of concept and not just a report from a scanner)

• Reports of window.opener redirects

• Open SMTP redirects (just because it looks like you can use our servers doesn't mean it's true-- unless you have a PoC)

• Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC

• Clickjacking on static websites

• Content spoofing / text injection

• Use of a known vulnerable library (without evidence of exploitability)

• Vulnerabilities affecting users of outdated browsers or platforms

• Social engineering attacks

• Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)

• Self-XSS

• Denial of service attacks, do not perform them

• 3rd party sites used by Vimeo

• Subdomain takeovers where someone has signed up for an account, forwarded to an external site that doesn't exist/can be compromised

• RCE on sites that link or are redirected from Vimeo

• Exploits that require the attacker to have access to the user’s device or external account (phone, laptop, email, 2FA token, etc)

• Issues where the user’s device or account (phone, laptop, email, etc) have been rooted, malwared, bot'd, etc.

Disclosure Policy

Vimeo understands that disclosure helps the infosec community and strengthens your professional reputation.

Rules

• If you wish to disclose a specific issue, you must receive explicit prior approval from Vimeo.

• Please do not discuss any vulnerabilities, even resolved ones, outside of the program at any time without express consent from Vimeo.

How to request permission

Please request a disclosure by commenting on the report within HackerOne and we’ll kick off an internal disclosure process promptly.

Restrictions

• Vimeo reserves the right to approve or deny any request for disclosure for any reason and at our sole discretion.

• 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.-

• Duplicate reports are not eligible for disclosure. Only the original reporter is eligible for disclosure

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. Furthermore, failure to comply with these rules may result in a program ban for all company properties (Vimeo, Livestream, VHX, Magisto) .

In addition to these rules, please also follow HackerOne's disclosure guidelines

Safe Harbor

Thank 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.

We 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.

If 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.

To the extent that our applicable online terms of service are inconsistent with this Safe Harbor Statement, then this Safe Harbor Statement shall control.

Please note that this Safe Harbor Statement does not extend to systems, services, and applications that we do not control.

We 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.

Thanks for helping us fight the good fight!