Moodle 4.1.12 4.1 no longer receives security fixesLTS

User list filters allowed managers to filter by user profile fields that they could not view on users' profiles.

Insufficient username escaping could allow a minor XSS risk if an unauthenticated user was tricked into opening a password reset link (so did not affect authenticated user sessions).

An incorrect capability check in the AI "generate image" web service could allow users to access that feature without having the "generate image" capability.

The manual enrolment management page did not prevent direct access when the plugin was disabled and a link was no longer available in the UI. Note: This still required the relevant capability to access the page (had it been enabled).

Insufficient escaping resulted in an XSS risk in some templates used to display forum posts.

Insufficient validation of the audience classname in report builder allowed arbitrary class instantiation.

The report builder fragment output callbacks did not verify that the requesting user had the required capability to access the requested report, potentially allowing users to retrieve report data beyond their permitted access.

A blind SSRF risk was identified in the MNet peers management functionality, due to missing validation of peer hostnames against the cURL blocked hosts configuration. Note: This feature is only available to site administrators.

Capability checks were missing from course assistance AI placement web services, which could allow users to make requests to those AI course assistance web services without having the relevant capabilities (if those features are enabled).

The quiz feature to add section headings did not include the necessary token to prevent a CSRF risk.

The actions to enable and disable group messaging did not include the necessary token to prevent a CSRF risk.

The Feedback activity module's import functionality required additional sanitizing to prevent a reflected XSS risk.

The user profile page reset action did not include the necessary token to prevent a CSRF risk.

The setting for users to set their own homepage preference did not include the necessary token to prevent a CSRF risk.

Missing group access checks in some grade web services could allow a user to access grade and user information for students in groups they did not have permission to view.

Insufficient CSRF token and capability checks were applied to an MNet admin setting.

The upstream AWS SDK for PHP library was upgraded, which included a security fix.

A flaw in message handling of conversations with deleted users could result in active users losing access to their private messages.

When blind marking is enabled for an assignment, user IDs remained visible on the assignment submissions page instead of being masked.

Badges being awarded with a role performed the correct capability check, but did not verify the user had the required role to meet the award criterion.

Forum ratings required additional permission checks to prevent users from being able to view ratings they did not have the capability to access.

Insufficient checks on a confirmation email web service made it easier to brute force password checks against known usernames.

An open redirect risk existed in the OAuth login functionality.

There was a behaviour that made it possible for a student to bypass the timed restriction on a timed assignment.

Insufficient capability checks meant users with the capability to create group events, but without the capability to view hidden groups, could see hidden and separate groups in the list of groups to select for calendar events.

It was possible to brute force password checks against known usernames when the mobile client and auth_webservice were enabled.

Insufficient capability checks meant a user with permission to manage/view cohorts in a lower context could retrieve data about cohorts defined in the system context, that they would not otherwise have access to.

Insufficient capability checks meant a callback designed to allow plugins to control user profile access did not correctly limit access in some web service functions.

Feedback activity results for all groups in Separate Groups mode could be viewed by non-editing teachers when they were not a member of any group.

Separate Groups mode restrictions were not honoured when viewing a course's Logs report, so actions of all course participants were displayed in the report. By default this only provided additional access to non-editing teachers.

A stricter capability check was required to restrict which users can fetch other users' recently accessed courses information.

The "move up" and "move down" actions in backpack management for badges did not include the necessary token to prevent a CSRF risk.

Additional cache controls were required to prevent web browsers caching a user's password on the login page (note accessing this would require access to the web browser on the device where the user had logged in).

Additional checks were required to ensure users can only fetch cohort data they are intended to have access to.

Insufficient capability checks in a messaging web service made it possible to view other users' names and online status.

Additional checks were required to prevent users deleting course sections they did not have permission to modify.

Insufficient capability checks made it possible for a user enrolled in a course to access some details (full name and profile image URL) of other users they did not have permission to access.

The analysis request action in the Brickfield tool did not include the necessary token to prevent a CSRF risk.

A user's CSRF token was unnecessarily included in the URL on the database module's edit and delete pages.

Insufficient capability checks made it possible to view RSS feed content a user does not have permission to access.

The user tours duplicate tour action did not include the necessary token to prevent a CSRF risk.

Insufficient capability checks in some grade reports resulted in some hidden grades being available to users who did not have permission to view them.

Additional checks were required to ensure trusttext is applied (when enabled) to glossary entries being restored.

Insufficient capability checks made it possible to disable badges a user does not have permission to access.

The upstream RequireJS library was upgraded, which included a security fix.

The drag-and-drop onto image (ddimageortext) question type required additional sanitizing to prevent a stored XSS risk.

Tags not expected to be visible to a user could still be discovered by them via the tag search page or in the tags block.

Separate Groups mode restrictions were not factored into permission checks before allowing viewing or deletion of responses in Feedback activities.

In a database activity with separate groups mode enabled, users who were not in a group (and did not have permission to access all groups) could see entries from members of all groups in the activity, rather than just entries of users also not in any groups. Note: Users within groups worked as intended, only able to see entries belonging to other members of their group(s).

On sites requiring a confirmation step to update a user's email address, the token used to verify the change should only be accessible via the confirmation email, but was otherwise retrievable by the user.

Insufficient checks meant users could see users tagged with a tag, regardless of whether they had access to view the users' profiles.

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

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.

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