| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Multiple cross-site scripting (XSS) vulnerabilities in the Heartbeat module 6.x before 6.x-4.9 for Drupal allow remote authenticated users to inject arbitrary web script or HTML via unspecified vectors. |
| Multiple cross-site scripting (XSS) vulnerabilities in the Storm module 5.x and 6.x before 6.x-1.33 for Drupal allow remote authenticated users, with certain module privileges, to inject arbitrary web script or HTML via the (1) fullname, (2) address, (3) city, (4) provstate (aka state), (5) phone, or (6) taxid parameter in a stormorganization action to index.php; the (7) name parameter in a stormperson action to index.php; the (8) stepno (aka Step no.) or (9) title parameter in a stormtask action to index.php; the (10) title (aka Project) parameter in a stormticket action to index.php; or (11) unspecified parameters in a stormproject action to index.php. NOTE: some of these details are obtained from third party information. |
| Multiple cross-site scripting (XSS) vulnerabilities in the Rotor Banner module 5.x before 5.x-1.8 and 6.x before 6.x-2.5 for Drupal allow remote authenticated users, with "create rotor item" or "edit any rotor item" privileges, to inject arbitrary web script or HTML via the (1) srs, (2) title, or (3) alt image attribute. |
| Cross-site scripting (XSS) vulnerability in the Glossary module 6.x-1.x before 6.x-1.8 for Drupal allows remote attackers to inject arbitrary web script or HTML via unspecified vectors related to "taxonomy information." |
| The Contact Forms module 7.x-1.x before 7.x-1.2 for Drupal does not specify sufficiently restrictive permissions, which allows remote authenticated users with the "access the site-wide contact form" permission to modify the module settings via unspecified vectors. |
| Cross-site request forgery (CSRF) vulnerability in the Take Control module 6.x-2.x before 6.x-2.2 for Drupal allows remote attackers to hijack the authentication of unspecified users for Ajax requests that manipulate files. |
| Open redirect vulnerability in the Janrain Capture module 6.x-1.0 and 7.x-1.0 for Drupal, when synchronizing user data, allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the destination parameter. |
| The Janrain Capture module 6.x-1.0 and 7.x-1.0 for Drupal, when creating a local user account, allows attackers to obtain part of the initial input used to generate passwords, which makes it easier to conduct brute force password guessing attacks. |
| Open redirect vulnerability in the Global Redirect module 6.x-1.x before 6.x-1.4 and 7.x-1.x before 7.x-1.4 for Drupal, when non-clean to clean is enabled, allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the q parameter. |
| The Ubercart Product Keys module 6.x-1.x before 6.x-1.1 for Drupal does not properly check access for product keys, which allows remote attackers to read all unassigned product keys via certain conditions related to the uid. |
| Cross-site request forgery (CSRF) vulnerability in the BrowserID (Mozilla Persona) module 7.x-1.x before 7.x-1.3 for Drupal allows remote attackers to hijack the authentication of arbitrary users for requests that login a user to another web site. |
| SQL injection vulnerability in the conversion form for Events in the Date module 6.x-2.x before 6.x-2.8 for Drupal allows remote authenticated users with the "administer Date Tools" privilege to execute arbitrary SQL commands via unspecified vectors. |
| The finder_import function in the Finder module 6.x-1.x before 6.x-1.26, 7.x-1.x, and 7.x-2.x before 7.x-2.0-alpha8 for Drupal allows remote authenticated users with the administer finder permission to execute arbitrary PHP code via admin/build/finder/import. |
| Multiple cross-site scripting (XSS) vulnerabilities in the Data module 6.x-1.x before 6.x-1.0 and 7.x-1.x before 7.x-1.0-alpha3 for Drupal allow remote authenticated users with the administer data tables permission to inject arbitrary web script or HTML via the title parameter in (1) data.views.inc and (2) data_ui/data_ui.admin.inc. |
| The OpenID module in Drupal 7.x before 7.16 allows remote OpenID servers to read arbitrary files via a crafted DOCTYPE declaration in an XRDS file. |
| jQuery-UI is the official jQuery user interface library. Prior to version 1.13.0, accepting the value of various `*Text` options of the Datepicker widget from untrusted sources may execute untrusted code. The issue is fixed in jQuery UI 1.13.0. The values passed to various `*Text` options are now always treated as pure text, not HTML. A workaround is to not accept the value of the `*Text` options from untrusted sources. |
| jQuery-UI is the official jQuery user interface library. Prior to version 1.13.0, accepting the value of the `altField` option of the Datepicker widget from untrusted sources may execute untrusted code. The issue is fixed in jQuery UI 1.13.0. Any string value passed to the `altField` option is now treated as a CSS selector. A workaround is to not accept the value of the `altField` option from untrusted sources. |
| Drupal core's form API has a vulnerability where certain contributed or custom modules' forms may be vulnerable to improper input validation. This could allow an attacker to inject disallowed values or overwrite data. Affected forms are uncommon, but in certain cases an attacker could alter critical or sensitive data. |
| Under certain circumstances, the Drupal core form API evaluates form element access incorrectly. This may lead to a user being able to alter data they should not have access to. No forms provided by Drupal core are known to be vulnerable. However, forms added through contributed or custom modules or themes may be affected. |
| Drupal core sanitizes filenames with dangerous extensions upon upload (reference: SA-CORE-2020-012) and strips leading and trailing dots from filenames to prevent uploading server configuration files (reference: SA-CORE-2019-010). However, the protections for these two vulnerabilities previously did not work correctly together. As a result, if the site were configured to allow the upload of files with an htaccess extension, these files' filenames would not be properly sanitized. This could allow bypassing the protections provided by Drupal core's default .htaccess files and possible remote code execution on Apache web servers. This issue is mitigated by the fact that it requires a field administrator to explicitly configure a file field to allow htaccess as an extension (a restricted permission), or a contributed module or custom code that overrides allowed file uploads. |
