Clean Email welcomes responsible reports that help protect our users and services. This policy explains what qualifies, what a report must contain, and how we assess rewards.
This program covers:
Findings must affect the latest public release, including officially released public betas, on a supported platform.
Other websites, subdomains, administrative systems, and third-party services are not automatically included. If you are unsure whether an asset is covered, contact support@clean.email before testing it.
A security vulnerability allows an attacker to cross a security boundary and gain access or perform actions they are not authorized to perform.
Examples include but are not limited to:
Reports must demonstrate a concrete, reproducible attack path and resulting impact. Identify the attacker’s required access, any user interaction, the protection being bypassed, and the unauthorized outcome.
A vulnerability name, CWE reference, severity score, scanner warning, or code excerpt does not establish exploitability by itself.
Please do not access real customer data or cause harm. Use accounts and data you control. A minimal proof of concept or verifiable technical evidence sufficient for us to reproduce the issue safely is acceptable. If further verification would require unsafe testing, stop and contact us.
“Tehoretical” or “possible” attack vectors do not qualify as a viable report. The following ordinarily do not qualify unless you can demonstrate an attack path and security impact:
Third-party component vulnerabilities may qualify only if their exploitable impact in Clean Email is demonstrated.
Automated and AI-assisted research is welcome, but findings must be validated. Unverified generated reports and scanner output alone do not qualify.
We may adopt a hardening recommendation or change an intentional configuration. Making a change does not, by itself, validate a vulnerability claim or create bounty eligibility unless an attack path was demonstrated.
We welcome reports showing that an exposed credential or missing restriction permits unintended use of resources billed to Clean Email.
These findings are assessed according to their verified financial impact and may receive a discretionary reward. They do not automatically establish exposure of customer data.
The presence of a key in an application is insufficient by itself. Clean Email contains multiple public service access keys by design. Reports must establish what unintended access or usage it permits. Include relevant responses and timestamps; an HTTP success code alone may not prove successful API execution.
Do not generate substantial charges, exhaust quotas, or repeatedly invoke billable services. Contact us before testing if verification could incur costs.
Email support@clean.email with “Security report” in the subject.
Include:
Clearly distinguish demonstrated impact from hypothetical consequences. Redact personal information and secrets; ask us for a suitable private transfer method if sensitive material is necessary for verification.
Submit independent issues separately. Describe related findings and exploit chains together, identifying any shared root cause.
Use accounts, mailboxes, and data you own or have explicit permission to use. Keep testing minimal.
Do not access other users’ accounts, modify their data, send messages to uninvolved users, conduct social engineering or credential attacks, establish persistence, or perform disruptive testing such as denial-of-service, load testing, or quota exhaustion.
If you unexpectedly encounter another person’s data, stop testing and notify us promptly. Do not continue accessing, retaining, or sharing it.
We consider good-faith research conducted within this policy authorized and will not pursue legal action solely for that compliant research. This authorization applies only to systems we control and does not authorize testing third-party systems.
We assess reports based on reproducibility, scope, realistic exploitability, verified impact, and compliance with this policy. We may request additional evidence or classify a report as validated, informational, duplicate, previously known, out of scope, or not reproducible.
Reward decisions consider:
Only the first sufficiently complete report establishing a previously unknown issue is normally eligible. Multiple reports describing the same root cause may be treated as one finding. Report volume does not increase a reward.
Informational findings and hardening recommendations ordinarily receive no monetary reward. Severity labels and scores supplied by researchers do not determine eligibility or payment.
The responsible team decides whether to award a bounty and its amount. Any award and payment arrangements will be communicated directly to the researcher. Support staff forwarding reports do not make bounty decisions.
Report privately before publishing details. Allow at least 90 days from receipt for investigation and remediation, unless we agree to earlier disclosure.
Contact us to coordinate publication. If additional time is needed, we will explain why and discuss an extension. Never publish customer information, active credentials, or other confidential data obtained during research.
We may revise this policy. Reports will be assessed under the policy applicable when they were submitted; later exclusions and requirements will not be applied retroactively.
For reports or scope questions, contact support@clean.email.