A Cross-Site Scripting vulnerability exists in Drupal 6.20 with Data 6.x-1.0-alpha14 due to insufficient sanitization of table descriptions, field names, or labels before display.
An access bypass issue was found in Drupal 7.x before version 7.5. If a Drupal site has the ability to attach File upload fields to any entity type in the system or has the ability to point individual File upload fields to the private file directory in comments, and the parent node is denied access, non-privileged users can still download the file attached to the comment if they know or guess its direct URL.
Locale module and dependent contributed modules in Drupal 6.x before 6.16 and 5.x before version 5.22 do not sanitize the display of language codes, native and English language names properly which could allow an attacker to perform a cross-site scripting (XSS) attack. This vulnerability is mitigated by the fact that an attacker must have a role with the 'administer languages' permission.
Drupal 6.x before 6.16 and 5.x before version 5.22 does not properly block users under certain circumstances. A user with an open session that was blocked could maintain their session on the Drupal site despite being blocked.
Drupal 5.x and 6.x before 6.16 uses a user-supplied value in output during site installation which could allow an attacker to craft a URL and perform a cross-site scripting attack.
In PrestaShop 1.7.5.2, the shop_country parameter in the install/index.php installation script/component is affected by Reflected XSS. Exploitation by a malicious actor requires the user to follow the initial stages of the setup (accepting terms and conditions) before executing the malicious link.
In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, validation messages are not escaped, which can lead to XSS when user input is included. This is related to symfony/framework-bundle.
In Symfony before 2.7.51, 2.8.x before 2.8.50, 3.x before 3.4.26, 4.x before 4.1.12, and 4.2.x before 4.2.7, when service ids allow user input, this could allow for SQL Injection and remote code execution. This is related to symfony/dependency-injection.