Issues and bug reports#

Reporting bugs#

If you have discovered a bug in Silverstripe CMS, we'd be glad to hear about it - well written bug reports can be half of the solution already!

Silverstripe CMS uses GitHub to manage bug reports. If you want to report a bug, you will need to create a GitHub account and log in.

Before submitting a bug#

• Ask for assistance in our community channels if you're unsure if it's really a bug.
• Search for similar, existing issues. You can list all issues across modules, then add your search phrase at the start of the existing search filters.
• Is this a security issue? Stop here and follow our security reporting guidelines below instead.
• Try to reproduce your issue on a clean installation to rule out bugs in your own code.

If the issue does look like a new bug#

• Create an issue on the right module repository in GitHub
  • If you are unsure, create an issue on the the "framework" repository.
  • Note that documentation issues are tracked in the "developer-docs" repository.
• Describe the steps required to reproduce your issue, and the expected outcome. Example code, screenshots, and videos can help here. Be as clear as you can, but don't miss any steps out. Simply saying "create a page" is less useful than guiding us through the steps you're taking to create a page, for example.
• If the bug is too complex to reproduce with some short code samples, please reproduce it in a public repository and provide a link to the repository along with steps for setting up and reproducing the bug using that repository. A repository like this should only contain code that is required to set up and reproduce the bug.
• Describe your environment in as much detail as possible. Include the versions of relevant modules, the PHP version, webserver, and operating system used to run the project, the browser(s) you see the issue in, etc.
• If part of the bug includes an error or exception, please provide a full stack trace. Be wary that stack traces may contain sensitive information, and if that is the case, be sure to redact them prior to posting your stack trace.
• You are strongly encouraged to submit a pull request which fixes the issue. Bug reports which are accompanied with a pull request are a lot more likely to be resolved quickly.

Lastly, don't get your hopes up too high. Unless your issue is a blocker affecting a large number of users, don't expect Silverstripe developers to jump onto it right way. Your issue is a starting point where others with the same problem can collaborate with you to develop a fix. If this bug is a blocker for you, then submitting a pull request is the best way to ensure it gets fixed.

Feature requests#

In order to gain interest and feedback in your feature, we encourage you to present it to the community through the community channels.

Reporting security issues#

Silverstripe CMS follows a coordinated disclosure model. Vulnerabilities are reported privately to the security team, fixed privately, and only disclosed publicly once a patched release is available.

How to report a vulnerability#

Report potential security issues by email to security@silverstripe.org. Emails sent to that address are forwarded to a private mailing list and kick off a specific security process. This is the only channel we accept security reports through.

If you have any doubts or are unsure whether the bug you've found has security implications or not, please err on the side of caution and email us about it. We would much rather receive a report that turns out not to be a vulnerability than have a real vulnerability disclosed in public.

Your report should include enough detail for us to understand and reproduce the vulnerability, for example:

• the affected module(s) and version(s)
• a description of the vulnerability and its potential impact
• clear steps to reproduce the issue, including any proof-of-concept code, HTTP requests, or screenshots
• any suggested mitigations or fixes
• whether, and how, you would like to be credited in the security advisory

Do not open a public pull request containing a fix for a vulnerability, as the fix itself discloses the vulnerability. If you have a fix, include it in your report and the security team will apply it through our private process.

While we work on a fix#

Please keep the details of the vulnerability confidential until we publish a security advisory. In particular:

• don't share the details of the vulnerability with anyone other than the Silverstripe CMS security team
• don't publish a proof-of-concept or exploit code
• don't request a CVE or publish an advisory yourself - we request the CVE and publish the advisory when the patch is released
• let us know before discussing the vulnerability with any third party, such as another affected vendor

Once the security advisory has been published, you are free to discuss and write about the vulnerability.

When researching a vulnerability, only test against Silverstripe CMS installations you own or are explicitly authorised to test. This includes the project's own websites and infrastructure, such as silverstripe.org. Do not access, modify, or delete data that isn't yours, and do not use denial of service or social engineering attacks.

What happens next#

Review our Managing Security Issues process to understand what happens once a vulnerability is reported.

Silverstripe CMS aims to ship security patches at pre-defined intervals when those issues are not actively exploited in the wild. Review the Security patch windows section of our minor release policy for more details.

Silverstripe CMS does not operate a bug bounty program. Reports that are conditional on payment or rewards will not be accepted.

GitHub labels#

The current GitHub labels are grouped into five sections:

1. Impact - What impact does this issue have, does it break a feature completely, is it just a side effect or is it trivial and not a big problem (but a bit annoying), etc. Impact is evaluated in the context of the CMS as a whole, rather than against the individual module the issue is raised on.
2. Complexity - What level of technical proficiency is required to address this issue?
3. Type - The type of solution required to address this issue
4. Affects - The major release line this issue is relevant to - for instance silverstripe/admin 3.0.0 is on the CMS 6 major release line, so use affects/v6. Do not add this label for unreleased major release lines, instead use type/api-break.
5. RFC - The issue is a request-for-comment