submit bug report: https://app.greenhouse.io

About#
Greenhouse is software to optimize your entire recruiting and onboarding process. Find better candidates, conduct more focused interviews, and make data-driven hiring decisions.
Through this security bug bounty program we collaborate with security researchers worldwide to identify and mitigate security vulnerabilities in our platform.
Find a security flaw in Greenhouse? Submit a report here. If we confirm it and it's within the guidelines below we'll send you a reward.
Guidelines#
Rewards are contingent on you operating within these guidelines and are granted at the discretion of Greenhouse:
Domains eligible for reward: app.greenhouse.io, api.greenhouse.io, boards.greenhouse.io, greenhouse.io, onboarding.greenhouse.io
If you're using your company's Greenhouse account, testing is not permitted without prior written authorization from Greenhouse.
We do not provide test accounts.
Only issues that might impact the security of our data and supporting systems are in-scope; usability, functionality, and programming bugs are out-of-scope.
Social engineering attacks against employees are out-of-bounds and will not be accepted.
Any research or testing that impacts our application's performance or exposes confidential information to anyone else is out-of-bounds and will not be accepted.
Output copied from any scanning, auditing, or attack tool without supporting evidence or a proof-of-concept will not be accepted as original work and will not be accepted.
If we catch you using a scanner against our applications you may be subject to being banned from our bounty
You are not an individual on, or residing in any country on, any U.S. sanctions lists.
You must provide a clear, detailed, and working proof of concept (PoC) that exploits the security issue
Submissions without a working PoC will likely be rejected
Response Times#
Action   Target   
Time to first response   3 days   
Time to triage   7 days   
Known Issues, Ineligible For Reward#
These issues are not eligible for reward due to design decisions, limitations of third-party services we use, etc.
Login/Logout CSRF/XSRF
Email configuration (SPF, DKIM, DMARC)
SSL/TLS ciphers or denial of service issues
Diffie-Hellman parameters
Clickjacking/UI Redress on boards.greenhouse.io (X-Frame-Options) or login pages
No Strict-Transport-Security header
Content Security Policy configuration issues
Issue related to links or forms outside of the greenhouse.io or grnh.se domains
Broken links on our company landing page, blog or marketing webpages
Problems related to widely publicized CVE's
DDoS
Downstream providers we do not control (e.g. Marketo)
Denial of service issues on form input length
io.greenhouse.recruiting (Mobile Applications)

submit bug report: http://mega.co.nz

Immediately after our launch, our security model and implementation came under intense crossfire, most of which turned out to be damp squibs. We have, however, also suffered three direct hits, and we want more! To improve MEGA's security, we are offering rewards to anyone reporting a previously unknown security-relevant bug or design flaw.
How much can I earn?
We offer up to EUR 10,000 per bug, depending on its complexity and impact potential.
Who is eligible?
The first finder of the bug. Bugs reported by third parties are typically not considered for a reward.
What is the disclosure policy?
You are free to disclose your finding to the general public after we confirm to you that the issue has been resolved.
Who makes the decision?
The decision whether you qualify and how much you earn is at our discretion, and while we will be fair and generous, you agree to accept our verdict as final.
How do I submit my finding?
Send an e-mail to bugs@mega.co.nz.
Policy: https://mega.co.nz/#blog_6
Domains
mega.co.nz
mega.nz

