How to report a vulnerability in UserEcho

Last modified:


Step-by-step guide on how to report a security bug/vulnerability

For responsible disclosure of a possible security vulnerability in UserEcho, we'd like you to follow these guidelines.

This way we get all the information we need in order to take appropriate and timely action. Thus, we ask you to report it directly to us thus, not to report the vulnerability in any public forums (like GitHub) etc. to ensure that it does not get exploited in the wild.

How to report a vulnerability

  • Reach out to us directly at support@userecho.com
  • Make sure to provide us with as much and thorough information as you can

What we expect from you

In order for us to fix and handle the vulnerability appropriately, we need your help. We need you to:

  • Not tell anyone about the problem until we have fixed it. You will also not submit it as a CVE during this time.
  • Make sure to verify your claim of a security vulnerability by sharing a proof of concept
  • Reporting the results of an automated scan is usually not helpful. Please send us proof on how you think an attacker could exploit each of the scan results.

What'll happen next?

We will acknowledge receipt of your vulnerability report. If we take the security issue further, we'll send you regular updates about our progress. As an acknowledgement of your contribution, we offer to publicly acknowledge your disclosure.

Bounty Ineligible Issues

The following items are known issues or accepted risks where we will not reward you:

  • Clickjacking.
  • Cookie flags.
  • SPF, DKIM, DMARC issues.
  • Malicious attachments on file uploads or attachments.
  • Missing additional security controls, such as HSTS or CSP headers.
  • Mobile issues that require a Rooted or Jailbroken device.
  • Brute-force, / Rate-limiting, / Velocity throttling, and other denial of service based issues.
  • Issues involving server information disclosure, namely `X-Powered-by` and `Server` response headers.
  • XSS (or a behavior) where you can only attack yourself (e.g. "Self XSS").
  • XSS on pages where admins are intentionally given full HTML editing capabilities, such as custom theme editing
  • Low severity issues


List of security contributors

We'd like to thank the contributors for their amazing efforts in making UserEcho safer, and we've therefore gathered a dedicated list of UserEcho security contributors​.


The people listed here, are all the first who provided us with actionable security information which helped us fix a particular vulnerability.


This article was helpful for 16 people. Is this article helpful for you?
Report an error
Still need help? New ticket