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.
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.
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.
backup/backup_scheduled.php in Moodle before 1.6.2 generates trace data with the full backup pathname even when debugging is disabled, which might allow attackers to obtain the pathname.
login/forgot_password.php in Moodle before 1.6.2 allows remote attackers to obtain sensitive information (e-mail addresses and Moodle account names) via a find action.
Multiple cross-site scripting (XSS) vulnerabilities in Moodle before 1.6.2 might allow remote attackers to inject arbitrary web script or HTML via (1) the choose parameter in files/index.php and (2) the sub parameter in doc/index.php.
Moodle before 1.6.2, when the configuration lacks (1) algebra or (2) tex filters, allows remote authenticated users to write LaTeX or MimeTeX output files to the top level of the dataroot directory via (a) filter/algebra/pix.php or (b) filter/tex/pix.php.
course/jumpto.php in Moodle before 1.6.2 does not validate the session key (sesskey) before providing content from arbitrary local URIs, which allows remote attackers to obtain sensitive information via the jump parameter.
Multiple cross-site scripting (XSS) vulnerabilities in Moodle 1.6.1 and earlier might allow remote attackers to inject arbitrary web script or HTML via unspecified parameters to (1) doc/index.php or (2) files/index.php.
SQL injection vulnerability in blog/edit.php in Moodle 1.6.1 and earlier allows remote attackers to execute arbitrary SQL commands via the format parameter as stored in the $blogEntry variable, which is not properly handled by the insert_record function, which calls _adodb_column_sql in the adodb layer (lib/adodb/adodb-lib.inc.php), which does not convert the data type to an int.