This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.
Please follow Wagtail’s security policy when contacting this team. For security discussions that aren’t related to vulnerabilities, find us in #security on the Wagtail Slack.
Team charter
The security team’s membership is restricted, as we discuss sensitive issues such as 0-day vulnerabilities in Wagtail. Membership is on invitation only, with an indefinite term revokable at any point.
We meet as-needed only. The team organises the response to security vulnerability reports in private channels according to Wagtail’s security policy (SECURITY.md), and uses #security for discussions which aren’t deemed sensitive.
Team members
Current members:
- Coen van der Kamp (@allcaps), UTC + 1 or 2, since January 2022
- Matt Westcott (@gasman), UTC + 0 or 1, since January 2022
- Neal Todd (@nealtodd), UTC + 0 or 1, since January 2022
- Thibaud Colas (@thibaudcolas), UTC + 0 or 1, since January 2022
- Tom Dyson (@tomdyson), UTC + 0 or 1, since January 2022
- Jake Howard (@RealOrangeOne), UTC + 0 or 1, since March 2023
- Dan Braghiș (@zerolab), UTC + 0 or 1, since October 2023
Past members:
- Karl Hobley (@kaedroho), January 2022 – November 2022
Vulnerability report response guide
Here are quick guidelines on responding to vulnerability reports. This guide is mostly aimed at team members to help us deal with incidents professionally, and reduce the risk of mistakes. This is especially important because security risks are stressful and can involve significant time pressure.
Where to start
We receive a lot of spam. This only covers legitimate reports.
- Thank the reporter for their time investigating the issue, and for reporting it to us. Clarify any potential doubts about the process.
- Establish a clear understanding of:
- Which component exactly is vulnerable
- What the impact is (loss of confidentiality, availability, integrity – see NIST CVSS metrics).
- How exploitable the vulnerability is for a given vulnerable Wagtail site. NIST’s CVSS exploitability metrics can help frame this.
- What severity the vulnerability is according to Django’s security policy
- How many sites this is likely to affect as a proportion, based on which component / configuration is vulnerable.
- Discuss this understanding with other team members.
- Attempt to exploit the vulnerability yourself to confirm your understanding.
Based on this, you can then decide to:
- Treat the report as a bona fide vulnerability: security advisory, CVE, patch releases.
- Treat the report as a security issue which isn’t a definite vulnerability: public GitHub issues and pull requests.
- Do nothing, if the vulnerability isn’t confirmed, or is outside of Wagtail’s remit.
Share your plans with the initial reporter, and proceed.
Confirmed vulnerabilities
Once there is team consensus to treat the report as a vulnerability, you can:
- Create an advisory in GitHub, filling in all relevant details. Make sure to grant access to
@wagtail/security. - Work on the patch in the advisory’s attached private fork.
- Request a CVE from GitHub once the vulnerability is described clearly enough.
- Ultimately publish the advisory, merging the patch.
Vulnerabilities outside Wagtail
We will occasionally take action when there are vulnerabilities outside Wagtail itself, if we have good reasons to believe they would affect Wagtail websites. This can be as simple as sharing a heads’up of possible security issues on communication channels for the benefit of our community members, or making more formal announcements.
Here are past examples of vulnerabilities likely affecting Wagtail websites which we’ve addressed:
- Wagtail statement on WebP vulnerability – 2023-10-04
- Wagtail statement on Log4j vulnerability – 2021-12-17
- Django security releases relevant to Wagtail sites – 2019-12-18