We encourage responsible reports of vulnerabilities found in our websites and apps. We kindly ask that you not publicly disclose any information regarding vulnerabilities until we fix them. Rewards are offered at our discretion based on how critical each vulnerability is.
To report vulnerabilities, contact us at security@missiveapp.com with a detailed description to help us understand and fix the vulnerability as quickly as possible.
Our security.txt can be found here.
Vulnerability requirements
To be considered valid, a submission must demonstrate real, exploitable impact on Missive's in-scope services.
Reports must demonstrate impact beyond what the reporter’s own privileges allow. If the action requires an authenticated session, explain how an attacker would obtain one — “attacker has access to the victim’s session” is not a vulnerability in the application.
Proof of concept required
Every report must include one of the following:
- A working demonstration against your own test account
- Clear, step-by-step reproduction instructions that our team can follow independently
- A video or screenshots showing the exploit in action
Test account identification required
Include the email address(es) of the account(s) used during testing. This allows us to verify that the reported behavior was actually tested against our application. Reports without this information will be returned for clarification.
Demonstrated impact required
The vulnerability must result in at least one of the following:
- Unauthorized access to, modification of, or deletion of another user's or organization's data
- Account takeover or impersonation of another user
- Ability to manipulate a victim into performing unintended state-changing actions (e.g., CSRF, OAuth flow manipulation)
- Bypassing limits
- Server-side exploitation such as remote code execution, SSRF with access to internal resources, or authentication/authorization bypass
Automatic disqualification
The following will be closed without review:
- Raw output from automated scanners without manual verification and demonstrated impact
- Theoretical or speculative vulnerabilities without a working proof of concept
- Reports that claim a protection is missing without verifying — if you report that the application doesn't do X, you must demonstrate that X is actually absent. We will close reports where the described behavior doesn't match reality.
- Informational findings such as version disclosure, missing security headers, or configuration suggestions that don't lead to a concrete exploit
- Behavior that is inherent to the underlying protocol or standard (e.g., OAuth tokens surviving provider password resets, client-side API tokens in mobile apps)
- Business logic or product design decisions such as trial length, account signup flow, or invitation policies that don't result in unauthorized access to another user's data
- Self-inflicted actions on the reporter's own account — if exploitation requires the attacker to already have full authenticated access, the report must explain what additional access is gained beyond what the session already provides
- Duplicate reports reframed as new findings (e.g., submitting trial abuse via plus-aliases separately from trial abuse via multiple accounts)
- Social engineering or phishing attacks against Missive employees
- Denial-of-service (DoS/DDoS) attacks
- Reports that do not include reproduction steps
Out of scope
The following vulnerability classes are excluded from the program. No reward will be offered for reports related to these.
- DMARC, SPF, and DKIM email policies on Missive domains
- Unstripped EXIF metadata in uploaded images
- Missing DNSSEC implementation
- Password reset links not invalidated after new requests
- Issues affecting feedback.missiveapp.com; these should be reported to Canny.io
- Issues affecting status.missiveapp.com; these should be reported to PagerDuty
- Issues affecting missiveapp.com (root domain); these should be reported to Webflow