submit bug report: https://www.exodus.com

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug/vulnerability. The Google Bug Hunters University guide may be useful in considering whether an issue has security impact.
Submit one vulnerability per report. WARNING: If the same exploit occurs across multiple endpoints, please include those endpoints under your single submission. Do NOT file multiple reports for the same exploit.
Multiple vulnerabilities caused by one underlying issue will be awarded one bounty (see above item).
When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
Social engineering (e.g. phishing, vishing, smishing) is prohibited.
Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service (including denial of service). Only interact with accounts you own or with explicit permission of the account holder. If you do accidentally cause some noticeable interruption of service, please immediately email us so we can handle it accordingly hack1@exodusmovement.opsgenie.net and please include the subject title "HackerOne Outage: <description>" for the alert to trigger.
Rewards
Reward decisions are up to the discretion of Exodus.
Minimum reward for a vulnerability report: $100
Maximum reward for a vulnerability report: $100,000
In scope vulnerabilities
Technical vulnerabilities or security-related problems in any of our company's internet public surface (websites and subdomains underneath Exodus's control)
Technical vulnerabilities or security-related problems in our company's Desktop Wallet application.
External Dependencies
Exodus makes use of a number of open (and closed) source libraries. If you discover a vulnerability in
an open source dependent library or OS component, we advise you to follow responsible disclosure procedures directly with the library or OS vendor. We will not pay bounties on undisclosed vulnerabilities in dependent components. However, if one of those libraries included you can demonstrate a serious vulnerability of any of our software/servers as a result of that library with a working Proof of Concept, we will on a case-by-case basis consider this in-scope and grant rewards.
Out of scope vulnerabilities
If you find a vulnerability that is not part of the In scope vulnerabilities, please report it and we will investigate it and depending on the severity of the vulnerability, you will be listed in our Hall of Fame and may be eligible for a reward. Any rewards for out of scope vulnerabilities will be granted on a case by case basis.
The following issues are currently considered out of scope:
Weaknesses that would require Email Phishing or Social Engineering
Attacks requiring MITM or physical access to a user's device.
Previously known vulnerable libraries without a working Proof of Concept.
Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
Sites/Software that is run entirely by another company that is simply subdomain-ed or linked to from our company. Eg: Constant Contact, Zendesk, etc.
Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
Vulnerabilities only affecting users of outdated or unpatched browsers or wallets [Less than 3 stable versions behind the latest released stable version]
Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
Package include/dependency vulnerabilities without demonstrating a vulnerability.
Issues that require unlikely user interaction
(KNOWN ISSUE) Disclosure of methods/endpoints/api keys involving 3rd party blockchain APIs (ex. bitcoin, tezos, waves etc) including known embedded API key, and known outdated swaggerhub / openapi issue. (also mentioned in specific scopes for increased awareness)
The following issues are currently considered do not attempt without permission:
Extended testing/attacks of Exodus servers or infrastructure
Rate limiting or brute-force attacks on exodus backend infrastructure
Any activity that could lead to the disruption of our service (DoS).
To request permission, please email bugbounty@exodus.com and mention the details of your test including what endpoint(s) you will be hitting, what type of scan/attack/etc you would like to try, and what you're trying to achieve. We will respond within 2 working days, ideally less to your request. As long as it is reasonably well thought out and we don't see a risk on our end, we will approve the request.
Safe Harbor
Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not report to any law enforcement agencies or initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, Exodus will take steps to make it known that your actions were conducted in compliance with this policy.
Thank you for helping keep Exodus and our users safe!

submit bug report: https://eure.jp

