Banner object (1)

Hack and Take the Cash !

800 bounties in database
  Back Link to program      
Livestream logo
Hall of Fame


100 $ 

In Scope

Scope Type Scope Name
android_application com.livestream.livestream
ios_application 493086499
other Out of scope: any attacks of the install process, that require additional configuration files, dll, etc that are put onto the machine via virus, malware, confidence, etc.
web_application *
web_application *

Out of Scope

Scope Type Scope Name
hardware The hardware side of Livestream has been sold to a non-Vimeo company. Even though we have integrations with much of it still, we can not take reports for it.
other Its a 3rd party owned bucket, AMP.LIVE, publicly available. The content in there is made to be publicly available.
other WPEngine requires a different contract if you include it on a bug bounty program
web_application This is a 3rd party (AMP.LIVE).


Livestream's Responsible Bug Disclosure Policy

Livestream 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. After 3 medium or higher code based fixes, you can request to get a mention on our Bug Hall of Fame.

Public Disclosure Process and Policy

  • Livestream reserves the right to approve or deny any request for disclosure.
  • Livestream has a multi-level internal approval process for all valid disclosure requests.
  • ONLY RESOLVED reports requested by the original reporter are eligible for disclosure (duplicate reports are not eligible).
  • 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) .
  • 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.

Scope Priorities and Disclaimer

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

Unique Out-of-Scope Domain

* is listed as in scope because almost all subdomains are in scope.

Hardware / IoT

No hardware is considered within scope.


  • To be considered the original reporter of a vulnerability :
    • You must be able to prove that there is a vulnerability using your own account(s).
    • Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
    • Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
    • Please provide detailed reports with reproducible steps.
    • If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward. Videos work best (No need to overlay music), Text with screenshots second, plain text last.
    • HackerOne and Livestream must be able to reproduce it
    • It must go to “TRIAGED” state and be paid the post triage acceptance bounty reward of $100 (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”)
  • Don 't attempt to access other people's private data. Trial Livestream accounts are free ( __) , as well as the privacy features, so setting up example cases with throwaway accounts should be easy
  • Don 't use automated tools or scanners. Reports will be close as N/A.
  • Don 't DDoS or otherwise attack us in a way that would disrupt service for our customers

Qualifying vulnerabilities

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 guidelines to categorize security issues.

Critical: most impactful, Remote code execution, SQLi, root access to any systems

High: Insecure direct object references, stored xss that can be used against logged in users, account authentication issues (bypass etc)

Medium: stored or reflected cross site scripting, other novel bugs that have a security impact to many users

Low: CSRF missing from non excluded functions, other security issues that impact only a small subset of users

Wont fix: information disclosure, see also other non qualifying vulnerabilities

We do appreciate reports containing CVSSv3 formatted scores ( __)

Reports from automated scanners will not be accepted.

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

Non-qualifying vulnerabilities

  • User enumeration
  • Thumbnail / Description metadata leakage or similar
  • Anything on `*’ (Unless its is an LS<>Vimeo Integration or chained issue)- Otherwise these reports belong over at
  • Anything on `*’ - these reports belong over at
  • Reports from automated tools or scans
  • Presence of autocomplete attribute on web forms
  • Missing rate limits, unless it can lead to account takeover
  • Missing cookie flags on non-sensitive cookies
  • Logout CSRF attacks
  • 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.openerredirects
  • Open SMTP redirects (just because it looks like you can use our servers doesn't mean its true-- unless you have a PoC)
    • Email related attacks including spoofing or any issues related to SPF, DKIM or DMARC
    • Missing security headers including (content security policy) which do not lead directly to a vulnerability
    • 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 including self-xss
    • Homoglyph Attack, we feel this is a browser issue
    • Missing HTTP security headers (unless you deliver a proof of concept that leverages their absence)
    • Self-XSS (XSS exploits that cannot maliciously affect users besides yourself)
    • Denial of service attacks, do not perform them
    • 3rd party sites used by Livestream
    • 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 Livestream
    • Brute forcing
    • Re-reports due to improper verification
    • Issues where you would have to have access to the users X (Phone, email, 2FA token, etc)
    • Compromises or modifications prior/during/after the Livestream Studio/Producer install. The installer is a 3rd party program. We are interested ONLY in the actual Studio/Producer software exploits itself. No additional command line options, no additional configuration or dll inserted by any mean, etc.
    • Issues where the users X (Phone, email, etc) have been rooted, malwared, bot'd, etc.
    • Downloading or installing mobile versions from anywhere other than their associated official stores.
    • Any integration we have to hardware (the hardware business was sold)
    • If you are or have been banned on any Vimeo (/vimeo, /vhx, /livestream) program


Livestream will make a best effort to meet the following SLAs for hackers participating in our program:

  • Time to first response (from report submit) - 2 business days
  • Time to triage (from report submit) - 2 business days (unless more information is needed from the hacker)

We’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. We do find, especially in Livestreams case, that when they fix something they are quick to notify us.


Livestream 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 Livestream. Items in Triage state alone will NOT be considered accepted by the program until final disposition is made by Livestream, 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 Livestream. 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).


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

Google Play Security Rewards Program

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

Disclosure Policy

  • 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.
  • Follow HackerOne's disclosure guidelines __.

Safe Harbor

Thank you for helping Vimeo, Inc. and its subsidiaries (Of which Livestream is one) (“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 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.

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

**Thanks for helping us fight the good fight! *

FireBounty © 2015-2019

Legal notices