Updates

November 2025

• We made the program public and doubled the maximum bounty for critical vulnerabilities! 💰💰

July 2025

Launch of the program.

Zivver

Zivver offers secure communication solutions that help prevent data leaks. The Saas solution offers a web application and clients for Outlook, Outlook Web Access and Gmail. The product has:

• Zero-knowledge encryption (whitepaper)
• Human error prevention
• Large file transfer
• Email revocation
• Secure eSignatures
• Proof of Delivery
• Several enterprise features as role based access, SSO and reporting

With this bug bounty program, we want to reinforce our commitment to security and reward security researchers for helping us protect our customers' data.

Program Rules

Zivver wants to increase the security of its products by inviting security researchers to analyze the implementation of security measures in its product and to identify existing vulnerabilities. In order to achieve this goal together, it is important to us that the following rules are adhered to.

• Only attempt attacks using an account associated with your YesWeHack email alias. Any breach attempts from other accounts might be considered a threat to our customers and the associated accounts will be shut off without further notice. Other accounts than the ones associated with your YesWeHack email alias will not necessarily receive safe harbor protection.
• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue may not be marked as triaged.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only triage the first report that was received (provided that it can be fully reproduced).
• Multiple vulnerabilities caused by one underlying issue will be treated as one valid report.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Causing load-based issues by submitting an unreasonably large number of requests or transferring an excessive amount of data.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service.
• Only interact with accounts you own or with explicit permission of the account holder.
• Do not change passwords of accounts (unless it’s your own) or delete other accounts.
• Do not publish (even partially) any vulnerabilities that are found.

🚫 Important!

Do not claim any domain related to YesWeHack (yeswehack.com, yeswehack.ninja) in the product once you received a business account!
This will make signups for other hunters impossible using their YesWeHack email alias. We will delete any account that claims any of those domains without notification.

Reward Eligibility

We are happy to thank everyone who submits valid reports to improve the security of our service, however only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability (see below).
• Show meaningful impact: reports that note deviations from security 'best practices' but cannot present a clear proof of risk —such as flagging a missing X-Content-Type-Options header on a page that never handles user content—are ineligible for rewards, though we may accept the report for its informational value. This policy ensures we concentrate bounty funds on genuine, exploitable threats rather than theoretical issues.
• Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through YesWeHack.
• The vulnerability report must contain the following elements:
  1. A clear textual description of the vulnerability, how it can be exploited, its security impact and remediation advice.
  2. A proof of the exploitation of the vulnerability (e.g. screenshots, proof of concept code).
  3. The preconditions and steps required to reproduce the issue including code snippets, commands, request information, payloads, etc.
• You must not be a former or current employee of our company or one of its contractors.

XSS Reporting Requirements

Please note that for any reports involving Cross-Site Scripting (XSS), a basic proof-of-concept such as a JavaScript alert box (e.g., alert(1)) will not be considered sufficient for triage or reward. To qualify for a valid report, you must demonstrate a clear and actionable impact resulting from the XSS vulnerability. This includes, but is not limited to:

• Performing actions on behalf of another user (e.g., creating a new user account or modifying user settings)
• Exfiltrating sensitive data (e.g., sending authentication cookies or session tokens to an external server)
• Bypassing security controls or escalating privileges

The goal is to understand the real-world risk and exploitability of the issue, so please ensure your report includes a well-documented and impactful demonstration.

⚠️ Popular duplicate topics:

When reporting vulnerabilities, please consider (1) attack scenario/exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• MULTIFACTOR AUTHENTICATION (MFA) 'BYPASS' on the web application (client-side): MFA is intended to be an optional feature, rather than a hard requirement, for Zivver users. While the app may presently appear to enforce a hard requirement for MFA in places, that is not a strategic intent and the design will be re-evaluated in upcoming releases. Please do not report client-side MFA bypass vulnerabilities here.

Useful links

• Zivver signup page
• Zivver knowledge base
• Zero-knowledge encryption whitepaper