Vulnerability Disclosure Policy
At Gevme, we take security and privacy issues very seriously. Our team is busy improving the systems and processes. This helps to protect the our client data and also ensures the continuity of our services. However, this does not mean that our systems are immune to problems. If problems are detected, we would like your help. The responsible disclosure of security vulnerabilities helps us ensure the security and privacy of our end-consumers.
Security Researchers should…
- Respect the rules. Operate within the rules set forth by the this policy, or speak up if in strong disagreement with the rules.
- Respect privacy. Make a good faith effort not to access or destroy another user’s data.
- Be patient. Make a good faith effort to clarify and support their reports upon request.
- Do no harm. Act for the common good through the prompt reporting of all found vulnerabilities. Never wilfully exploit others without their permission.
⚠️ NOTE: You are testing on production. Behaviour that compromises the stability and integrity of the site is out of scope. For example, do not target other user’s data (use one of your other sets of credentials), delete/remove/edit parts of the site, engage any sort of DoS attack, and/or compromise any target’s ability to function for other users. If you believe that you have found a vulnerability of this nature, please stop further testing and report it.
- Notify us as soon as you discover a potential security vulnerability.
- Do not share details of the suspected vulnerability publicly or with any third party.
- Only use or access accounts and information that belong to you.
- Do not destroy or modify data that is not yours.
- Do not degrade the performance of Gevme products and services or our users.
- Do not perform social engineering, physical, or denial of service attacks on Gevme personnel, locations, or assets.
- Only use exploits to the extent necessary to confirm a vulnerability’s presence.
- Do not try to repeatedly access the system and do not share the access obtained with others.
- Do not use an exploit to compromise or exfiltrate data, establish persistent command line access, or use the exploit to pivot to other systems.
This program applies to Gevme products, services, and systems. Always be careful to verify whose assets you are testing while performing research. Assets in scope for this program are:
How to Report a Vulnerability
If you have detected a vulnerability, then please send your reports with POCs and steps to reproduce on firstname.lastname@example.org
Reporting format :
[URL / IP / Endpoint]
**Proof of Concept (PoC):**
[Step by Step PoC for replication]
[Proofs - screenshot or video]
What we would like to see from you
To help us triage and remediate potential findings, a good vulnerability report should:
- Describe the vulnerability, precisely where it was discovered, and the real-world impact.
- Offer a detailed description of the steps needed to reproduce the vulnerability (POCs, screenshots, and videos are helpful).
- Please include one vulnerability per report (unless in an attack chain).
- Don’t report automated scanner results without proof of exploitability.
⚠️ NOTE: Vulnerabilities reported without any POC (Proof of Concept) and Steps to Reproduce will not be considered for this reward program.
What you can expect from us
When you choose to share your contact information with us, we commit to coordinating with you as openly and as quickly as possible.
- Report may be submitted anonymously, without giving out any personally identifiable information. If you share contact information, we will acknowledge receipt of your report within 7 business days.
- To the best of our ability, we will confirm the existence of the vulnerability to you and be as transparent as possible about the remediation process, including on issues or challenges that may delay resolution.
- When you follow the guidelines that are laid out above, we will not pursue or support any legal action related to your research. Should legal action be initiated by a third party against you for activities that were conducted in accordance with this policy, we will make this authorization known.
- If you are the first to report a “qualifying vulnerability” in accordance with this Policy, we would like to recognize your contribution on our Security Researcher Wall of Fame and/or with a reward.
⚠️ NOTE: To qualify for bounty, the security bug must be original and previously unreported, and must be reported to Gevme and only Gevme.
- Third-Party Integrations
- Issues related to https://support-reg.gevme.com/ and https://support.gevme.com/ (unless its an RCE or something similar)
- Any sort of brute-force attacks
- Web / API :
- Account/e-mail enumeration using brute-force attacks
- Any low impact issues related to session management (i.e. concurrent sessions, session expiration, password reset/change log out, etc.)
- Client-side application/browser autocomplete or saved password/credentials
- Incomplete or missing SPF/DMARC/DKIM records
- Lack of SSL or Mixed content
- Login/Logout/Unauthenticated/Low-impact CSRF
- Low impact Information disclosures (including Software version disclosure)
- Missing Cookie flags
- SSL/TLS best practices that do not contain a fully functional proof of concept
- Valid bugs or best practice issues that are not directly related to the security posture of the client
- Vulnerabilities affecting users of outdated browsers, plugins or platforms. For example, an XSS reliant on Adobe Flash (no longer supported)
- SSL Weak Ciphers/ POODLE / Heartbleed
- Clickjacking, Phishing or any form of Social Engineering Attack
- Findings from applications or systems not listed in the ‘In Scope’ section.
- Attacks requiring MITM or physical access to a user’s device.
- Clickjacking on pages with no sensitive actions.
- Any activity that could lead to the disruption of our service (DoS).
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS.
- Rate limiting or brute-force issues on non-authentication endpoints.
- Anything not permitted by applicable law
- Missing DNSSEC settings.
- Self XSS.
- Missing HTTP security headers (CSP, HSTS, etc.)
We reserve the right to consider vulnerabilities in third party software as being in or out of scope.
Questions regarding this policy may be sent to email@example.com. We also invite you to contact us with suggestions for improving this policy.
⚠️ Anything Out-of-Scope can still be reported, however, its acceptance for rewards under VDP will be at sole discretion of the Gevme Security Team.