Security announcements | Moodle.org

When restricting access to a Lesson activity with a password, certain passwords could be bypassed/less secure due to a loose comparison in the password checking logic.

Note: this only affected passwords that are set to "magic hash" values. These are certain values where a loose comparison in the code can result in multiple values "matching" the password, instead of the expected behaviour that only an exact match for the password will be accepted.

Additional checks were required to ensure users can only delete their own OAuth2 linked accounts.

Dynamic tables did not enforce capability checks, which resulted in users having the ability to retrieve information they did not have permission to access.

Note: Please check the information at the bottom of this announcement for important information related to this fix.

The following is important information about this fix, which includes some action items that may be necessary on your site to ensure continued functionality of dynamic tables:

• This vulnerability potentially affects all dynamic tables, so the fix implements a new method which forces a capability check.
• By default, the patches released for Moodle 4.4, 4.3, 4.2 and 4.1 implement a default check which restricts all dynamic tables to admin access only (moodle/site:config capability), to ensure any third party code is also automatically protected.
• Any dynamic tables (classes implementing core_table\dynamic) which require access by non-admins will need to be updated in the code to implement the new ::has_capability() method.
• From Moodle 4.5, that default will be removed and the ::has_capability() method will become compulsory for dynamic tables (defined in the interface), so if you have any plugins/customisations that include classes implementing core_table\dynamic, those classes will need to be updated to implement the new method. Any dynamic tables without that implementation will trigger a fatal error and fail to load from Moodle 4.5 onwards.
• The fixes for this issue update all core LMS dynamic tables, so you can refer to those for examples of how to implement this.
• If your Moodle site(s) do not use any custom/third party code which implements core_table\dynamic, you just need to upgrade your site to the latest minor version (or apply the patch), no further action is required.

A local file include risk when restoring block backups was identified.

H5P error messages required additional sanitizing to prevent a reflected XSS risk.

Bulk messaging in the Feedback activity's non-respondents report did not verify message recipients belong to the set of users returned by the report.

Insufficient sanitizing of data when performing a restore could result in an XSS risk from malicious backup files.

An SQL injection risk was identified in the XMLDB editor tool available to site administrators

Insufficient capability checks made it possible for users with access to restore glossaries in courses to restore them into the global site glossary.

The bulk message sending feature for the Feedback module's non-respondents report had an incorrect CSRF token check, resulting in a CSRF risk.