Reporting a security issue
Thank you for taking interest in the security of Moodle LMS. We value the security of Moodle's users, their data, and our services. In an effort to protect our digital ecosystem and that of the many schools, institutions and companies around the world running their own Moodle instances, we've created this page to allow security researchers to report any potential security issues they may have identified.
Our commitments to you:
- We will maintain respect, trust and confidentiality in our exchanges with researchers.
- We appreciate your contribution to keeping Moodle LMS and its users safe and secure.
- We will work with you to validate and remediate reported vulnerabilities.
- We will investigate and remediate issues in a manner consistent with our Responsible Disclosure Policy.
What we ask of you:
- Respect. As we promise to maintain respect, trust and confidentiality with you, we ask that you do the same with us. We ask that you adhere to our Responsible Disclosure Policy, and that you do not disclose any information regarding your submission's details without express written permission from our team.
- Patience. While we will attend to issues as soon as we can, and will prioritise potentially serious vulnerabilities, please keep in mind we are a relatively small team.
- Please provide as much relevant information as possible in your submission. It is vital to provide clear reproduction steps regarding your finding so that we may validate the report in a timely manner.
- Adhere to the out of scope section below.
- Please make sure to add your email address to the submission, so we can get in touch with you about any technical details as needed.
- Please do not request CVEs yourself. We will do so as part of our responsible disclosure process, and your name will still be listed as the reporter when our CVEs are published. This not only ensures the details are verified and written consistently, but also allows us to include a complete list of affected and patched Moodle versions.
When conducting vulnerability research according to this policy, we consider this research to be:
- Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy;
- Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls;
- Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and
- Lawful, helpful to the overall security of the Internet, and conducted in good faith.
You are expected, as always, to comply with all applicable laws.
If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please inquire via firstname.lastname@example.org before going any further.
- Testing of any production systems (operated by Moodle or otherwise). Please use the Moodle LMS security testing instance, or download a copy of Moodle and install a local instance for testing (Moodle is also available via Git and as a Docker image).
Note: Although testing of production systems is out of scope, if you spot a potential vulnerability on an out of scope asset managed by Moodle (such as moodle.org), please feel free to submit it.
- Testing the physical security of our offices, employees, equipment, etc.
- Conducting non-technical attacks such as social engineering or phishing attacks.
- Accessing, downloading, or modifying data residing in an account that does not belong to you.
- DoS/DDoS or any other testing that would impact the operation of our systems. Moodle LMS is open source, so if you wish to test potential DoS scenarios or run high-traffic automated tools that may negatively impact other users/researchers using the test site, please download a copy and test locally (at your own risk).
- Testing that would result in sending spam or other unsolicited messages.
- Testing third party applications, plugins or services.
- Defacement of any assets.
- Self-XSS (unless there is a proven impact on other users).
Vulnerabilities that can be avoided by proper configuration by site administrators. Some examples of this include (but aren't limited to):
- SSRF that can be mitigated by configuring site HTTP security settings.
- Weak password policy settings.
Verbose error messages caused by developer debugging being enabled, etc.
Please see our docs for more information about site security settings.
- Reports from automated testing tools (unless a clear vulnerability proof of concept is provided).
- Mail configuration issues (e.g. SPF, DKIM or DMARC settings).
- Credentials intentionally published on the test site homepage (these are provided for testing purposes).
- Unsupported Moodle versions (see our version support table for an up-to-date list of supported versions).
Below you will find the form where you can submit your finding. Please remember to include clear steps to reproduce (including any relevant URLs/navigation steps, user role i.e. student/teacher etc), to help facilitate validation. It is highly recommended that you provide your email address to ensure you can claim your submission and continue communication as needed.
For more information about Moodle security features, settings and procedures, please see our Security documentation.