Request demo

Request demo

Request demo

Request a demo

Solutions

Platform

Explore

Request a demo

Vulnerability Disclosure Policy

Vulnerability Disclosure Policy

Last Revised

January 30, 2024

Protecting our systems, and data entrusted to us by our customers is integral to what we do at Planhat.

We value the work done by security researchers in making the Internet a safer and more secure place, and have developed this policy using guidance from ISO 29147:2018

If you have identified a security vulnerability in our products, services or systems we would like to work with you to improve our systems. Please review this policy before attempting to test or report a vulnerability.

A security vulnerability is a weakness, error or flaw in a product, service or system that could allow an attacker to compromise the integrity, availability, or confidentiality of that product, service or system.

Reporting vulnerabilities

Report any vulnerability you discover in our systems by e-mailing security@planhat.com More details on how to contact us, including how to secure your communications, are provided later in this policy.

In all cases, you must:

  1. Act responsibly for the sole purpose of reporting suspected vulnerabilities and safeguarding users from damage, harm or loss. Only test systems that are in scope of this policy. These are listed further down in this policy.

  2. Avoid causing any kind of damage, harm or loss to individuals or organizations (e.g. you should not attempt to test, reproduce or verify the suspected vulnerability, or take any action which may cause interruption or degradation of any Services of Planhat).

  3. Conduct yourself in accordance with applicable laws and regulations at all times. If you have any doubt about such laws or regulations, please reach out to us at security@planhat.com. Under no circumstances should you attempt to exfiltrate any data or publish details of any identified vulnerability.

  4. Where applicable, provide your name, email and mobile number in the suspected vulnerability report so that we may contact you for clarifications. Include the name(s) and email(s) of other person(s) to whom you may have disclosed the vulnerability.

  5. Provide adequate information in the vulnerability report so that we may work with you on validating the vulnerability, including these details (where available):

    • Description of the vulnerability.

    • IP address and/or URL of the subject Service.

    • Configuration and version of the subject software.

    • Description of the circumstances, including date(s) and time(s), leading to your reporting of the suspected vulnerability.

    • Description of the reason(s) why you believe the suspected vulnerability may impact the subject Service and the extent of such suspected potential impact (e.g. describe how you believe the suspected vulnerability might potentially operate).

  6. Act in good faith. Depending on the disclosure method and our policy, you may be eligible for a recognition. You will be kept informed through the processing and triaging the bugs that you report.

  7. Work with us. Promptly report any findings to us, stopping after you find the first vulnerability and requesting permission to continue testing. Allow us a reasonable amount of time to resolve the vulnerability before publicly disclosing it.

And you must not:

  • Exfiltrate data. Instead use a proof of concept to demonstrate a vulnerability.

  • Deploy destructive, disruptive or other unlawful means to detect vulnerabilities (e.g. attacks on physical security, social engineering, denial of service, brute force attacks, fuzzers/scanners).

  • Use a vulnerability to disable further security controls.

  • Exploit, test or otherwise use any suspected vulnerability (e.g. taking any step(s) to access, copy, create, delete, modify, manipulate or download any data or program, build system backdoor(s), modify system configuration(s), facilitate or share system access).

  • Break the law, or any agreements you may have with Planhat or third parties.

You can help us by:

  • Providing the IP address from which you performed the testing so that we can view logs related to your testing.

  • Clearly identifying your traffic, for example by including a unique custom HTTP header such as X-Planhat-CVD:{youremail@address}.

  • If you are attempting to demonstrate root level access, please use touch /root/{uniqueid}.

  • Providing us with detailed information about the vulnerability to help us confirm it e.g:

    • The URL of the product, service or system

    • If the vulnerability is in code that Planhat distributes, the version number

    • A description of the vulnerability

    • The steps needed to reproduce the vulnerability, any proof-of-concept code

    • Any screenshots

    • Details of the browser and OS used during testing

    • How you prefer to be contacted

    • Any current plans you have to disclose the vulnerability

What we'll do

Planhat will:

  • Respond and acknowledge your report within two calendar days.

  • Ask for any additional information we need to investigate your report.

  • Work with you to confirm the vulnerability, the extent to which it affects us, and let you know how long we think the vulnerability will take to fix. Our aim is to fix vulnerabilities within 60 days of confirmation.

  • Notify you when the vulnerability has been fixed.

  • Where appropriate, release information about the issue to our members, partners, or the public to help others determine if they are affected by the vulnerability, and if so, what they need to do.

  • Review what went wrong and update our practices and processes to improve our products and services.

  • If you wish, acknowledge your assistance to Planhat on our “Hall of Fame” page.

  • Treat your report as confidential, treat your data according to our privacy policy, and not pass your personal data onto any third parties without your permission.