Eureka Bug Bounty Program Terms
Security is a priority at Eureka. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.
Your participation in our Bug Bounty Program is voluntary and by invitation-only. By joining our Bug Bounty Program, submitting a report or otherwise disclosing a vulnerability to us (“Submission”), you are indicating that you have read and agree to follow the rules set forth on this page (“Program Terms”).
If (i) you do not meet the eligibility requirements below; (ii) you breach any of these Program Terms or any other agreements you have with Eureka or its affiliates; or (iii) we determine that your participation in our Bug Bounty Program could adversely impact us, our affiliates or any of our users, employees or agents, we, in our sole and absolute discretion, may remove you from our Bug Bounty Program and disqualify you from receiving any benefit of our Bug Bounty Program.
Confidentiality
Regardless of the manner (whether as a direct result of you finding and/or investigating a security bug in our in-scope applications/infrastructure or received/collected through other methods) and timing (whether after or before you joined the Bug Bounty Program) in which it was obtained, any information about us, our services, our affiliates or any of our users, employees or agents in connection with our Bug Bounty Program (“Confidential Information”) must be kept confidential, only used in connection with the Bug Bounty Program and not disclosed to any third party. You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your participation in our Bug Bounty Program and any Submission.
By joining our Bug Bounty Program, you represent and warrant that you have not used and will not use Confidential Information for any purpose other than in connection with the Bug Bounty Program and that you have not shared and will not share such Confidential Information with any third party.
At any time after a Submission is made, Eureka reserves the right to request that you securely and irreversibly delete any data related to such Submission, including, without limitation, any data about us, our services, our affiliates or any of our users, employees or agents.
Upon making a Submission, you accept the responsibility to fully comply with any such request.
Additionally, you agree to securely and irreversibly delete any data related to the Submission immediately upon it no longer being reasonably necessary to retain for the purposes of conveying the impact or scope of the reported issue, after verifying with Eureka that it is no longer necessary, and/or if the Submission is closed, regardless of outcome.
Eligibility to Participate
To participate in our Bug Bounty Program, you must:
Be at least 18 years of age if you test using an account in "Pairs" app, or otherwise be the age of majority in your jurisdiction of residence.
Be at least 13 years old and have the consent of your parent or guardian to participate in our Bug Bounty Program if you are under the age of majority in your jurisdiction of residence.
Not be a resident of, or make a Submission to our Bug Bounty Program from, a country against which the United States has issued export sanctions or other trade restrictions.
Not be in violation of any national, state, or local law or regulation with respect to any activities directly or indirectly related to our Bug Bounty Program.
Not be employed by Eureka or any of its affiliates or an immediate family member of a person employed by Eureka or any of its affiliates.
You are responsible for any tax implications of a reward from our Bug Bounty Program depending on your country of residency and citizenship.
Program Ground Rules
Don’t mass create accounts to perform testing against our applications and services.
Don’t conduct automated testing - under no circumstance is automated testing allowed and will result in disqualification of the security bug(s).
Don’t engage in social engineering (e.g. phishing, vishing, smishing).
Don’t attempt to extort us.
Don’t leave any system in a more vulnerable state than you found it.
Don’t publicly disclose vulnerabilities.
Do respect our users’ privacy.
Do research vulnerabilities and disclose vulnerabilities to us in good faith.
Do be respectful when interacting with our team.
Bounty Eligibility
Eureka reserves the right to decide if the minimum severity threshold is met and whether the vulnerability was previously reported.
To qualify for a reward under this program, you must:
Send a clear textual vulnerability description of the bug along with the steps to reproduce the vulnerability.
Include attachments such as screenshots and proof of concept code as necessary. A clear description and proof of concept helps you prove that the security bug is legitimate and speeds up the reward process.
Be the first to report a specific vulnerability.
Disclose the vulnerability report directly and exclusively to us. Reminder: you are not permitted to disclose vulnerabilities to third parties -- including vulnerability brokers.
Stay in scope.
Do not attempt to elevate privileges, or explore a system beyond the minimum necessary to prove access or attempt to pivot in any way. This will disqualify you from receiving a bounty.
In general, the following would not meet the threshold for inclusion:
Vulnerabilities on sites hosted by third-parties unless they lead to a vulnerability on the main website / application
Denial of service
Social engineering
Spamming
Homographs, RTLO, or other types of UI issues
Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
Click-jacking, or issues only exploitable via click-jacking
Disclosure of known public files or directories (.htaccess, robots.txt, etc)
Third-party vulnerabilities (e.g. Wordpress) that have recently become publicly known will generally be out of scope for a period of 30 days from the public release of an official patch or workaround.
Missing or misconfigured security headers which do not lead directly to a vulnerability
Overly verbose responses (errors, banners, etc.), which cannot be directly used in an exploit
Software version disclosure without proof of exploitability
Reports from automated tools or scans
Lack of certificate pinning, or HSTS
TLS/SSL version, configuration, weak ciphers or expired certificates
Lack of Secure, or HTTPOnly flags on cookies
Lack of, or weak, Captcha, or rate-limiting
Tap-jacking
Tab-nabbing
SPF/DKIM/DMARC related issues, including missing SPF records on subdomains
Scenarios that require unlikely user interaction and/or outdated OS or software version
Self-XSS
Login/Logout CSRF
Unrestricted file uploads without a clear impact, beyond resource consumption, DoS, undesirable content, etc.
Third-party API Keys/Secrets embedded in mobile applications, without a clear impact, as many third-parties require this for their own client attribution purposes.
The ability to obtain multiple promotional items by opening multiple accounts
Most GPS spoofing related issues
Attacks against corporate IT infrastructure (e.g. firewalls and their software)
Attacks against employees (phishing, stealing laptops, physical security issues, etc.)
Host header injection without a clearly exploitable condition
Mobile client issues requiring a rooted device and/or outdated OS version
Attacks requiring MITM or physical access to a user's device.
Comma Separated Values (CSV) injection without demonstrating a vulnerability.
Program Updates and Licenses
We may modify the Program Terms or cancel our Bug Bounty Program at any time in our sole and absolute discretion.
As a condition of participation in the our Bug Bounty Program, you hereby grant Eureka and its affiliates a perpetual, irrevocable, worldwide, royalty-free, transferrable, sublicensable and exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create derivative work from, make, use, sell, offer for sale and import the Submission, as well as any materials submitted to Eureka in connection therewith, for any purpose. You should not send us any Submission that you do not wish to license to us. You hereby represent and warrant that the Submission is original to you and you own all right, title and interest in and to the Submission.
Domains
*.pairs.lv
*.pairs.tw
*.pairs-korea.com
*.pairs.kr
*.eure.jp

