As a security company, we know we're held to high security standards. We value our security community and welcome input regarding security vulnerabilities that may be found in our systems. We encourage researchers to inform us of any vulnerabilities they may find in our system, using the process set forth below. 

PLEASE NOTE: Disclosures that do not conform to this process may not be eligible for bug-bounty awards. 


Responsible Disclosure 


  1. Email and include:

    1.  Sufficient details of the vulnerability to allow it to be understood and reproduced.

    2. HTTP requests and responses, HTML snippets, screenshots or any other supporting evidence.  

    3. Proof of concept code (if available).

    4. The impact of the vulnerability.

    5. Any references or further reading that may be appropriate.

  2. We ask that all researchers conform to these guidelines:

    1. Allow us a reasonable amount of time to validate and, if needed, patch the vulnerability before public disclosure. 

    2. Do not engage in brute-force attacks or social engineering in order to identify vulnerabilities. 

    3. Do not disrupt, modify, or destroy any other customer’s data, DNSFilter data or services.

  3. We will acknowledge receipt of your report within 5 business days and conduct an internal review of the reported vulnerability in order to validate the report. We may engage with you during this process in the event we are unable to replicate the issue or have other questions. We will also determine the severity of the reported vulnerability using the NVD Common Vulnerability Scoring System (CVSS v3) for the purposes of any bug-bounty award. 

  4. Following our assessment, we will notify you of our findings. If your report was validated, you may be invited to re-test the vulnerability to confirm that the issue has been resolved once any fix has been released.

Bug Bounties

DNSFilter will reward researchers who responsibly disclose vulnerabilities with awards tiered in accordance with our assessment of the vulnerability risk level.  We will also identify the disclosing researchers in the release notes of our next update if they would like. 

In order to be eligible for any bounty, to the extent there is any intended public disclosure of the reported vulnerability it must be done in a coordinated manner and agreed upon timeline with DNSFilter.

Bounty Rules:

  • When duplicates occur, we only award the first report that was received

  • Multiple vulnerabilities caused by one underlying issue will be awarded one bounty

  • In the event of any disagreement with respect to bounty awards and/or amount, any decision from the DNSFilter Security Team is final

Our Bug Bounty program applies to the following properties :

  • *

  • *

  • *



  • All DNSFilter Roaming Clients

Our Bug Bounty program DOES NOT cover the following items: 

  • Findings derived primarily from social engineering (e.g. phishing, vishing, etc).

  • Raw output from common network and vulnerability scanning tools

  • Functional, UI, and UX bugs and spelling mistakes.

  • Denial of Service (DoS/DDoS) vulnerabilities

  • Clickjacking or missing security headers (i.e. HSTS, CSP, x-frame-options)

  • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions

  • Attacks requiring MITM or physical access to a user's device.

  • Previously known vulnerable libraries without a working Proof of Concept.

  • Missing best practices in SSL/TLS configuration.

  • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS

  • Rate limiting or bruteforce issues on email or API endpoints

  • Missing best practices in Content Security Policy.

  • Missing HttpOnly or Secure flags on cookies

  • Any session staying active after a user makes an update to their account (i.e. password update, email change, 2FA change, phone number change, etc)

  • Missing security controls, configuration best practices or business logic issues without a working Proof on Concept

  • Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)

  • Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]

  • Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, garbage collection, application or server errors).

  • Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.

  • Tabnabbing

  • Open redirect - unless an additional security impact can be demonstrated

  • Issues that require unlikely user interaction

Vulnerability Risk Levels 

Our assessment of disclosed vulnerabilities will include determination of the appropriate severity level for each vulnerability. We will address the potential impact of the vulnerability, as well as the likelihood that the vulnerability could be exploited. We may also consider the quality of the vulnerability report in making our assessment. 


Potential Bounty

CVSS 7.0 and above


CVSS 4.0 to 6.9