Responsible Disclosure Statement

At Verve Group, we consider the security of our systems a top priority. But no matter how much effort we put into system security, there can still be vulnerabilities present. If you discover a vulnerability, we would like to know about it so we can take steps to address it as quickly as possible. We would like to ask you to help us better protect our clients and our systems.

Please do the following

  • Submit your findings to moc.e1709530305vrev@1709530305ytiru1709530305ces1709530305
  • Do not take advantage of the vulnerability or problem you have discovered, for example by downloading more data than necessary to demonstrate the vulnerability or deleting or modifying other people’s data.
  • Do not reveal the problem to others until it has been resolved.
  • Do not use attacks on physical security, social engineering, distributed denial of service, spam, or applications of third parties.
  • Do provide sufficient information to reproduce the problem, so we will be able to resolve it as quickly as possible. Usually, the IP address or the URL of the affected system and a description of the vulnerability will be sufficient, but complex vulnerabilities may require further explanation.
  • Only findings with evidence of the vulnerability being exploited (without taking advantage of it) will be considered.

What we promise

  • We will respond to your report within 5 business days with our evaluation of the report and expected resolution date.
  • If you have followed the instructions above, we will not take any legal action against you in regard to the report.
  • We will not pass on your personal details to third parties without your permission.
  • We will keep you informed of the progress toward resolving the problem.

Examples of qualifying vulnerabilities

The Company reserves the right to decide if the minimum severity qualification threshold is met and whether it was already reported.

  • Authentication bypass or privilege escalation.
  • Clickjacking.
  • Cross-site scripting (XSS).
  • Cross-site request forgery (CSRF/XSRF).
  • Mixed-content scripts.
  • Server-side code execution.
  • User data breach.
  • Remote Code Execution.

Examples of non-qualifying vulnerabilities

Reporting the following vulnerabilities is appreciated but will not lead to systematic reward from the company:

  • Denial of Service vulnerabilities (DoS).
  • DNS CAA (Certificate Authority Authorization) record. 
  • DNSSEC (Domain Name System Security Extensions) configuration.
  • Possibilities to send malicious links to people you know.
  • Security bugs in third-party websites that integrate with Company API.
  • Vulnerabilities related to third-party software (e.g. Java, plugins, extensions) or websites unless they lead to vulnerability on the Company website.
  • Spam (including issues related to SPF/DKIM/DMARC).
  • Usability issues, forms autocomplete.
  • Vulnerabilities (including XSS) require a potential victim to install non-standard software or otherwise take very unlikely active steps to make themselves susceptible.
  • Non-technical attacks including social engineering, phishing, or physical attacks against our employees, users, or infrastructure.
  • Vulnerabilities (including XSS) that affect only legacy browsers/plugins or outdated protocols like TLS 1.0.
  • Self-XSS.
  • CSRF for non-significant actions (logout, etc.).
  • Content injection, such as reflected text or HTML tags.
  • Missing HTTP headers, except where their absence fails to mitigate an existing attack.
  • Vulnerabilities require access to passwords, tokens, or the local system (e.g. session fixation).
  • Assumed vulnerabilities based upon software or hardware version numbers only.
  • Bugs require exceedingly unlikely user interaction.
  • Disclosure of public information and information that does not present significant risk.
  • Scripting or other automation and brute forcing of intended functionality.
  • Requests violate the same-origin policy without concrete attack scenarios (for example, when using CORS, cookies are not used to perform authentication, or sent with requests).