The XML grade import functionality (which allows setting or overwriting of student grades) did not include the necessary token to prevent a CSRF risk.
Moodle 3.3.8 3.3 no longer receives security fixes
Released 10 Sep 2018. Moodle 3.3 had its last security release, 3.3.9, on 12 Nov 2018, and its security support ended 12 Nov 2018. Advisories published since then list it only as an earlier unsupported version.
269 of them were published after 3.3 left security support, so no 3.3 release fixes them. The fix is a major upgrade: 4.5.14 is the current long-term support release, 5.2.3 the newest.
An incorrect capability check in a grade web service allowed students to access profile information of other students enrolled in the same course, which they would not otherwise have access to.
An SQL injection risk was identified in a question bank web service.
Incorrect handling of IPv4-mapped IPv6 addresses could allow bypassing of some blocked hosts, resulting in an SSRF risk.
User profile descriptions for authenticated users posed a denial of service risk due to the absence of a defined maximum length.
Insufficient capability checks in the Assignment module's marker allocation functionality allowed users without the required capability to allocate markers to submissions.
The regrade action in the quiz overview report did not include the necessary token to prevent a CSRF risk.
The grade item ID number editing functionality did not include the necessary token to prevent a CSRF risk and also lacked sufficient output sanitizing to prevent an XSS risk.
Additional checks were required to ensure users with the capability to delete comments can only do so in the contexts where they have the permission.
A remote code execution risk was identified in the admin presets import feature. Note: This feature is only available to site administrators.
An arbitrary file read risk was identified in the backup restore functionality.
A flaw in email-based multi-factor authentication made it possible for a user to bypass another user's MFA token check if using the email factor. Note: Valid login credentials (such as username and password) were still required to log into the account.
An arbitrary file read risk was identified in the Database Activity module's import feature.
A remote code execution risk was identified in Moodle's Google Drive repository plugin.
An SQL injection risk was identified in the "external database" authentication plugin (auth_db). Note: This only affected sites with the auth_db authentication plugin enabled.
Rendering of TeX content with mimetex in the formula editor required execution time limitations to prevent a denial of service risk.
Additional sanitizing was required on a TeX filter administration setting to prevent a remote code execution risk.
A remote code execution risk was identified in the file restore functionality.
The return URL in the policy tool required extra sanitizing to prevent a reflected XSS risk.
Insufficient sanitizing when exporting data to CSV / XLSX format could result in malicious formulas being inserted into the files.
Insufficient sanitizing in the formula editor could result in an XSS risk.
Suspended users were not prevented from authenticating via the LTI Provider
A remote code execution risk was identified in the file restore functionality.
The upstream FPDI library was upgraded, which included a security fix.
Insufficient authorisation checks could result in users being able to view BigBlueButton recordings they did not have permission to access.
Insufficient state and capability checks resulted in some details of hidden courses (such as course name, description and teachers) being available to users who did not have permission to access them.
A DNS rebind risk in the way cURL requests were handled could result in an SSRF risk, due to the possibility of cURL blocked hosts / allowed ports site configurations being bypassed.
The upstream ADOdb library contained an SQL injection risk in the pg_insert_id() method. It is important to note that the core Moodle LMS was NOT affected by this vulnerability, however as a precaution, this library has been upgraded to remove the risk entirely, in case any third party code/plugins uses the vulnerable code.
The return URL in the policy tool required extra sanitizing to prevent a reflected XSS risk.
A remote code execution risk was identified in the Moodle LMS EQUELLA repository. By default this was only available to teachers and managers, on sites with the EQUELLA repository enabled.
A remote code execution risk was identified in the Moodle LMS Dropbox repository. By default this was only available to teachers and managers, on sites with the Dropbox repository enabled.
Insufficient sanitizing in an undocumented MimeTeX command resulted in a remote code execution risk for sites using MimeTeX (via the TeX Notation filter).
An SQL injection risk was identified in the module list filter within course search.
Description information displayed in the site administration live log required additional sanitizing to prevent a stored XSS risk.
Insufficient sanitizing in the TeX notation filter resulted in an arbitrary file read risk on sites where pdfTeX is available (such as those with TeX Live installed).
Guest user sessions were given a longer timeout than authenticated users, which could result in an elevated denial of service risk.
Insufficient capability checks in a learning plan web service could result in users having the ability to retrieve information they did not have permission to access (such as users' names).
Dynamic tables did not enforce capability checks, which resulted in users having the ability to retrieve information they did not have permission to access.
A local file include risk when restoring block backups was identified.
H5P error messages required additional sanitizing to prevent a reflected XSS risk.
An SQL injection risk was identified in the XMLDB editor tool available to site administrators
The bulk message sending feature for the Feedback module's non-respondents report had an incorrect CSRF token check, resulting in a CSRF risk.
Insufficient capability checks made it possible to delete badges a user does not have permission to access.
Additional localstorage validation was required to mitigate a cache poisoning risk.
Insufficient sanitizing in the TeX notation filter resulted in an arbitrary file read risk on sites where pdfTeX is available (such as those with TeX Live installed).
Additional restrictions were required to avoid a remote code execution risk in calculated question types. (Note: This required the capability to add/update questions.)
Incorrect CSRF token checks resulted in multiple CSRF risks.
In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore database activity modules and direct access to the web server outside of the Moodle webroot could execute a local file include.
In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore wiki modules and direct access to the web server outside of the Moodle webroot could execute a local file include.
In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore workshop modules and direct access to the web server outside of the Moodle webroot could execute a local file include.
In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore feedback modules and direct access to the web server outside of the Moodle webroot could execute a local file include.
Incorrect validation of allowed event types in a calendar web service made it possible for some users to create events with types/audiences they did not have permission to publish to.
Insufficient file size checks resulted in a denial of service risk in the file picker's unzip functionality.
A remote code execution risk was identified in course blocks. By default this was only available to teachers and managers.
Insufficient recursion limitations resulted in a denial of service risk in the URL downloader.
A remote code execution risk was identified in logstore. By default this was only available to managers.
In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user who also has direct access to the web server outside of the Moodle webroot could utilise a local file include to achieve remote code execution.
Wiki comments required additional sanitizing and access restrictions to prevent a stored XSS risk and potential IDOR risk.
A remote code execution risk was identified in the IMSCP activity. By default this was only available to teachers and managers.
A remote code execution risk was identified in the Lesson activity. By default this was only available to teachers and managers.
The phpCAS library included with Moodle has been upgraded to version 1.6.0, which includes a fix for a serious security issue.
It was possible to escalate stored self-XSS to stored XSS where users login via OAuth 2.
A remote code execution risk was identified where file repository reference properties are parsed.
Incorrect domain matching logic made it possible to bypass the proxy, which could result in access to hosts intended to be blocked by the proxy.
An issue in the logic used to check 0.0.0.0 against the cURL blocked hosts lists resulted in an SSRF risk.
Content output by the database auto-linking filter required additional sanitizing to prevent an XSS risk.
Insufficient sanitizing in backup resulted in an arbitrary file read risk. The capability to access this feature is only available to teachers, managers and admins by default.
Insufficient validation of profile field availability condition resulted in an SQL injection risk (by default only available to teachers and managers).
Some returnurl parameters required additional sanitizing to prevent a reflected XSS risk.
Moodle's LTI provider library did not utilise Moodle's inbuilt cURL helper, which resulted in a blind SSRF risk.
The return URL in the policy tool required extra sanitizing to prevent a reflected XSS risk.
An upstream security patch was applied to the third party VideoJS library included with Moodle, on versions affected by an XSS risk.
A remote code execution risk when restoring backup files originating from Moodle 1.9 was identified.
Recursive rendering of Mustache template helpers containing user input could, in some cases, result in an XSS risk or a page failing to load.
The Mustache template library included with Moodle has been upgraded to the latest version, which includes a fix for a serious security issue.
Insufficient sanitizing of SCORM track details presented stored XSS and blind SSRF risks.
Insufficient path checks in a lesson question import resulted in an arbitrary file read risk. The capability to access this feature is only available to teachers, managers and admins by default.
An omitted execution parameter resulted in a remote code execution risk for sites running GhostScript versions older than 9.50.
An issue in the logic used to count failed login attempts could result in the account lockout threshold being bypassed.
An SQL injection risk was identified in Badges code relating to configuring criteria.
An SQL injection risk was identified in Badges code relating to configuring criteria. Access to the relevant capability was limited to teachers and managers by default.
The "delete badge alignment" functionality did not include the necessary token check to prevent a CSRF risk.
The "delete related badge" functionality did not include the necessary token check to prevent a CSRF risk.
A URL parameter in the filetype site administrator tool required extra sanitizing to prevent a reflected XSS risk.
A remote code execution risk when restoring backup files was identified.
It was possible for a student to view their quiz grade before it had been released, using a quiz web service.
Insufficient escaping of the LaTeX preamble made it possible for site administrators to read files available to the HTTP server system account.
An authentication bypass risk was identified in the external database authentication functionality, due to a type juggling vulnerability.
A session hijack risk was identified in the Shibboleth authentication plugin. ( Note: Shibboleth authentication is disabled by default in Moodle.)
Insufficient capability checks meant message deletions were not limited to the current user.
Insufficient redirect handling made it possible to blindly bypass cURL blocked hosts/allowed ports restrictions, resulting in a blind SSRF risk. ( Note: The request response was still blocked and not available to the user.)
The file repository's URL parsing required additional recursion handling to mitigate the risk of recursion denial of service.
A remote code execution risk was identified in the Shibboleth authentication plugin. ( Note: Shibboleth authentication is disabled by default in Moodle.)
An SQL injection risk was identified in the library fetching a user's recent courses
An SQL injection risk was identified in the library fetching a user's enrolled courses
A denial-of-service risk was identified in the draft files area, due to it not respecting user file upload limits.
An SQL injection risk existed on sites with MNet enabled and configured, via an XML-RPC call from the connected peer host. Note that this required site administrator access or access to the keypair.
It was possible for a student to view their quiz grade before it had been released, using a quiz web service.
Text-based feedback answers required additional sanitizing to prevent stored XSS and blind SSRF risks.
The ID number user profile field required additional sanitizing to prevent a stored XSS risk.
It was possible for site administrators to execute arbitrary PHP scripts via a PHP include used during Shibboleth authentication.
If the TeX notation filter was enabled, additional sanitizing of TeX content was required to prevent the risk of stored XSS.
The decompressed size of zip files was not checked against available user quota before unzipping them, which could lead to a denial of service risk.
The filter in the tag manager required extra sanitizing to prevent a reflected XSS risk.
yui_combo needed to limit the amount of files it can load to help mitigate the risk of denial of service.
Teachers of a course were able to assign themselves the manager role within that course.
It was possible to create a SCORM package in such a way that when added to a course, it could be interacted with via web services in order to achieve remote code execution.
MathJax versions 2.7.2 and earlier contain a stored XSS risk. The MathJax URL has been updated to reference a newer version, which has the vulnerability patched.
X-Forwarded-For headers could be used to spoof a user's IP, in order to bypass remote address checks.
Fatal error messages required extra sanitizing to prevent reflected XSS risks on some pages.
OAuth 2 providers who do not verify users' email address changes require additional verification during sign-up to reduce the risk of account compromise.
The mobile launch endpoint contained an open redirect in some circumstances, which could result in a user's mobile access token being exposed. ( Note: This does not affect sites with a forced URL scheme configured, mobile service disabled, or where the mobile app login method is "via the app").
Mustache helper tags that were included in template contexts were not being escaped before that context was injected into another Mustache helper, which could result in script injection in some templates.
Users could assign themselves an escalated role within courses or content accessed via LTI, by modifying the request to the LTI publisher site.
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.
The login form is not protected by a token to prevent login cross-site request forgery.
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.
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.
Insufficient capability checks made it possible for users with access to restore glossaries in courses to restore them into the global site glossary.
The cURL wrapper in Moodle stripped HTTPAUTH and USERPWD headers during emulated redirects, but retained other original request headers, so HTTP authorization header information could be unintentionally sent in requests to redirect URLs.
Some hidden user profile fields were visible in gradebook reports, which could result in some users without the "view hidden user fields" capability having access to the information.
When creating an export of site administration presets, some sensitive secrets/keys were not being excluded from the export, which could result in them being unintentionally leaked if the presets were shared with a third party.
A unique key should be generated for a user's QR login key and their auto-login key, so the same key cannot be used interchangeably between the two.
The cURL wrapper in Moodle retained the original request headers when following redirects, so HTTP authorization header information could be unintentionally sent in requests to redirect URLs.
Insufficient escaping of calendar event titles resulted in a stored XSS risk in the event deletion prompt.
Insufficient capability checks meant it was possible for users to gain access to BigBlueButton join URLs they did not have permission to access.
Actions in the admin management of analytics models did not include the necessary token to prevent a CSRF risk.
The site log report required additional encoding of event descriptions to ensure any HTML in the content is displayed in plaintext instead of being rendered.
Actions in the admin preset tool did not include the necessary token to prevent a CSRF risk.
ID numbers displayed in the lesson overview report required additional sanitizing to prevent a stored XSS risk.
Insufficient escaping of participants' names in the participants page table resulted in a stored XSS risk when interacting with some features.
Additional sanitizing was required when opening the equation editor, to prevent a stored XSS risk when editing another user's equation.
Insufficient checks in a web service made it possible to add comments to the comments block on another user's dashboard when it was not otherwise available (eg on their profile page).
The link to update all installed language packs did not include the necessary token to prevent a CSRF risk.
Separate Groups mode restrictions were not honoured when performing a forum export, which would export forum data for all groups. By default this only provided additional access to non-editing teachers.
Separate Groups mode restrictions were not honoured in the H5P attempts report, which would display users from other groups. By default this only provided additional access to non-editing teachers.
The URL parameters accepted by forum search were not limited to the allowed parameters.
The mtrace output when running a task in the admin UI required additional sanitizing to prevent an XSS risk.
Insufficient capability checks meant it was possible for all users to view the recipients of badges.
Separate Groups mode restrictions were not honoured in survey response reports, which would display users from other groups.
Separate Groups mode restrictions were not honoured in the Logs and Live logs course reports, which would display users from other groups.
Separate Groups mode restrictions were not honoured in the forum summary report, which would display users from other groups.
Insufficient web service capability checks made it possible to move categories a user had permission to manage, to a parent category they did not have the capability to manage.
Stronger revision number limitations were required on file serving endpoints to improve cache poisoning protection.
The course upload preview contained an XSS risk for users uploading unsafe data.
H5P metadata automatically populated the author with the user's username, which could be sensitive information.
The CSV grade import method contained an XSS risk for users importing the spreadsheet, if it contained unsafe content.
Insufficient limitations made it possible for students to bypass sequential navigation during a quiz attempt.
Insufficient capability checks resulted in competency framework tools being available to users without the relevant capability.
The admin view all policies page URL required additional sanitizing to prevent an open redirect risk.
The JQuery UI library included with Moodle has been upgraded to version 1.13.2, which includes fixes for security issues.
Insufficient capability checks made it possible to fetch other users' message processor preferences data.
Permission overrides on individual blocks in the system dashboard did not cascade to user dashboards.
A limited SQL injection risk was identified on the Mnet SSO access control page.
A limited SQL injection risk was identified in functionality used by the Wiki activity when listing pages.
The course participation report required additional checks to prevent roles being displayed which the user did not have access to view.
Insufficient filtering of grade report history made it possible for teachers to access the names of users they could not otherwise access.
The Mustache pix helper contained a potential Mustache injection risk if combined with user input (note: This did not appear to be implemented/exploitable anywhere in the core Moodle LMS).
If the algebra filter was enabled but not functional (eg the necessary binaries were missing from the server), it presented an XSS risk.
Insufficient limitations on the "start page" preference made it possible to set that preference for another user. (Note: This was still limited to the pre-defined start page options)
A user's CSRF token was unnecessarily included in the URL when being redirected to a course they have just restored.
Insufficient limitations in some quiz web services made it possible for students to bypass sequential navigation during a quiz attempt.
The H5P activity attempts report did not filter by groups, which in separate groups mode could reveal information to non-editing teachers about attempts/users in groups they should not have access to.
A limited SQL injection risk was identified in the "browse list of users" site administration page.
The upstream Moodle machine learning backend and its reference in /lib/mlbackend/python/classes/processor.php were upgraded, which includes some security updates.
A minor reflected XSS risk was identified in the LTI module. This did not impact authenticated users.
The mobile auto-login URL required additional sanitizing to prevent an open redirect risk.
Global search results could include author information on some activities where a user may not otherwise have access to it.
The description user field was not hidden when being set as a hidden user field.
ID numbers displayed when bulk allocating markers to assignments required additional sanitizing to prevent a stored XSS risk.
The CKEditor included in the h5p-editor-php-library within Moodle has been upgraded to the latest version, which includes security fixes.
The PHPMailer library included with Moodle has been upgraded to the latest version, which includes security fixes.
Users with the capability to configure badge criteria (teachers and managers by default) were able to configure course badges with profile field criteria, which should only be available for site badges.
Insufficient capability checks could allow users with the moodle/site:uploadusers capability to delete users, without having the necessary moodle/user:delete capability.
Insufficient capability checks could lead to users accessing their grade report for courses where they did not have the required gradereport/user:view capability.
The calendar:manageentries capability allowed managers to access or modify any calendar event, but should have been restricted from accessing user level events.
Insufficient capability checks made it possible to fetch other users' calendar action events.
The upstream Moodle machine learning backend and its reference in /lib/mlbackend/python/classes/processor.php were upgraded, which includes some security updates.
Insufficient capability checks made it possible for teachers to download users outside of their courses.
In some circumstances, email notifications of messages could have the link back to the original message hidden by HTML, which may pose a phishing risk.
Users' names required additional sanitizing in the account confirmation email, to prevent a self-registration phishing risk.
ID numbers exported in HTML data formats required additional sanitizing to prevent a local stored XSS risk. Note that the XSS was part of the locally downloaded file and not on the Moodle site's domain.
Insufficient capability checks made it possible to remove other users' calendar URL subscriptions.
The redirect URI in the LTI authorization endpoint required extra sanitizing to prevent reflected XSS and open redirect risks.
ID numbers displayed in the quiz grading report required additional sanitizing to prevent a stored XSS risk.
The JQuery version used by Moodle required upgrading to 3.5.1 to patch some published potential vulnerabilities.
The web service responsible for fetching other users' enrolled courses did not validate that the requesting user had permission to view that information in each course.
When creating a user account, it was possible to verify the account without having access to the verification email link/secret.
It was possible for some users without permission to view other users' full names to do so via the online users block.
Messaging did not impose a character limit when sending messages, which could result in client-side (browser) denial of service for users receiving very large messages.
If the upload course tool was used to delete an enrolment method which did not exist or was not already enabled, the tool would erroneously enable that enrolment method. This could lead to unintended users gaining access to the course.
Some database module web services allowed students to add entries within groups they did not belong to.
Insufficient capability checks could lead to users with the ability to course restore adding additional capabilities to roles within that course.
Users' enrolment capabilities were not being sufficiently checked when they restored into an existing course, which could lead to them unenrolling users without having permission to do so.
Users with "Log in as" capability in a course context (typically, course managers) may gain access to some site administration capabilities by "logging in as" a System manager.
Insufficient input escaping was applied to the PHP unit webrunner admin tool.
Users viewing the grade history report without the 'access all groups' capability were not restricted to viewing grades of users within their own groups.
An open redirect existed in the Lesson edit page.
When a cohort role assignment was removed, the associated capabilites were not being revoked (where applicable).
If a forum's subscription mode was set to "forced subscription", the forum's subscribe link contained an open redirect.
Activity creation capabilities were not correctly respected when selecting the activity to use for a course in single activity mode.
The analytics Python Machine Learning backend has received some security fixes, resulting in the required PIP package version being increased. ( Note: Sites using the PHP ML backend, or not using analytics are not affected)
Users with the capability to create courses were assigned as a teacher in those courses, regardless of whether they had the capability to be automatically assigned that role.
The third party TCPDF library used by Moodle required updating to patch bug fixes, including a security fix (see CVE for more details).
Teachers in an assignment group could modify group overrides for other groups in the same assignment.
Teachers in a quiz group could modify group overrides for other groups in the same quiz.
Users with permission to delete entries from a glossary were able to delete entries from other glossaries they did not have direct access to.
A sesskey (CSRF) token was not being utilised by the XML loading/unloading admin tool.
The size of users' private file uploads via email were not correctly checked, so their quota allowance could be exceeded.
The form to upload cohorts contained a redirect field, which was not restricted to internal URLs.
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.
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 '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.
Advisory titles and descriptions are Moodle's own words, from the security announcements on moodle.org, and every entry links to its source. This list is a lower bound: Moodle stops issuing advisories for a branch once it leaves security support. MDL Shield is an independent service and is not affiliated with or endorsed by Moodle Pty Ltd.