FreshPorts - VuXML

Drupal Team reports:

The Contact module does not correctly handle certain user input when displaying category information. Users privileged to create contact categories can insert arbitrary HTML and script code into the contact module administration page. Such a cross-site scripting attack may lead to the malicious user gaining administrative access.

The Menu module does not correctly handle certain user input when displaying the menu administration overview. Users privileged to create new menus can insert arbitrary HTML and script code into the menu module administration page. Such a cross-site scripting attack may lead to the malicious user gaining administrative access.

< 5.21

< 6.15

Drupal Team reports:

A user-supplied value is directly output during installation allowing a malicious user to craft a URL and perform a cross-site scripting attack. The exploit can only be conducted on sites not yet installed.

The API function drupal_goto() is susceptible to a phishing attack. An attacker could formulate a redirect in a way that gets the Drupal site to send the user to an arbitrarily provided URL. No user submitted data will be sent to that URL.

Locale module and dependent contributed modules do not sanitize the display of language codes, native and English language names properly. While these usually come from a preselected list, arbitrary administrator input is allowed. This vulnerability is mitigated by the fact that the attacker must have a role with the 'administer languages' permission.

Under certain circumstances, a user with an open session that is blocked can maintain his/her session on the Drupal site, despite being blocked.

< 5.22

< 6.16

Drupal Team reports:

The core OpenID module does not correctly implement Form API for the form that allows one to link user accounts with OpenID identifiers. A malicious user is therefore able to use cross site request forgeries to add attacker controlled OpenID identities to existing accounts. These OpenID identities can then be used to gain access to the affected accounts.

The OpenID module is not a compliant implementation of the OpenID Authentication 2.0 specification. An implementation error allows a user to access the account of another user when they share the same OpenID 2.0 provider.

File uploads with certain extensions are not correctly processed by the File API. This may lead to the creation of files that are executable by Apache. The .htaccess that is saved into the files directory by Drupal should normally prevent execution. The files are only executable when the server is configured to ignore the directives in the .htaccess file.

Drupal doesn't regenerate the session ID when an anonymous user follows the one time login link used to confirm email addresses and reset forgotten passwords. This enables a malicious user to fix and reuse the session id of a victim under certain circumstances.

< 5.20

< 6.14

The Drupal Security Team reports:

Cross-site scripting

The Forum module does not correctly handle certain arguments obtained from the URL. By enticing a suitably privileged user to visit a specially crafted URL, a malicious user is able to insert arbitrary HTML and script code into forum pages. Such a cross-site scripting attack may lead to the malicious user gaining administrative access. Wikipedia has more information about cross-site scripting (XSS).

User signatures have no separate input format, they use the format of the comment with which they are displayed. A user will no longer be able to edit a comment when an administrator changes the comment's input format to a format that is not accessible to the user. However they will still be able to modify their signature, which will then be processed by the new input format.

If the new format is very permissive, via their signature, the user may be able to insert arbitrary HTML and script code into pages or, when the PHP filter is enabled for the new format, execute PHP code. This issue affects Drupal 6.x only.

When an anonymous user fails to login due to mistyping his username or password, and the page he is on contains a sortable table, the (incorrect) username and password are included in links on the table. If the user visits these links the password may then be leaked to external sites via the HTTP referer.

In addition, if the anonymous user is enticed to visit the site via a specially crafted URL while the Drupal page cache is enabled, a malicious user might be able to retrieve the (incorrect) username and password from the page cache.

< 5.19

< 6.13

Drupal Security Team reports:

When outputting user-supplied data Drupal strips potentially dangerous HTML attributes and tags or escapes characters which have a special meaning in HTML. This output filtering secures the site against cross site scripting attacks via user input.

Certain byte sequences that are valid in the UTF-8 specification are potentially dangerous when interpreted as UTF-7. Internet Explorer 6 and 7 may decode these characters as UTF-7 if they appear before the meta http-equiv="Content-Type" tag that specifies the page content as UTF-8, despite the fact that Drupal also sends a real HTTP header specifying the content as UTF-8. This behaviour enables malicious users to insert and execute Javascript in the context of the website if site visitors are allowed to post content.

In addition, Drupal core also has a very limited information disclosure vulnerability under very specific conditions. If a user is tricked into visiting the site via a specially crafted URL and then submits a form (such as the search box) from that page, the information in their form submission may be directed to a third-party site determined by the URL and thus disclosed to the third party. The third party site may then execute a CSRF attack against the submitted form.

< 5.17

< 6.11

The Drupal Security Team reports:

When outputting user-supplied data Drupal strips potentially dangerous HTML attributes and tags or escapes characters which have a special meaning in HTML. This output filtering secures the site against cross site scripting attacks via user input.

Certain byte sequences that are valid in the UTF-8 specification are potentially dangerous when interpreted as UTF-7. Internet Explorer 6 and 7 may decode these characters as UTF-7 if they appear before the tag that specifies the page content as UTF-8, despite the fact that Drupal also sends a real HTTP header specifying the content as UTF-8. This enables attackers to execute cross site scripting attacks with UTF-7. SA-CORE-2009-005 - Drupal core - Cross site scripting contained an incomplete fix for the issue. HTML exports of books are still vulnerable, which means that anyone with edit permissions for pages in outlines is able to insert arbitrary HTML and script code in these exports.

Additionally, the taxonomy module allows users with the 'administer taxonomy' permission to inject arbitrary HTML and script code in the help text of any vocabulary.

< 5.18

< 6.12