Safe Harbor

When conducting vulnerability research according to this policy, we consider this research to be:

  • Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy;

  • Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls;

  • Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and

  • Lawful, helpful to the overall security of the Internet, and conducted in good faith.

  • You are expected, as always, to comply with all applicable laws.

If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please inquire via support@planhat.com before going any further.

Communicating with Planhat

If you are worried about the confidentiality of information sent to Planhat as part of this process, we recommend you send the information on encrypted mail. You may wish to report something to us entirely anonymously. We are happy for you to do this, but it may make it difficult for us to confirm the vulnerability and acknowledge your efforts if we are unable to contact you. We may also fail to identify activity if you are anonymous, for example, if you do not wish to provide us the IP address used to test our systems.

Scope of the policy

This policy is under active development. We are using a limited scope to help us explore what works well and what does not. The scope of the policy will change over time.

Systems in scope

The fully qualified domain names of the systems within scope are listed below. Subdomains not explicitly listed are not in-scope. All systems within scope can be identified by the presence of security.txt within their web root, for example https://www.planhat.com/.well-known/security.txt.

Out of scope
  • Spam or social engineering techniques

  • Denial-of-service attacks

  • Email Spoofing

  • Security issues in third-party apps or websites that integrate with Planhat except in some specific circumstances

  • Executing scripts on sandboxed domains. Using alert (document.domain) in your payload can help verify whether the context is actually *.planhat.com

  • Any attack or vulnerability that hinges on a user’s computer first being compromised

  • False positives

If you are unsure as to whether a system is in scope, please contact us first.

Planhat Employees and Contractors

If you are a Planhat employee or contractor, use the internal process for reporting incidents, not this external process.

We would like to encourage you to work on security problems that cannot be addressed externally and ensure that your efforts are recognized by our performance management system. For more information contact the information security team.

Program Rewards

Our public program currently does not provide any monetary reward beyond Planhat’s eternal gratitude. If you are a researcher, you can claim your submission for kudos and listing on our hall of fame. If you are interested in helping us in a more dedicated manner as a security researcher in our Private Program, please contact security@planhat.com with your request and justification.

At Planhat’s sole discretion, we may make exceptions to this policy for exceptional contributions.

Possible Exceptions: You may be eligible for a reward if you report a previously unknown issue to us AND it requires a severe code/configuration change from our side. Rewards can be monetary or swag. Reward amount varies based on the CVSS Score, business impact, severity, and creativity of the issue reported. Vulnerabilities reported within the applications, features, and functions that are in the “Systems in Scope” section in this document are awarded at higher levels.

Excluded Submission Types

Some submission types are excluded because they are dangerous to assess, or because they have low security impact on us. This section contains issues that we do not accept, will be immediately marked as invalid, and are not rewardable.

  • Findings from physical testing such as office access (e.g. open doors, tailgating).

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

  • Findings from applications or systems not listed in the ‘Targets’ section.

  • Functional, UI and UX bugs and spelling mistakes.

  • Network level Denial of Service (DoS/DDoS) vulnerabilities.

  • Common “Non-qualifying” Submission Types

Some submission types do not qualify for a reward because they have low security impact on us, and thus, do not trigger a code change. This section contains a listing of issues found to be commonly reproducible and reported but are often ineligible. We would highly appreciate your reports on these issues if you can demonstrate a chained attack with higher/critical impact.

  • Descriptive error messages (e.g. Stack Traces, application or server errors).

  • HTTP 404 codes/pages or other HTTP non-200 codes/pages.

  • Banner disclosure on common/public services.

  • Disclosure of known public files or directories, (e.g. robots.txt).

  • Clickjacking and issues only exploitable through clickjacking.

  • CSRF on forms that are available to anonymous users (e.g. the contact form).

  • Logout Cross-Site Request Forgery (logout CSRF).

  • Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.

  • Lack of Secure and HTTPOnly cookie flags.

  • Lack of Security Speedbump when leaving the site.

  • Weak Captcha / Captcha Bypass

  • Username enumeration via Login Page error message

  • Username enumeration via Forgot Password error message

  • Login or Forgot Password page brute force and account lockout not enforced

  • OPTIONS / TRACE HTTP method enabled

  • SSL Attacks such as BEAST, BREACH, Renegotiation attack

  • SSL Forward secrecy not enabled

  • SSL Insecure cipher suites

  • The Anti-MIME-Sniffing header X-Content-Type-Options

  • Missing HTTP security headers, specifically (https://www.veracode.com/blog/2014/03/guidelines-for-setting-security-headers)