Security announcements

A web service fetching messages was not restricted to the current user's conversations.

(Edited 11 June 2019 to update the CVE identifier.)

get_with_capability_join and get_users_by_capability were not taking context freezing into account when checking user capabilities

There was a link to site home within the the Boost theme's secure layout, meaning students could navigate out of the page.

Links within assignment submission comments would open directly (in the same window). Although links themselves may be valid, opening within the same window and without the no-referrer header policy made them more susceptible to exploits.

Users could assign themselves an escalated role within courses or content accessed via LTI, by modifying the request to the LTI publisher site.

Permissions were not correctly checked before loading event information into the calendar's edit event modal popup, so logged in non-guest users could view unauthorised calendar events. (Note: It was read-only access, users could not edit the events.)

Users with the "login as other users" capability (such as administrators/managers) can access other users' Dashboards, but the JavaScript those other users may have added to their Dashboard was not being escaped when being viewed by the user logging in on their behalf.

Please note that for versions 3.1 and 3.4 only, this fix removes access to other users' Dashboards while using the login-as functionality. Versions 3.5 and 3.6 have additional sanitizing implemented, which allowed the risk to be removed while retaining Dashboard access. If you require access to Dashboards through the login-as feature, we recommend upgrading to Moodle 3.5 or above (noting that 3.1 and 3.4 will also no longer receive security updates after their next releases in May 2019).

The /userpix/ page did not escape users' full names, which are included as text when hovering over profile images. Note this page is not linked to by default and its access is restricted.

The mybackpack functionality allowed setting the URL of badges, when it should be restricted to the Mozilla Open Badges backpack URL. This resulted in the possibility of blind SSRF via requests made by the page.

The 'manage groups' capability did not have the 'XSS risk' flag assigned to it, but does have that access in certain places. Note that the capability is intended for use by trusted users, and is only assigned to teachers and managers by default.