Skip to main content

Security procedures

In the Moodle software, security issues are treated very seriously. Even though a lot of time is dedicated designing the code to avoid such problems, it is inevitable in a project of this size that new vulnerabilities will occasionally be discovered.

Disclosure policy​

In Moodle, responsible disclosure is practised, which means there is 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.

When reporting a security issue, you are asked to observe these same guidelines too. 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".

warning

In line with the 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 in the Moodle security news forum, credits are always given 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 (for example, Tracker, email) cannot be linked to a Bugcrowd account, as they will not be triaged via that platform.

At this time, no paid public bug bounty program is offered.

See also​

Translations​