Hírolvasó
Renderkit - Less critical - Access bypass - SA-CONTRIB-2020-026
The renderkit module contains components which can transform the display of field items sent to it.
Some of these components do not respect the '#access' property on the field render element, and thus can make rendered field values visible to visitors who would otherwise not be allowed to see those field values.
This only occurs if all of the following conditions are true:
- Your site has a field where viewing access is restricted on field level, e.g. using the "Field permissions" module.
- The access-restricted field is displayed using the "Field with formatter" entity display from renderkit, in combination with one of the affected field display processor components.
If a site is affected there are 2 steps to fix this issue on a site:
Step 1: Install the latest version of renderkit:- If you use the renderkit module for Drupal 7.x, upgrade to Renderkit 7.x-1.14.
Look for classes that implement FieldDisplayProcessorInterface.
Consider to extend the FieldDisplayProcessorBase class instead of implementing the interface.
Also see the Renderkit project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Drupal core - Less critical - Access bypass - SA-CORE-2020-006
JSON:API PATCH requests may bypass validation for certain fields.
By default, JSON:API works in a read-only mode which makes it impossible to exploit the vulnerability. Only sites that have the read_only set to FALSE under jsonapi.settings config are vulnerable.
Solution:Install the latest version:
- If you are using Drupal 8.8.x, upgrade to Drupal 8.8.8.
- If you are using Drupal 8.9.x, upgrade to Drupal 8.9.1.
- If you are using Drupal 9.0.x, upgrade to Drupal 9.0.1.
Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.8.
Reported By: Fixed By:- Sergii Bondarenko
- Wim Leers
- Jess of the Drupal Security Team
- Lee Rowlands of the Drupal Security Team
Drupal core - Critical - Arbitrary PHP code execution - SA-CORE-2020-005
Drupal 8 and 9 have a remote code execution vulnerability under certain circumstances.
An attacker could trick an administrator into visiting a malicious site that could result in creating a carefully named directory on the file system. With this directory in place, an attacker could attempt to brute force a remote code execution vulnerability.
Windows servers are most likely to be affected.
Solution:Install the latest version:
- If you are using Drupal 8.8.x, upgrade to Drupal 8.8.8.
- If you are using Drupal 8.9.x, upgrade to Drupal 8.9.1.
- If you are using Drupal 9.0.x, upgrade to Drupal 9.0.1.
Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.8.
Reported By: Fixed By:- Jess of the Drupal Security Team
- Samuel Mortenson of the Drupal Security Team
- Peter Wolanin of the Drupal Security Team
- Lorenzo G
- Lee Rowlands of the Drupal Security Team
- Greg Knaddison of the Drupal Security Team
- Cash Williams of the Drupal Security Team
- Heine of the Drupal Security Team
- Drew Webber of the Drupal Security Team
- Alex Pott of the Drupal Security Team
- Gábor Hojtsy
Drupal core - Critical - Cross Site Request Forgery - SA-CORE-2020-004
The Drupal core Form API does not properly handle certain form input from cross-site requests, which can lead to other vulnerabilities.
Solution:- If you are using Drupal 7.x, upgrade to Drupal 7.72.
- If you are using Drupal 8.8.x, upgrade to Drupal 8.8.8.
- If you are using Drupal 8.9.x, upgrade to Drupal 8.9.1.
- If you are using Drupal 9.0.x, upgrade to Drupal 9.0.1.
Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.8.
Reported By:- Samuel Mortenson of the Drupal Security Team
- Dor Tumarkin
- Greg Knaddison of the Drupal Security Team
- Samuel Mortenson of the Drupal Security Team
- Jess of the Drupal Security Team
- Lee Rowlands of the Drupal Security Team
- Angie Byron of the Drupal Security Team
- Peter Wolanin of the Drupal Security Team
- Daniel Wehner
- Dor Tumarkin
- Drew Webber of the Drupal Security Team
- Alex Pott of the Drupal Security Team
- David Snopek of the Drupal Security Team
- Brandon Bergren
Internationalization - Moderately critical - Cross site scripting - SA-CONTRIB-2020-025
The Internationalization (i18n) module is a collection of modules to extend Drupal core multilingual capabilities and allows to build real life multilingual sites.
A value in the term translation module is displayed without being escaped leading to a Cross Site Scripting (XSS) vulnerability.
This vulnerability is mitigated by the fact that an attacker must have a role with the permission "Edit terms in " on a taxonomy vocabulary with i18n term translation enabled and the victim uses the i18n term translation page.
Solution:Install the latest version:
- If you use the Internationalization (i18n) module for Drupal 7.x, upgrade to i18n 7.x-1.27
Also see the Internationalization project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Open ReadSpeaker - Moderately critical - Cross site scripting - SA-CONTRIB-2020-024
This module enables you to add a configured ReadSpeaker button for text-to-speech for your site visitors.
The module doesn't sufficiently sanitize block configuration causing a Cross Site Scripting (XSS) vulnerability.
This vulnerability is mitigated by the fact that an attacker must have a role with the permission "administer blocks".
Solution:Install the latest version:
- If you use the Open ReadSpeaker module for Drupal 8.x, upgrade to Open ReadSpeaker 8.x-1.5
Also see the Open ReadSpeaker project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
YubiKey - Less critical - Access bypass - SA-CONTRIB-2020-023
This module enables you to use a Yubikey device to protect your Drupal user account. YubiKey is a secure method for logging into many websites using a cryptographically secure USB token.
The module doesn't sufficiently implement login flood control when the module is configured for YubiKey OTP only. This allows an attacker to attempt many YubiKey OTP codes. However, a brute force attack on this code is not practical in most situations given the length and randomness of the OTP codes.
Solution:Install the latest version:
- If you use the Yubikey module for Drupal 7.x, upgrade to Yubikey 7.x-2.3
Also see the YubiKey project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Services - Moderately critical - Access bypass - SA-CONTRIB-2020-022
This module provides a standardized solution for building API's so that external clients can communicate with Drupal.
The module's taxonomy term index resource doesn't take into consideration certain access control tags provided (but unused) by core, that certain contrib modules depend on.
This vulnerability is mitigated by the fact your site must have the taxonomy term index resource enabled, your site must have a contributed module enabled which utilizes taxonomy term access control, and an attacker must know your api endpoint's path.
Solution:Install the latest version:
- If you use the Services module for Drupal 7.x, upgrade to Services 7.x-3.26
Also see the Services project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Password Reset Landing Page (PRLP) - Highly critical - Access bypass - SA-CONTRIB-2020-021
This module enables you to force a password update when using password reset link.
The module doesn't sufficiently validate the login URL allowing a malicious user to use a specially crafted URL to log in as another user.
Install the latest version:
- If you use the PRLP module for Drupal 8.x, upgrade to PRLP 8.x-1.5
Also see the Password Reset Landing Page (PRLP) project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Drupal Commerce - Moderately critical - Access bypass - SA-CONTRIB-2020-020
Drupal Commerce is used to build eCommerce websites and applications. It's possible to configure commerce to permit orders by anonymous users. In this configuration, customers who do not choose to create an account upon checkout completion remain anonymous, and the resulting orders are never assigned an owner.
When anonymous users are granted the "View own orders" permission, they are able to see any such anonymous order via direct navigation to its view page. The module does not include extra access control necessary to ensure anonymous users are only able to view their own previously placed orders.
This vulnerability is mitigated by the fact that a site must be configured to permit anonymous checkout and an attacker must be an anonymous user with the permission "View own orders".
Solution:Install the latest version:
- If you use Commerce for Drupal 8.x upgrade to Commerce 2.18
Also see the Drupal Commerce project page.
Reported By: Fixed By:- Alex Pott of the Drupal Security Team
- Matt Glaman
- Joe Kersey
- Greg Knaddison of the Drupal Security Team
Drupal core - Moderately critical - Open Redirect - SA-CORE-2020-003
Drupal 7 has an Open Redirect vulnerability. For example, a user could be tricked into visiting a specially crafted link which would redirect them to an arbitrary external URL.
The vulnerability is caused by insufficient validation of the destination query parameter in the drupal_goto() function.
Other versions of Drupal core are not vulnerable.
Solution:Install the latest version:
- If you use Drupal 7.x upgrade to Drupal 7.70
- Drew Webber of the Drupal Security Team
- Fabian Franz
- David Snopek of the Drupal Security Team
- vortfu
Drupal core - Moderately critical - Cross Site Scripting - SA-CORE-2020-002
The jQuery project released version 3.5.0, and as part of that, disclosed two security vulnerabilities that affect all prior versions. As mentioned in the jQuery blog, both are
[...] security issues in jQuery’s DOM manipulation methods, as in .html(), .append(), and the others. Security advisories for both of these issues have been published on GitHub.
Those advisories are:
These vulnerabilities may be exploitable on some Drupal sites. This Drupal security release backports the fixes to the relevant jQuery functions, without making any other changes to the jQuery version that is included in Drupal core or running on the site via some other module such as jQuery Update. It is not necessary to update jquery_update on Drupal 7 sites that have the module installed.
Backwards-compatibility code has also been added to minimize regressions to Drupal sites that might rely on jQuery's prior behavior. With jQuery 3.5, incorrect self-closing HTML tags in JavaScript for elements where end tags are normally required will encounter a change in what jQuery returns or inserts. To minimize that disruption in 8.8.x and earlier, this security release retains jQuery's prior behavior for most safe tags. There may still be regressions for edge cases, including invalidly self-closed custom elements on Internet Explorer.
(Note: the backwards compatibility layer will not be included in the upcoming Drupal 8.9 and 9.0 releases, so Drupal 8 and 9 modules, themes, and sites should correct tags in JavaScript to properly use closing tags.)
If you find a regression caused by the jQuery changes, please report it in Drupal core's issue queue (or that of the relevant contrib project). However, if you believe you have found a security issue, please report it privately to the Drupal Security Team.
Solution:Install the latest version:
- If you are using Drupal 8.8, upgrade to Drupal 8.8.6.
- If you are using Drupal 8.7, upgrade to Drupal 8.7.14.
- If you are using Drupal 7, upgrade to Drupal 7.70.
Versions of Drupal 8 prior to 8.7 are end-of-life and do not receive security coverage. Sites on 8.6 or earlier should update to 8.7.14.
The pre-release Drupal versions (8.9 and 9.0) have been updated jQuery to version 3.5.1 as of 8.9.0-beta3 and 9.0.0-beta3.
Reported By:- Drew Webber of the Drupal Security Team
- Emerson Jair Reis Oliveira da Silva
- Drew Webber of the Drupal Security Team
- Sally Young
- cilefen of the Drupal Security Team
- Jess of the Drupal Security Team
- Emerson Jair Reis Oliveira da Silva
- Lee Rowlands of the Drupal Security Team
- Alex Bronstein of the Drupal Security Team
- Ben Mullins
- Lauri Eskola
- Peter Weber
- Samuel Mortenson of the Drupal Security Team
reCAPTCHA v3 - Critical - Access bypass - SA-CONTRIB-2020-019
The reCaptcha v3 module enables you to protect your forms using the Google reCaptcha V3.
If the reCaptcha v3 challenge succeeds, all the other form validations are bypassed. This makes it possible for attackers to submit invalid or incomplete forms.
This vulnerability only affects forms that are protected by reCaptcha v3 and have server side validation steps (e.g required field or custom validation functions).
Solution:Install the latest version:
- If you use the reCAPTCHA v3 module for Drupal 8.x, upgrade to reCAPTCHA v3 8.x-1.2
Also see the reCAPTCHA v3 project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Webform - Critical - Access bypass - SA-CONTRIB-2020-018
This webform module enables you to build a 'Term checkboxes' element.
The module doesn't sufficiently check term 'view' access when rendering 'Term checkboxes' elements. Unpublished terms will always appear in the 'Term checkboxes' element.
Solution:Install the latest version:
- If you use the Webform module for Drupal 8.x, upgrade to Webform 8.x-5.12
Also see the Webform project page.
Reported By: Fixed By:- Joseph Zhao
- Lee Rowlands of the Drupal Security Team
- Jacob Rockowitz
- Greg Knaddison of the Drupal Security Team
Webform - Moderately critical - Access bypass - SA-CONTRIB-2020-017
This module enables you to build forms and surveys in Drupal.
The Webform Node sub-module allows these forms to be associated with a Drupal node. The Webform Node module does not implement access checking in the same manner as other nodes and entities. As such, writers of custom modules which implement webform_node, node, or entity access checks may not achieve the intended access results for Webform Node content.
There is no known exploit of this vulnerability and the vulnerability only exists on sites with custom code and a node access module in use.
Solution:Install the latest version:
- If you use the Webform module for Drupal 8, upgrade to Webform 8.x-5.11
Also see the Webform project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Webform - Critical - Access bypass - SA-CONTRIB-2020-016
This webform module enables you to build 'Term select' and 'Term checkboxes' elements.
The module doesn't sufficiently check term 'view' access when rendering the 'Term select' and 'Term checkboxes' elements. Unpublished terms will always appear in the 'Term select' and 'Term checkboxes' elements.
Solution:Install the latest version:
- If you use the Webform module for Drupal 8, upgrade to Webform 8.x-5.11
Also see the Webform project page.
Reported By:- James Gilliland of the Drupal Security Team
- Greg Knaddison of the Drupal Security Team
Webform - Moderately critical - Cross site scripting - SA-CONTRIB-2020-015
This module enables you to build forms and surveys in Drupal.
The module doesn't sufficiently sanitize Webform labels nor visibility conditions under the scenario of placing a block. When a webform block is placed and visible on a website any JavaScript code contained within the webform's label was executed.
This vulnerability is mitigated by the fact that an attacker must have a role with the permission "Edit own webform" (or "Edit any webform").
Solution:Install the latest version:
- If you use the Webform module for Drupal 8, upgrade to Webform 8.x-5.11
Also see the Webform project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Webform - Moderately critical - Cross site scripting - SA-CONTRIB-2020-014
This module enables you to build forms and surveys in Drupal.
The module doesn't sufficiently filter user input under in the scenario when a webform is edited, namely the message related to character min/max counter does not undergo sufficient filtering and thus allows execution of JavaScript code through it.
This vulnerability is mitigated by the fact that an attacker must have a role with the permission "Edit own webform" (or "Edit any webform").
Solution:Install the latest version:
- If you use the Webform module for Drupal 8, upgrade to Webform 8.x-5.11
Also see the Webform project page.
Reported By: Fixed By:- Krzysztof Domański
- Lee Rowlands of the Drupal Security Team
- Jacob Rockowitz
- bucefal91
- Greg Knaddison of the Drupal Security Team
Webform - Moderately critical - Cross site scripting - SA-CONTRIB-2020-013
The Webform module allows site builders to create forms.
The module doesn't sufficiently prevent malicious code from being render via an options elements (i.e select menu, checkboxes, radios, etc...) under the scenario where the site builder allows the raw option value to be displayed.
This vulnerability is mitigated by the fact that site builder must be allowed to build webform and select raw as the options element's submission display.
Solution:Install the latest version:
- If you use the Webform module for Drupal 8, upgrade to Webform 8.x-5.11
Also see the Webform project page.
Reported By: Fixed By: Coordinated By:- Greg Knaddison of the Drupal Security Team
Webform - Moderately critical - Access bypass - SA-CONTRIB-2020-012
This module enables you to build forms and surveys in Drupal.
The module doesn't sufficiently validate data submitted into Webform Signature element during webform submission creation. This allows a malicious user to generate and extract HMAC hashes for arbitrary data. Such HMAC hashes are used across multiple spots in Drupal 8 core and contrib modules.
An extracted HMAC hash could be used to view restricted site content or log in as another user in certain situations.
This vulnerability is mitigated by the fact that an attacker must be able to create a webform submission with "Signature" element and then be able to view the submission.
For Drupal instances that have "Signature" webform element available to users with low trust, it is advised to change the value of the hash salt within settings.php file to a new random value. Below we reference the specific extract from settings.php that is advised for change in such Drupal instances:
/** * Salt for one-time login links, cancel links, form tokens, etc. * * This variable will be set to a random value by the installer. All one-time * login links will be invalidated if the value is changed. Note that if your * site is deployed on a cluster of web servers, you must ensure that this * variable has the same value on each server. * * For enhanced security, you may set this variable to the contents of a file * outside your document root; you should also ensure that this file is not * stored with backups of your database. * * Example: * @code * $settings['hash_salt'] = file_get_contents('/home/example/salt.txt'); * @endcode */ $settings['hash_salt'] = 'new-value-here'; Solution:Install the latest version:
- If you use the Webform module for Drupal 8, upgrade to Webform 8.x-5.11
Also see the Webform project page.
Reported By:- Heine of the Drupal Security Team
- Greg Knaddison of the Drupal Security Team
