Moodle security procedures

We treat security issues in Moodle software very seriously. Even though we dedicate a lot of time designing our code to avoid such problems, it is inevitable in a project of this size that new vulnerabilities will occasionally be discovered.

Disclosure policy

We practice responsible disclosure, which means we have a policy of disclosing all security issues that come to our attention, but only after we have solved the issue and given registered Moodle sites time to upgrade or patch their installations.

We ask that when reporting a security issue, you observe these same guidelines, and beyond communicating with the security team, do not share your knowledge of security issues with the public at large.

How can I report a security issue?

Please submit your findings via our security issue submission form, providing step by step instructions if possible. The form is broken down into sections to help you provide all of the necessary details to help us assess the issue.

The submission form is linked to our Bugcrowd program, which ensures more efficient triage of incoming security issues and a smoother overall responsible disclosure process.

If you are a developer and wish to submit a fix along with your submission, please feel free to create a new issue in the Moodle Tracker instead, ensuring that you set a security level on the issue ("Serious security issue" or "Minor security issue"), which will hide it from public view. If you are submitting via Tracker and not sure whether an issue is a security issue, you should set the security level to "Could be a security issue".

In line with our responsible disclosure philosophy, please do not post about security issues in the forums on moodle.org or elsewhere, as this will reveal the issue before we are able to prepare a fix.

How we deal with a reported security issue

1. Issues submitted via the submission form are received by Bugcrowd's triage team, who perform initial triage on the report.
2. If the issue is confirmed valid and not a duplicate by the Bugcrowd team, the Moodle security team reviews the issue and evaluates its potential impact on all supported versions of Moodle. If the issue was submitted directly into Tracker rather than via the form, this will be the first step in the process.
3. Valid issues are then pushed to the Moodle Tracker (restricted from public view).
4. The Moodle security team works with the issue reporter to resolve the problem, following the Security issue development process and keeping details of the problem and its solution hidden until a release is made.
5. New versions are created and tested.
6. Meanwhile Moodle requests CVE identifiers for the security issue.
7. New packages are created and made available on download.moodle.org.
8. Advisories are mailed to administrators of registered Moodle sites, giving a period of time when they can upgrade before the issue becomes public.
9. A public announcement is made about the security issue in the Moodle security news forum.
10. Open Source Software Security is notified about it.
11. Issues submitted via the submission form are marked fixed in the Bugcrowd platform, which will notify the reporter.

Rewards

When a patched Moodle LMS security vulnerability is announced via CVE and the Moodle security news forum, we will always give credit by naming the first reporter of the issue (regardless of submission method).

In addition to this, if an email address is provided with submissions made via the submission form, it is possible for members of the Bugcrowd platform to claim their submissions under their Bugcrowd account. Please note that security issues submitted by other means (eg Tracker, email) cannot be linked to a Bugcrowd account, as they will not be triaged via that platform.

At this time, we do not offer a paid public bug bounty program.

See also

• Security issue development process
• Moodle_Penetration_Testing