| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| help.php in Moodle before 1.6.2 does not check the existence of certain help files before including them, which might allow remote authenticated users to obtain the path in an error message. |
| lib/setup.php in Moodle before 1.6.2 sets the error reporting level to 7 to display E_WARNING messages to users even if debugging is disabled, which might allow remote authenticated users to obtain sensitive information by triggering the messages. |
| Moodle before 1.6.2 does not properly validate the module instance id when creating a course module object, which has unspecified impact and remote attack vectors. |
| SQL injection vulnerability in sql.php in the Glossary module in Moodle 1.4.1 and earlier allows remote attackers to modify SQL statements. |
| Unknown vulnerability in Moodle before 1.2 allows teachers to log in as administrators. |
| Multiple SQL injection vulnerabilities in the get_record function in datalib.php in Moodle 1.5.2 allow remote attackers to execute arbitrary SQL commands via the id parameter in (1) category.php and (2) info.php. |
| Directory traversal vulnerability in file.php in Moodle 1.4.2 and earlier allows remote attackers to read arbitrary session files for known session IDs via a .. (dot dot) in the file parameter. |
| Dynamic code evaluation vulnerability in tests/tmssql.php test script in ADOdb for PHP before 4.70, as used in multiple products including (1) Mantis, (2) PostNuke, (3) Moodle, (4) Cacti, (5) Xaraya, (6) PhpOpenChat, possibly (7) MAXdev MD-Pro, and (8) Simplog, allows remote attackers to execute arbitrary PHP functions via the do parameter, which is saved in a variable that is then executed as a function, as demonstrated using phpinfo. |
| Incorrect CSRF token checks resulted in multiple CSRF risks. |
| Virtual Programming Lab for Moodle up to v4.2.3 was discovered to contain a cross-site scripting (XSS) vulnerability via the component vplide.js. |
| Actions in the admin management of analytics models did not include the necessary token to prevent a CSRF risk. |
| In Moodle, ID numbers displayed in the quiz override screens required additional sanitizing to prevent a stored XSS risk. |
| In moodle, ID numbers displayed in the web service token list required additional sanitizing to prevent a stored XSS risk. |
| In Moodle, insufficient capability checks meant message deletions were not limited to the current user. |
| In Moodle, the file repository's URL parsing required additional recursion handling to mitigate the risk of recursion denial of service. |
| In Moodle, 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. |
| In Moodle, Users' names required additional sanitizing in the account confirmation email, to prevent a self-registration phishing risk. |
| In Moodle, ID numbers exported in HTML data formats required additional sanitizing to prevent a local stored XSS risk. |
| In Moodle, insufficient capability checks made it possible to remove other users' calendar URL subscriptions. |
| In Moodle, a remote code execution risk was identified in the Shibboleth authentication plugin. |
