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.
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.
Solution:
Install the latest version:
If you are using Drupal 9.4, update to Drupal 9.4.3.
If you are using Drupal 9.3, update to Drupal 9.3.19.
Auditing your files directory’s .htaccess to ensure it has not been overwritten or overridden in a subdirectory
If your web server uses Apache httpd with AllowOverride, you should check within your files directories and subdirectories to ensure that any .htaccess files present are intentional. You can search for files named .htaccess by running the following command in the roots of both your public and private files directory:
find ./ -name “.htaccess” -print
Drupal automatically creates .htaccess files like the following in the root of the public files directory:
# Turn off all options we don’t need.
Options -Indexes -ExecCGI -Includes -MultiViews
# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
# Override the handler again if we’re run later in the evaluation list.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>
# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php7.c>
php_flag engine off
</IfModule>
<IfModule mod_php.c>
php_flag engine off
</IfModule>
Check with your system administrator for the correct .htaccess configuration for the given files directory.
Peter Wolanin of the Drupal Security Team xjm of the Drupal Security Team Drew Webber of the Drupal Security Team Alex Bronstein of the Drupal Security Team Greg Knaddison of the Drupal Security Team Jen Lampton, provisional member of the Drupal Security Team Lee Rowlands of the Drupal Security Team Dave Long, provisional member of the Drupal Security Team
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.
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.
Solution:
Install the latest version:
If you are using Drupal 9.4, update to Drupal 9.4.3.
If you are using Drupal 9.3, update to Drupal 9.3.19.
Multiple vulnerabilities have been discovered in Google Chrome, the most severe of which could allow for arbitrary code execution. Google Chrome is a web browser used to access the Internet. Successful exploitation of the most severe of these vulnerabilities could allow for arbitrary code execution in the context of the logged on user. Depending on the privileges associated with the user, an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.
