Moodle Moodle 2.7.8

A session fixation vulnerability in Moodle 3.x through 3.11.18 allows unauthenticated attackers to hijack user sessions via the sesskey parameter. The sesskey can be obtained without authentication and reused within the OAuth2 login flow, resulting in the victim's session being linked to the attacker's. Successful exploitation results in full account takeover. According to the Moodle Releases page, "Bug fixes for security issues in 3.11.x ended 11 December 2023." NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

A flaw was discovered in Moodle. Additional checks were required to ensure that users can only access cohort data they are authorized to retrieve.

A flaw was found in Moodle. Insufficient capability checks in a messaging web service allowed users to view other users' names and online statuses.

A flaw was found in Moodle. Additional checks were required to prevent users from deleting course sections they did not have permission to modify.

A flaw was found in Moodle. The return URL in the policy tool required additional sanitizing to prevent a reflected Cross-site scripting (XSS) risk.

A flaw was found in Moodle. 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 flaw was found in Moodle. 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.

A flaw was found in Moodle. Insufficient capability checks made it possible for a user enrolled in a course to access some details, such as the full name and profile image URL, of other users they did not have permission to access.

A flaw was found in Moodle. The analysis request action in the Brickfield tool did not include the necessary token to prevent a Cross-site request forgery (CSRF) risk.

A security vulnerability was found in Moodle where confidential information that prevents cross-site request forgery (CSRF) attacks was shared publicly through the site's URL. This vulnerability occurred specifically on two types of pages within the mod_data module: edit and delete pages.

A flaw was found in Moodle. This vulnerability allows unauthorized users to access and view RSS feeds due to insufficient capability checks.

A security vulnerability was discovered in Moodle that allows anyone to duplicate existing tours without needing to log in due to a lack of protection against cross-site request forgery (CSRF) attacks.

A security vulnerability was discovered in Moodle that allows students to enroll themselves in courses without completing all the necessary safety checks. Specifically, users can sign up for courses prematurely, even if they haven't finished two-step verification processes.

A flaw has was found in Moodle where anonymous assignment submissions can be de-anonymized via search, revealing student identities.

A security vulnerability was discovered in Moodle that allows some users to access sensitive information about other students before they finish verifying their identities using two-factor authentication (2FA).

A security vulnerability was discovered in Moodle that can allow hackers to gain access to sensitive information about students and prevent them from logging into their accounts, even after they had completed two-factor authentication (2FA).

A flaw has been identified in Moodle where insufficient capability checks in certain grade reports allowed users without the necessary permissions to access hidden grades.

A flaw has been identified in Moodle where, on certain sites, unauthenticated users could retrieve sensitive user data—including names, contact information, and hashed passwords—via stack traces returned by specific API calls. Sites with PHP configured with zend.exception_ignore_args = 1 in the php.ini file are not affected by this vulnerability.

An SQL injection risk was identified in the module list filter within course search.

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 question bank filter required additional sanitizing to prevent a reflected XSS risk.

Description information displayed in the site administration live log required additional sanitizing to prevent a stored XSS risk.

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.