submit bug report: https://www.cloudbees.com

CloudBees takes security very seriously and investigates all reported vulnerabilities. We want to keep our software and services safe for everybody. We welcome working with the security community to resolve valid issues promptly.
Bounty Program
CloudBees offers monetary bounties for reports of qualifying security vulnerabilities. Reward amounts will vary based on the severity of the report, and eligibility is at our sole discretion. Not all submitted items will be in scope for a reward. Duplicate issues will be merged.
Our determination of what is in scope or not is final. Awarded bounties are not negotiable, including the decision to not pay out a bounty.
Program Scope
CloudBees oversees a large scope of products. Some projects fall under the scope of the open source Jenkins project, and as such will be handled by that security team following their documented processes at https://jenkins.io/security/. Any submissions to the CloudBees HackerOne program that fall under the scope of the Jenkins project will be forwarded to that team for further analysis, and follow-up will be handled via that team. Such reported vulnerabilities MAY be subject to bounties at the discretion of the CloudBees security team.
Within the CloudBees portfolio, the following products are in scope:
CloudBees Console (app.cloudbees.com, id.cloudbees.com, and associated services)
CloudBees CI and associated plugins (aka CloudBees Core)
CloudBees CD (aka Flow)
CloudBees Feature Management (FM, aka Rollout - app.rollout.io, x-api.rollout.io, push.rollout.io and analytics.rollout.io)
CloudBees CodeShip (SaaS service - codeship.com)
CloudBees Websites (www.cloudbees.com, support.cloudbees.com)
For a more detailed list, see “Scopes” (visible only to invited testers). Vulnerabilities reported against unlisted domains MAY be subject to bounties at the sole discretion of the CloudBees security team.
Please note that just because you find the same issue within multiple domains in our portfolio, it does not mean we will treat them as separate issues. Please don't open multiple tickets for the same issue for each domain, as we will just mark them as duplicates
Testing accounts and traffic categorisation
When performing testing on our SaaS applications, please ensure the testing accounts registered on our applications follow either format below. Not following this guidance might be a reason for disqualifying your finding.
Use a +h1 suffix on the username, for example “<username>+h1@<domain>”; OR
Use the @wearehackerone.com e-mail address assigned to your HackerOne account
Researchers must add headers to requests such as: “X-HackerOne-Research: [H1 username]”
Other good practices on this can be found (although not mandatory) here
Third-party applications behind CloudBees domains
At CloudBees we rely on many third-party SaaS applications to help us deliver final services or products. Many of those might be behind domains we control such as the list below, although not limited to it:
http://id.cloudbees.com
http://support.cloudbees.com
http://feedback.cloudbees.com
Our stance on such applications is that they are partially in-scope. Issues related to how CloudBees has configured and integrated with these services will be considered in scope. Testers reporting flaws that lie fully within the third party service will be redirected to the security programs of the respective service. The CloudBees security team makes the final determination of whether a report is in scope.
Consider the case of exposed storage buckets, for example. We welcome reports of misconfiguration issues, but if there is a flaw in the core storage service, the best target for such a report would be the cloud provider since they are in the best position to fix it.
We will assess the reports the same way we do it with other reports, although if we don’t find any data compromise on such applications it is unlikely we will take it as a report for our program.
Areas of highest interest
We are most interested in, and will pay higher bounties for:
OWASP top 10 related issues, such as demonstrated XSS
Anything that allows bypass of the authentication system (aside from brute forcing or DoS style attacks)
Things that would expose private user data in ways that are not intended.
Ability to modify or inject content into any of our public web properties
Cloud Security configuration issues related to cloud infrastructure used by our SaaS services (AWS, Google Cloud, Kubernetes), leading to exploitable vulnerabilities.
Areas of lowest interest
We are not particularly interested in:
Blatant dumps of information from scanning tools. Do not dump your burp suite findings with links to public pages about why that finding is bad. You must demonstrate an actual exploitable issue.
CVEs for versions of software you may identify we are running unless you can point to an actual vulnerability
Reports of best practices you feel CloudBees should be following
Reports involving low or medium issues surrounding our authentication/login system (including things like best practices, rate limiting, etc).
Reports of sub-domain takeovers or dangling domains (will likely be pay low at most)
Common Reports we get that are out of scope
Any and all reports regarding password complexity
DKIM/SPF/DMARC/etc settings for email of domains we own
Clickjacking on pages with no sensitive actions.
Unauthenticated/logout/login CSRF.
Attacks requiring MITM or physical access to a user's device.
Previously known vulnerable libraries without a working Proof of Concept.
Comma Separated Values (CSV) injection without demonstrating a vulnerability.
Missing best practices in SSL/TLS configuration.
Any activity that could lead to the disruption of our service (DoS).
Content sniffing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
Open redirects unless there's an actual security issue associated with it. Manually changing the URL in a redirect is not sufficient cause for a security issue. Tampering with an existing redirect that legitimately tricks an actual user to a different site IS valid.
Information disclosure-looking vulnerabilities for keys and tokens that are supposed to be client/browser bound.
While researching we ask that you do not perform the following:
Any type of Denial of Service
Spamming/Messaging
Social Engineering attempts on CloudBees employees or contractors
Any physical attempts to access to CloudBees offices
Disclosure Policy
As this is a private program, please do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organisation.
Follow HackerOne's disclosure guidelines.
What we expect from you
Strictly follow this policy and the H1's (code of conduct](https://www.hackerone.com/policies/code-of-conduct)
What to expect from us
Our goal is to triage your report as per the program response targets. We will work with our engineering teams to take scope of severity, business impact, and how we fit any potential fixes into our work queue. Please note that most reported items are not business critical, and as such it takes some time for our teams to determine exactly the scope of the issue, and how it will be addressed. Once we have a good idea of how it will be fixed and the overall severity, we will pay a bounty. Our preference is to pay a bounty at the same time we validate resolution of the issue as it allows us to make sure the amount of the bounty is appropriately tied to the actual problem.
In some cases the item filed may be (by our team) considered more of a bug than a security issue. We may still elect to fix and pay out bounties for such items, but there is no particular timeline for addressing them as our product management teams will be scoping them into the product plan details.
While we appreciate your reports, asking the status of when we will respond, fix the item, or post a bounty will not receive a response. Repeated attempts at asking for status of such reports may result in banning from continued participation in our program.
This program page may be updated at any time.
Policy: https://www.cloudbees.com/security-policy