The Contextual Links module doesn't sufficiently validate the requested contextual links.
This vulnerability is mitigated by the fact that an attacker must have a role with the permission "access contextual links".
In Drupal core, when sending email some variables were not being sanitized for shell arguments in `DefaultMailSystem::mail()`, which could lead to remote code execution.
Drupal core and contributed modules frequently use a "destination" query string parameter in URLs to redirect users to a new destination after completing an action on the current page. Under certain circumstances, malicious users can use this parameter to construct a URL that will trick users into being redirected to a 3rd party website, thereby exposing the users to potential social engineering attacks.
Drupal External URL injection through URL aliases leading to Open Redirect
The path module in Drupal allows users with the 'administer paths' to create pretty URLs for content.
In certain circumstances the user can enter a particular path that triggers an open redirect to a malicious url.
The Comment module allows users to reply to comments. In certain cases, an attacker could make comment reply requests that would trigger a denial of service (DOS).
Sites that do not use the Comment module are not affected.
Drupal contains a vulnerability with improper handling of structural elements. If this vulnerability is exploited, an attacker may be able to cause a denial-of-service (DoS) condition.
In certain scenarios, Drupal's JSON:API module will output error backtraces. With some configurations, this may cause sensitive information to be cached and made available to anonymous users, leading to privilege escalation.
This vulnerability only affects sites with the JSON:API module enabled, and can be mitigated by uninstalling JSON:API.
The core REST and contributed GraphQL modules are not affected.
The file download facility doesn't sufficiently sanitize file paths in certain situations. This may result in users gaining access to private files that they should not have access to. Some sites may require configuration changes following this security release. Review the release notes for your Drupal version if you have issues accessing private files after updating.
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 m
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
Drupal 9.3 implemented a generic entity access API for entity revisions. However, this API was not completely integrated with existing permissions, resulting in some possible access bypass for users who have access to use revisions of content generally, but who do not have access to individual items of node and media content. This vulnerability only affects sites using Drupal's revision system.
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.
Drupal core provides a page that outputs the markup from `phpinfo()` to assist with diagnosing PHP configuration.
If an attacker was able to achieve an XSS exploit against a privileged user, they may be able to use the phpinfo page to access sensitive information that could be used to escalate the attack.
This vulnerability is mitigated by the fact that a successful XSS exploit is required in order to exploit it.
The language module provides a Language switcher block which can be placed to provide links to quickly switch between different languages.
The URL of unpublished translations may be disclosed. When used in conjunction with a module like Pathauto, this may reveal the title of unpublished content.
This advisory is not covered by [Drupal Steward](/steward).
The Media module does not properly check entity access in some circumstances. This may result in users seeing thumbnails of media items they do not have access to, including for private files.
This release was coordinated with [SA-CONTRIB-2023-010](https://www.drupal.org/sa-contrib-2023-010).
This advisory is not covered by [Drupal Steward](/steward).
The Media Library module does not properly check entity access in some circumstances. This may result in users with access to edit content seeing metadata about media items they are not authorized to access.
The vulnerability is mitigated by the fact that the inaccessible media will only be visible to users who can already edit content that includes a media reference field.
This advisory is not covered by [Drupal Steward](/steward).
Twig may load a template outside a configured directory when using the filesystem loader
Twig is a template language for PHP. Versions 1.x prior to 1.44.7, 2.x prior to 2.15.3, and 3.x prior to 3.4.3 encounter an issue when the filesystem loader loads templates for which the name is a user input. It is possible to use the `source` or `include` statement to read arbitrary files from outside the templates' directory when using a namespace like `@somewhere/../some.file`. In such a case, validation is bypassed. Versions 1.44.7, 2.15.3, and 3.4.3 contain a fix for validation of such template names. There are no known workarounds aside from upgrading.