VuXML ID | Description |
b3531fe1-2b03-11df-b6db-00248c9b4be7 | drupal -- multiple vulnerabilities
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.
Discovery 2010-03-03 Entry 2010-03-08 drupal5
< 5.22
drupal6
< 6.16
http://drupal.org/node/731710
|
be927298-6f97-11de-b444-001372fd0af2 | drupal -- multiple vulnerabilities
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.
Discovery 2009-07-01 Entry 2009-07-13 Modified 2010-05-02 drupal5
< 5.19
drupal6
< 6.13
CVE-2009-2372
CVE-2009-2374
CVE-2009-2373
http://drupal.org/node/507572
http://secunia.com/advisories/35681
|
ecedde1c-5128-11dd-a4e1-0030843d3802 | drupal -- multiple vulnerabilities
The Drupal Project reports:
Free tagging taxonomy terms can be used to insert arbitrary script
and HTML code (cross site scripting or XSS) on node preview pages. A
successful exploit requires that the victim selects a term containing
script code and chooses to preview the node. This issue affects Drupal
6.x only. Some values from OpenID providers are output without being
properly escaped, allowing malicious providers to insert arbitrary script
and HTML code (XSS) into user pages. This issue affects Drupal 6.x only.
filter_xss_admin() has been hardened to prevent use of the object HTML
tag in administrator input.
Translated strings (5.x, 6.x) and OpenID identities (6.x) are
immediately deleted upon accessing a properly formatted URL, making
such deletion vulnerable to cross site request forgeries (CSRF). This
may lead to unintended deletion of translated strings or OpenID
identities when a sufficiently privileged user visits a page or site
created by a malicious person.
When contributed modules such as Workflow NG terminate the current
request during a login event, user module is not able to regenerate
the user's session. This may lead to a session fixation attack, when a
malicious user is able to control another users' initial session ID.
As the session is not regenerated, the malicious user may use the
'fixed' session ID after the victim authenticates and will have the
same access. This issue affects both Drupal 5 and Drupal 6.
Schema API uses an inappropriate placeholder for 'numeric' fields
enabling SQL injection when user-supplied data is used for such
fields.This issue affects Drupal 6 only.
Discovery 2008-07-09 Entry 2008-07-13 Modified 2010-05-12 drupal5
< 5.8
drupal6
< 6.3
CVE-2008-3218
CVE-2008-3221
http://drupal.org/node/280571
http://secunia.com/advisories/31028/
|
6f736456-c060-11dc-982e-001372fd0af2 | drupal -- cross site scripting (utf8)
The Drupal Project reports:
When outputting plaintext Drupal strips potentially dangerous
HTML tags and attributes from HTML, and 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 invalid in the UTF8
specification are not handled properly by Internet Explorer 6
and may lead it to see a multibyte start character where none is
present. Internet Explorer 6 then consumes a number of
subsequent UTF-8 characters. This may lead to unsafe attributes
that were outside a tag for the filter to appear inside a tag
for Internet Explorer 6. This behaviour can then be used to
insert and execute javascript in the context of the website.
Discovery 2008-01-10 Entry 2008-01-11 Modified 2010-05-12 drupal5
< 5.6
drupal4
< 4.7.11
CVE-2008-0273
http://drupal.org/node/208564
http://secunia.com/advisories/28422/
|
fa708908-a8c7-11dc-b41d-000fb5066b20 | drupal -- SQL injection vulnerability
The Drupal Project reports:
The function taxonomy_select_nodes() directly injects variables
into SQL queries instead of using placeholders. While taxonomy
module itself validates the input passed to
taxonomy_select_nodes(), this is a weakness in Drupal core.
Several contributed modules, such as taxonomy_menu, ajaxLoader,
and ubrowser, directly pass user input to taxonomy_select_nodes(),
enabling SQL injection attacks by anonymous users.
Discovery 2007-12-05 Entry 2007-12-12 drupal5
< 5.4
drupal4
< 4.7.9
CVE-2007-6299
http://drupal.org/node/198162
http://secunia.com/advisories/27932/
|
751823d4-f189-11de-9344-00248c9b4be7 | drupal -- multiple cross-site scripting
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.
Discovery 2009-12-16 Entry 2009-12-25 Modified 2010-05-02 drupal5
< 5.21
drupal6
< 6.15
CVE-2009-4370
http://drupal.org/node/661586
|
7a1ab8d4-35c1-11de-9672-0030843d3802 | drupal -- cross site scripting
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.
Discovery 2009-04-30 Entry 2009-04-30 Modified 2010-05-02 drupal5
< 5.17
drupal6
< 6.11
CVE-2009-1575
CVE-2009-1576
http://drupal.org/node/449078
|
12efc567-9879-11dd-a5e7-0030843d3802 | drupal -- multiple vulnerabilities
The Drupal Project reports:
A logic error in the core upload module validation allowed
unprivileged users to attach files to content. Users can view files
attached to content which they do not otherwise have access to.
If the core upload module is not enabled, your site will not be
affected.
A deficiency in the user module allowed users who had been blocked
by access rules to continue logging into the site under certain
conditions. If you do not use the 'access rules' functionality in core,
your site will not be affected.
The BlogAPI module does not implement correct validation for
certain content fields, allowing for values to be set for fields which
would otherwise be inaccessible on an internal Drupal form. We have
hardened these checks in BlogAPI module for this release, but the
security team would like to re-iterate that the 'Administer content
with BlogAPI' permission should only be given to trusted users.
If the core BlogAPI module is not enabled, your site will not be
affected.
A weakness in the node module API allowed for node validation to be
bypassed in certain circumstances for contributed modules implementing
the API. Additional checks have been added to ensure that validation
is performed in all cases. This vulnerability only affects sites using
one of a very small number of contributed modules, all of which will
continue to work correctly with the improved API. None of them were
found vulnerable, so our correction is a preventative measure.
Discovery 2008-10-08 Entry 2008-10-12 Modified 2010-05-12 drupal5
< 5.11
drupal6
< 6.5
CVE-2008-4791
CVE-2008-4792
CVE-2008-4793
http://drupal.org/node/318706
http://secunia.com/advisories/32200/
http://secunia.com/advisories/32201/
http://secunia.com/advisories/32198/
|
a6605f4b-4067-11de-b444-001372fd0af2 | drupal -- cross-site scripting
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.
Discovery 2009-05-13 Entry 2009-05-14 Modified 2009-05-16 drupal5
< 5.18
drupal6
< 6.12
http://drupal.org/node/461886
http://secunia.com/advisories/35045
|
9c00d446-8208-11dc-9283-0016179b2dd5 | drupal --- multiple vulnerabilities
The Drupal Project reports:
In some circumstances Drupal allows user-supplied data to
become part of response headers. As this user-supplied data
is not always properly escaped, this can be exploited by
malicious users to execute HTTP response splitting attacks
which may lead to a variety of issues, among them cache
poisoning, cross-user defacement and injection of arbitrary
code.
The Drupal installer allows any visitor to provide credentials
for a database when the site's own database is not reachable. This
allows attackers to run arbitrary code on the site's server.
An immediate workaround is the removal of the file install.php
in the Drupal root directory.
The allowed extension list of the core Upload module contains
the extension HTML by default. Such files can be used to execute
arbitrary script code in the context of the affected site when a
user views the file. Revoking upload permissions or removing the
.html extension from the allowed extension list will stop uploads
of malicious files. but will do nothing to protect your site
againstfiles that are already present. Carefully inspect the file
system path for any HTML files. We recommend you remove any HTML
file you did not update yourself. You should look for , CSS
includes, Javascript includes, and onerror="" attributes if
you need to review files individually.
The Drupal Forms API protects against cross site request
forgeries (CSRF), where a malicious site can cause a user
to unintentionally submit a form to a site where he is
authenticated. The user deletion form does not follow the
standard Forms API submission model and is therefore not
protected against this type of attack. A CSRF attack may
result in the deletion of users.
The publication status of comments is not passed during the
hook_comments API operation, causing various modules that rely
on the publication status (such as Organic groups, or Subscriptions)
to mail out unpublished comments.
Discovery 2007-10-17 Entry 2007-10-24 drupal4
< 4.7.8
drupal5
< 5.3
CVE-2007-5597
CVE-2007-5596
CVE-2007-5595
CVE-2007-5594
CVE-2007-5593
http://drupal.org/node/184315
http://drupal.org/node/184316
http://drupal.org/node/184348
http://drupal.org/node/184354
http://drupal.org/node/184320
http://secunia.com/advisories/27292
http://secunia.com/advisories/27292
http://secunia.com/advisories/27292
http://secunia.com/advisories/27290
http://secunia.com/advisories/27290
|
bad1b090-a7ca-11de-873f-0030843d3802 | drupal -- multiple vulnerabilities
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.
Discovery 2009-09-17 Entry 2009-09-22 drupal5
< 5.20
drupal6
< 6.14
http://drupal.org/node/579482
http://secunia.com/advisories/36787/
http://secunia.com/advisories/36786/
http://secunia.com/advisories/36781/
http://secunia.com/advisories/36776/
http://secunia.com/advisories/36785/
|
4451a4c9-c05e-11dc-982e-001372fd0af2 | drupal -- cross site request forgery
The Drupal Project reports:
The aggregator module fetches items from RSS feeds and makes
them available on the site. The module provides an option to
remove items from a particular feed. This has been implemented
as a simple GET request and is therefore vulnerable to cross
site request forgeries. For example: Should a privileged user
view a page containing an tag with a specially
constructed src pointing to a remove items URL, the items would
be removed.
Discovery 2008-01-10 Entry 2008-01-11 Modified 2010-05-12 drupal5
< 5.6
drupal4
< 4.7.11
CVE-2008-0272
http://drupal.org/node/208562
http://secunia.com/advisories/28422/
|
070b5b22-6d74-11dd-aa18-0030843d3802 | drupal -- multiple vulnerabilities
The Drupal Project reports:
A bug in the output filter employed by Drupal makes it possible
for malicious users to insert script code into pages (cross site
scripting or XSS). A bug in the private filesystem trusts the MIME
type sent by the browser, enabling malicious users with the ability
to upload files to execute cross site scripting attacks.
The BlogAPI module does not validate the extension of uploaded
files, enabling users with the "administer content with blog api"
permission to upload harmful files. This bug affects both Drupal
5.x and 6.x.
Drupal forms contain a token to protect against cross site
request forgeries (CSRF). The token may not be validated properly
for cached forms and forms containing AHAH elements. This bug
affects Drupal 6.x.
User access rules can be added or deleted upon accessing a
properly formatted URL, making such modifications vulnerable to
cross site request forgeries (CSRF). This may lead to unintended
addition or deletion of an access rule when a sufficiently
privileged user visits a page or site created by a malicious
person. This bug affects both Drupal 5.x and 6.x.
The Upload module in Drupal 6 contains privilege escalation
vulnerabilities for users with the "upload files" permission. This
can lead to users being able to edit nodes which they are normally
not allowed to, delete any file to which the webserver has
sufficient rights, and download attachments of nodes to which they
have no access. Harmful files may also be uploaded via cross site
request forgeries (CSRF). These bugs affect Drupal 6.x.
Discovery 2008-08-13 Entry 2008-08-18 Modified 2010-05-12 drupal5
< 5.10
drupal6
< 6.4
CVE-2008-3742
CVE-2008-3740
CVE-2008-3741
CVE-2008-3743
CVE-2008-3744
CVE-2008-3745
http://secunia.com/advisories/31462/
|
609c790e-ce0a-11dd-a721-0030843d3802 | drupal -- multiple vulnerabilities
The Drupal Project reports:
The update system is vulnerable to Cross site request forgeries.
Malicious users may cause the superuser (user 1) to execute old
updates that may damage the database.
When an input format is deleted, not all existing content on a site
is updated to reflect this deletion. Such content is then displayed
unfiltered. This may lead to cross site scripting attacks when harmful
tags are no longer stripped from 'malicious' content that was posted
earlier.
Discovery 2008-12-11 Entry 2008-12-19 Modified 2010-05-02 drupal5
< 5.14
drupal6
< 6.8
CVE-2008-6533
http://drupal.org/node/345441
http://secunia.com/advisories/33112/
|
f0fa19dd-c060-11dc-982e-001372fd0af2 | drupal -- cross site scripting (register_globals)
The Drupal Project reports:
When theme .tpl.php files are accessible via the web and the PHP
setting register_globals is set to enabled, anonymous users are
able to execute cross site scripting attacks via specially
crafted links.
Drupal's .htaccess attempts to set register_globals to disabled
and also prevents access to .tpl.php files. Only when both these
measures are not effective and your PHP interpreter is
configured with register_globals set to enabled, will this issue
affect you.
Discovery 2008-01-10 Entry 2008-01-11 Modified 2010-05-12 drupal5
< 5.6
drupal4
< 4.7.11
CVE-2008-0274
http://drupal.org/node/208565
http://secunia.com/advisories/28422/
|
706c9eef-a077-11dd-b413-001372fd0af2 | drupal -- multiple vulnerabilities
The Drupal Project reports:
On a server configured for IP-based virtual hosts, Drupal may be
caused to include and execute specifically named files outside
of its root directory. This bug affects both Drupal 5 and
Drupal 6.
The title of book pages is not always properly escaped, enabling
users with the "create book content" permission or the
permission to edit any node in the book hierarchy to insert
arbitrary HTML and script code into pages. Such a Cross site
scripting attack may lead to the attacker gaining administrator
access. This bug affects Drupal 6.
Discovery 2008-10-22 Entry 2008-10-22 Modified 2010-05-12 drupal5
< 5.12
drupal6
< 6.6
CVE-2008-6170
http://drupal.org/node/324824
|
6d85dc62-f2bd-11dd-9f55-0030843d3802 | drupal -- multiple vulnerabilities
Drupal Team reports:
The Content Translation module for Drupal 6.x enables users to make
a translation of an existing item of content (a node). In that proces
the existing node's content is copied into the new node's submission
form.
The module contains a flaw that allows a user with the 'translate
content' permission to potentially bypass normal viewing access
restrictions, for example allowing the user to see the content of
unpublished nodes even if they do not have permission to view
unpublished nodes.
When user profile pictures are enabled, the default user profile
validation function will be bypassed, possibly allowing invalid user
names or e-mail addresses to be submitted.
Discovery 2009-01-14 Entry 2009-02-04 drupal5
< 5.15
drupal6
< 6.9
http://drupal.org/node/358957
http://secunia.com/advisories/33550/
http://secunia.com/advisories/33500/
http://secunia.com/advisories/33542/
|