| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Cross-site scripting (XSS) vulnerability in the Imagemenu module 6.x-1.x before 6.x-1.4 for Drupal allows remote authenticated users with the "administer imagemenu" permission to inject arbitrary web script or HTML via an image file name. |
| Cross-site scripting (XSS) vulnerability in the Spambot module 6.x-3.x before 6.x-3.2 and 7.x-1.x before 7.x-1.1 for Drupal allows certain remote attackers to inject arbitrary web script or HTML via a stopforumspam.com API response, which is logged by the watchdog. |
| Cross-site scripting (XSS) vulnerability in the PRH Search module 7.x-1.x before 7.x-1.1 for Drupal allows remote attackers from certain sources to inject arbitrary web script or HTML via unspecified vectors. |
| Cross-site scripting (XSS) vulnerability in the Exposed Filter Data module 6.x-1.x before 6.x-1.2 for Drupal allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. |
| Cross-site scripting (XSS) vulnerability in the EventCalendar module for Drupal 7.14 allows remote attackers to inject arbitrary web script or HTML via the year parameter to eventcalander/. NOTE: this issue has been disputed by the Drupal Security Team; it may be site-specific. If so, then this CVE will be REJECTed in the future |
| Cross-site scripting (XSS) vulnerability in the Fonecta verify module 7.x-1.x before 7.x-1.6 for Drupal allows remote attackers from certain sources to inject arbitrary web script or HTML via unspecified vectors. |
| Cross-site scripting (XSS) vulnerability in the Apache Solr Autocomplete module 6.x-1.x before 6.x-1.4 and 7.x-1.x before 7.x-1.3 for Drupal allows remote attackers to inject arbitrary web script or HTML via vectors involving autocomplete results. |
| Cross-site scripting (XSS) vulnerability in the phptemplate_preprocess_node function in template.php in the Inf08 theme 6.x-1.x before 6.x-1.10 for Drupal allows remote authenticated users with the "administer taxonomy" permission to inject arbitrary web script or HTML via a taxonomy vocabulary name. |
| Cross-site scripting (XSS) vulnerability in the stickynote module before 7.x-1.1 for Drupal allows remote authenticated users with edit stickynotes privileges to inject arbitrary web script or HTML via unspecified vecotrs. |
| 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. |
| The Janrain Engage (formerly RPX) module 6.x-1.3 for Drupal does not validate the file for a profile image, which allows remote authenticated users to conduct cross-site scripting (XSS) attacks and possibly execute arbitrary PHP code by causing a crafted avatar to be downloaded from an external login provider site. |
| Cross-site scripting (XSS) vulnerability in the CCK TableField module 6.x before 6.x-1.2 for Drupal allows remote authenticated users, with certain node creation or editing privileges, to inject arbitrary web script or HTML via table headers. |
| SQL injection vulnerability in the Multisite Search module 6.x-2.2 for Drupal allows remote authenticated users with certain permissions to execute arbitrary SQL commands via the Site table prefix field. |
| 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. |
| The Media oEmbed iframe route does not properly validate the iframe domain setting, which allows embeds to be displayed in the context of the primary domain. Under certain circumstances, this could lead to cross-site scripting, leaked cookies, or other vulnerabilities. |
| In some situations, the Image module does not correctly check access to image files not stored in the standard public files directory when generating derivative images using the image styles system. Access to a non-public file is checked only if it is stored in the "private" file system. However, some contributed modules provide additional file systems, or schemes, which may lead to this vulnerability. This vulnerability is mitigated by the fact that it only applies when the site sets (Drupal 9) $config['image.settings']['allow_insecure_derivatives'] or (Drupal 7) $conf['image_allow_insecure_derivatives'] to TRUE. The recommended and default setting is FALSE, and Drupal core does not provide a way to change that in the admin UI. Some sites may require configuration changes following this security release. Review the release notes for your Drupal version if you have issues accessing files or image styles after updating. |
