Sikkerhedsmeddelelser | Moodle.org

Additional checks were required to ensure users can only access the schedule of a report if they have permission to edit that report.

Additional checks were required to ensure users with permission to view badge recipients can only access lists of those they are intended to have access to.

Additional checks were required to ensure users can only fetch the list of course badges for courses they are intended to have access to.

Users with access to delete audiences from some reports could delete audiences from other reports they did not have permission to delete from.

Additional checks were required to ensure users can only edit or delete RSS feeds they have permission to modify.

It was possible for users with the "send message" capability to view other users' names they may not otherwise have access to, via an error message in Messaging. (Note: The name returned followed the full name format configured on the site).

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.