Use this section to tell people about which versions of your project are currently being supported with security updates.
Version | Supported | Until |
---|---|---|
v4.x |
✅ | |
v3.x |
✅ | 2023-04-30 |
v2.x |
❌ | 2022-10-31 |
v1.x |
❌ | 2021-03-01 |
v0.10.x |
❌ | 2020-03-01 |
< v0.10 |
❌ | 2019-12-31 |
To report a vulnerability please send the details to [email protected].
Your report will be acknowledged within 24 hours, and you’ll receive a more detailed response to your report within 48 hours indicating the next steps in handling your submission.
After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue.
Thanks for helping to keep the base-cms ecosystem secure!
- A security advisory is created and is assigned a primary handler. This person will coordinate the fix and release process.
- If the vulnerability is confirmed, a list of all affected versions is determined and code is audited to find any potential similar problems.
- Fixes are prepared for all versions under active development (see above). These fixes are not committed to the public repository until the security advisory is published.
- A suggested embargo date is chosen and a CVE (Common Vulnerabilities and Exposures (CVE®) identifier) is requested for the vulnerability.
- On the embargo date, the changes are pushed to the public repository and new builds are begun.
- Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on the severity of the bug or difficulty in applying a fix.
This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible; however, it’s important that we follow the release process above to ensure that the disclosure is handled in a consistent manner.