Responsible Disclosure Policy

dotCMS takes security very seriously and always aims to provide the most secure CMS platform that keeps customer content, data and systems safe. At dotCMS, we investigate all received vulnerability reports and implement the best course of action in order to protect our customers, both cloud based and self-hosted. dotCMS believes that working with skilled security researchers can help identify weaknesses in any technology.

If you are a security researcher and have discovered a security vulnerability in dotCMS products and services, we appreciate your help in disclosing it to us in a responsible manner.

Our Commitment

If you identify a verified vulnerability in compliance with dotCMS’s Responsible Disclosure Policy, the dotCMS security team commits to:

• Provide prompt acknowledgement of receipt of your vulnerability report (within 72 business hours of submission);
• Work closely with you to understand the nature of the issue and work on timelines for fix/disclosure together;
• Notify you when the vulnerability is resolved, so that it can be re-tested and confirmed as remediated.;
• Post a description on our security page when the fix is released, and credit / acknowledge your contribution;
• Post a security advisory/CVE if required.

Reporting a Potential Security Vulnerability

• Review existing security reports to see if the security vulnerability has already been reported. Please review our list of existing/known security issues.
• Please do not post a potential security issue on our Github repo, as that is the same as disclosing it publicly. Instead, privately share details of the suspected vulnerability with dotCMS by sending an email encrypted using PGP key to security@dotcms.com.
• If you require it, please send an email to security@dotcms.com to request our PGP key.
• Provide full details of the suspected vulnerability so the dotCMS security team may validate and reproduce the issue.

Not Eligible for Reward

While we are prepared to offer standard bounties for suitable disclosures, dotCMS will not reward for the following:

• Most forms of XSS — i.e., any form that does not directly lead to a more foundational threat, such as a privilege escalation
• SSL/TLS best practices
• Reflected file download
• Software version disclosure
• Path or hostname disclosure in error messages
• Logout CSRF
• Missing HTTP header which does not lead to a direct vulnerability
• Missing cookie flags, unless the absence can be abused by a legitimate workflow
• Clickjacking without demonstration of impact
• Account enumeration through brute-force attacks
• CSV command execution
• SVG script execution

Lastly: Issues already appearing on our Known Security Issues page are likewise ineligible for reward.

Research Guidelines

To encourage responsible disclosure, we ask that all researchers comply with the following Responsible Disclosure Guidelines:

• Provide us with a reasonable amount of time to resolve the issue before disclosing it to the public or a third party. We aim to resolve critical issues as quickly as possible, but it is important to understand that dotCMS has both cloud and self-hosted customers, each of which might require different solutions in order to mitigate security issues.
• Make a good faith effort to avoid violating privacy, destroying data, or interrupting or degrading any dotCMS service or operation.

While researching, the following conduct is expressly prohibited

• Performing actions that may negatively affect dotCMS and its users (e.g. Spam, Brute Force, Denial of Service, etc).
• Accessing, or attempting to access, data or information that does not belong to you.
• Destroying or corrupting, or attempting to destroy or corrupt, data or information that does not belong to you.
• Conducting any kind of physical or electronic attack on dotCMS personnel, property, or system environments.
• Social engineering any dotCMS service desk, employee, or contractor.
• Violating any laws or breaching any agreements in order to discover vulnerabilities.

Finally, we ask that security researchers do not take any action — e.g., filing a CVE — until they have communicated with dotCMS. Please allow 72 hours for a response. dotCMS is a CNA member, and will handle filing any pertinent CVEs after the vulnerability has been confirmed and procuring a CVE number becomes necessary.

dotCMS would like to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture.

Timetable

In our ongoing efforts to protect users, we have established timelines for resolving detected vulnerabilities. Note that the responsibility outlined here concerns vulnerabilities that are relevant to live, supported versions. Users on current LTS versions will benefit from security updates in accordance with our established schedules.

While end-of-life LTS versions have occasionally received certain security updates, this has been rare and the decision to do so is solely at the discretion of dotCMS. Whenever possible, we advise upgrading to a supported version of dotCMS.

Please allow the following approximate timeframe(s) for the remediation of identified exploitable vulnerabilities. The timeframes listed below should be considered valid for cloud-hosted infrastructure only; targets may vary slightly with the spread of versions and deployment methods across self-hosted customers.

Changes

We may revise these guidelines from time to time without notice.

Contact

dotCMS is always open to feedback, questions, and suggestions. If you would like to talk to us, please feel free to email us at security@dotcms.com.

Responsibility

It is the Chief Security Officer's responsibility to see this policy is enforced.