Vulnerability Disclosure Policy
Our Values
Interfere appreciates the work of security researchers and takes security, trust, and transparency seriously. This program was developed to make vulnerability reporting easier and to recognize the efforts of all people striving to help make the Internet a better place.
If you believe you have found a security vulnerability that could impact Interfere or our users, we encourage you to inform us right away. We will investigate all legitimate reports and do our best to quickly fix the problem.
What we expect from you
By participating in this program, you agree to the following program rules and guidelines. Failure to follow these rules will lead to disqualification from the Interfere Vulnerability Disclosure Program.
- You must make a good faith effort to avoid privacy violations, destruction of data and interruption or degradation of Interfere’s services and products during your research.
- All attacks must be executed against your own Interfere Account. If you need one, please contact us at security@interfere.com.
- Do not perform tests against customers of Interfere.
- Once you find a vulnerability, report it and reach out to us before you use the vulnerability to pivot across multiple in-scope assets.
- Make sure that scanners have a narrow scope set that is limited to authorized Interfere IPs only. Aggressive, overly broad scans or those which include Interfere customer IPs without permission will be considered tests against Interfere customers.
- Do not send unsolicited bulk messages (spam) or unauthorized messages.
- Do not knowingly post, transmit, upload, link to, or send any program or script that might be considered malicious.
- If your report is the product of collaboration, please add your collaborators before the bounty is awarded.
Any of the activities below will result in disqualification from the program permanently:
- Testing against Interfere customers, partners, service providers, suppliers, or vendors
- Social engineering of Interfere employees/contractors, including but not limited to: pre-authenticated clickjacking, phishing, impersonating Interfere in emails or convincing customer support to do something on behalf of another user
- Physical attacks against Interfere employees/contractors, offices, or data centers
- Executing Denial of Service attacks against Interfere
- Publishing, blogging, presenting, or otherwise publicly disclosing a report or its details within 90 days of submission without prior written approval from Interfere. This includes social media posts, conference talks, blog articles, YouTube videos, and any other public channel. Researchers who wish to disclose should coordinate with us per the Disclosure section below.
When submitting a report, we expect that researchers:
- 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.
- Provide a realistic attack scenario including prerequisites for an attack and expected gains after the exploitation. Reports without such a scenario, with unrealistic assumptions, or without meaningful outcomes will not be eligible for reward.
- Submit one vulnerability per report, unless you need to chain vulnerabilities in order to demonstrate impact.
- Avoid salami-style reporting of multiple reports. If you identify the same vulnerability on a subset of our products or multiple similar vulnerabilities on the same products, please submit one holistic report.
- Do not store any Interfere IP or PII information once the report is submitted.
Submitting high-quality reports is highly encouraged and will speed up the triage and award process. Reports that are low quality and unclear will be closed. Please address the following in your report:
- Affected asset : Exact product, domain, repository, file, commit, package version, or endpoint.
- Description of the problem: What the vulnerability is and how it works.
- Security boundary: What trust boundary is crossed and why the attacker should not have that access.
- Attacker model: Required privileges, prior access, approval status, account type, network position, and user interaction.
- Steps to reproduce or Proof of Concept: Clear, reproducible steps using only authorized accounts and assets.
- Impact: What data, actions, or secrets are accessed or modified.
- Default relevance: Whether the issue affects default or documented configuration, or requires unusual setup.
- Production relevance: Whether impact is shown in Interfere production, a supported product, or only a local, demo, or test environment.
- Safety: Confirmation that no testing was performed against Interfere customers, partners, vendors, employees, or third parties.
- Public knowledge: Whether knowledge of this issue is currently public.
Reports that do not clearly identify the affected asset, security boundary, attacker prerequisites, reproduction steps, and meaningful impact may be closed as Informational or Not Applicable. Interfere reserves the right to fix hardening issues without awarding a bounty when the report does not demonstrate a bounty-eligible security impact.
A working Proof of Concept is required for all bounty-eligible reports. No PoC, no bounty. Theoretical vulnerability descriptions, source-code-only analysis, static-analysis findings, or speculative attack narratives without a demonstrated reproduction are not eligible for bounty regardless of the claimed severity. “I can provide a PoC if needed” or “please confirm I am allowed to test” is not a PoC. The PoC must be included with the initial submission or provided promptly upon request. Reports submitted without a PoC may be closed without waiting for one to be produced.
Acceptable PoC formats include: curl commands, scripts (Python, Bash, JavaScript, etc.), step-by-step browser reproduction, video recordings with visible requests and responses, or any other format that allows independent reproduction. The PoC must use only the researcher’s own accounts and authorized test assets.
PoC readability requirement: Proofs of concept must be human-readable and independently verifiable by a security engineer without requiring specialized tooling, deobfuscation, or reverse engineering of the PoC itself. Researchers are welcome to use AI tools to assist in composing their reports, but the PoC code must be clear, commented where non-obvious, and written so that a reviewer can read the script and understand what each step does before running it. Minified, obfuscated, or unnecessarily complex PoC scripts that obscure the attack logic will be sent back for clarification. A good PoC should be short enough to read in under five minutes and should clearly separate setup steps from the exploit trigger. When in doubt, prefer a simple curl command or a short self-contained script over a multi-file framework.
Not all reproduction environments carry equal weight. The environment in which a vulnerability is demonstrated directly affects the severity assessment and bounty eligibility:
| Tier | Environment | Severity Impact | Examples |
|---|---|---|---|
| Production | Interfere-operated production services, live customer-facing endpoints, production APIs | Full severity per bounty table | api.interfere.com, sync.interfere.com, _.mcp.interfere.com, _.internal.interfere.com |
| Staging / Internal | Interfere-operated staging, internal tooling, or pre-production environments | Full severity if data or access is real; reduced if test-only | _.staging.interfere.com, _.cfdata.org internal services, staging API endpoints |
| Local / standalone | self-hosted environments with no Interfere runtime constraints | Informational unless the same code path is shown to be reachable in production with equivalent impact | Docker container running OSS libraries with no memory limits, Interfere’s public SDKs |
| Source-code-only | Static analysis, code review, theoretical analysis without any running reproduction | Informational regardless of claimed severity | “This function doesn’t validate input” without demonstrating reachability or impact |