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.
- 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.
Scope: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 VulnerabilityIf you have detected a vulnerability, then please send your reports with POCs and steps to reproduce on email@example.com
Reporting format :
**Issue:** [Issue Name] **Description:** [Issue Description] **Affected Resource:** [URL / IP / Endpoint] **Proof of Concept (PoC):** [Step by Step PoC for replication] **Attachment (Preffered):** [Proofs - screenshot or video]
What we would like to see from youTo 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.
What you can expect from usWhen 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.
- 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
- Missing/Enabled HTTP Headers/Methods which do not lead directly to a security vulnerability
- 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