Drupal core 7.x versions before 7.57 has an external link injection vulnerability when the language switcher block is used. A similar vulnerability exists in various custom and contributed modules. This vulnerability could allow an attacker to trick users into unwillingly navigating to an external site.

Insufficient policy enforcement in service workers in Google Chrome prior to 74.0.3729.108 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page.

An issue was discovered in Symfony 2.7.x before 2.7.38, 2.8.x before 2.8.31, 3.2.x before 3.2.14, and 3.3.x before 3.3.13. DefaultAuthenticationSuccessHandler or DefaultAuthenticationFailureHandler takes the content of the _target_path parameter and generates a redirect response, but no check is performed on the path, which could be an absolute URL to an external domain. This Open redirect vulnerability can be exploited for example to mount effective phishing attacks.

mod_auth_openidc is an authentication/authorization module for the Apache 2.x HTTP server that functions as an OpenID Connect Relying Party, authenticating users against an OpenID Connect Provider. In versions prior to 2.4.9.4, the 3rd-party init SSO functionality of mod_auth_openidc was reported to be vulnerable to an open redirect attack by supplying a crafted URL in the `target_link_uri` parameter. A patch in version 2.4.9.4 made it so that the `OIDCRedirectURLsAllowed` setting must be applied to the `target_link_uri` parameter. There are no known workarounds aside from upgrading to a patched version.

Insufficient validation of untrusted input in Intents in Google Chrome on Android prior to 95.0.4638.69 allowed a remote attacker to arbitrarily browser to a malicious URL via a crafted HTML page.

Drupal versions 5.x and 6.x has open redirection

An open redirect was discovered in Symfony 2.7.x before 2.7.50, 2.8.x before 2.8.49, 3.x before 3.4.20, 4.0.x before 4.0.15, 4.1.x before 4.1.9 and 4.2.x before 4.2.1. By using backslashes in the `_failure_path` input field of login forms, an attacker can work around the redirection target restrictions and effectively redirect the user to any domain after login.

A flaw was found in mod_auth_openidc before version 2.4.1. An open redirect issue exists in URLs with a slash and backslash at the beginning.

MediaWiki through 1.33.1 allows attackers to bypass the Title_blacklist protection mechanism by starting with an arbitrary title, establishing a non-resolvable redirect for the associated page, and using redirect=1 in the action API when editing that page.

Mediawiki before 1.28.1 / 1.27.2 / 1.23.16 has a flaw where Special:UserLogin?returnto=interwiki:foo will redirect to external sites.

SPIP before 3.1.11 and 3.2 before 3.2.5 mishandles redirect URLs in ecrire/inc/headers.php with a %0D, %0A, or %20 character.

Mediawiki before 1.28.1 / 1.27.2 / 1.23.16 contains a flaw where Special:Search allows redirects to any interwiki link.

An issue was discovered in OpenStack Horizon before 15.3.2, 16.x before 16.2.1, 17.x and 18.x before 18.3.3, 18.4.x, and 18.5.x. There is a lack of validation of the "next" parameter, which would allow someone to supply a malicious URL in Horizon that can cause an automatic redirect to the provided malicious URL.

django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect.

Zabbix before 2.2.21rc1, 3.x before 3.0.13rc1, 3.1.x and 3.2.x before 3.2.10rc1, and 3.3.x and 3.4.x before 3.4.4rc1 allows open redirect via the request parameter.

The security handlers in the Security component in Symfony in 2.7.x before 2.7.48, 2.8.x before 2.8.41, 3.3.x before 3.3.17, 3.4.x before 3.4.11, and 4.0.x before 4.0.11 have an Open redirect vulnerability when security.http_utils is inlined by a container. NOTE: this issue exists because of an incomplete fix for CVE-2017-16652.

Before WordPress 4.9.5, the URL validator assumed URLs with the hostname localhost were on the same host as the WordPress server.

sympa version 6.2.16 and later contains a CWE-601: URL Redirection to Untrusted Site ('Open Redirect') vulnerability in The "referer" parameter of the wwsympa.fcgi login action. that can result in Open redirection and reflected XSS via data URIs. This attack appear to be exploitable via Victim's browser must follow a URL supplied by the attacker. This vulnerability appears to have been fixed in none available.

The CGIHandler class in Python before 2.7.12 does not protect against the HTTP_PROXY variable name clash in a CGI script, which could allow a remote attacker to redirect HTTP requests.

yaws before 2.0.4 does not attempt to address RFC 3875 section 4.1.18 namespace conflicts and therefore does not protect CGI applications from the presence of untrusted client data in the HTTP_PROXY environment variable, which might allow remote attackers to redirect a CGI application's outbound HTTP traffic to an arbitrary proxy server via a crafted Proxy header in an HTTP request, aka an "httpoxy" issue.

Open redirect vulnerability in the Overlay module in Drupal 7.x before 7.41, the jQuery Update module 7.x-2.x before 7.x-2.7 for Drupal, and the LABjs module 7.x-1.x before 7.x-1.8 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via unspecified vectors. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-3233.

Jupyter Notebook before version 6.1.5 has an Open redirect vulnerability. A maliciously crafted link to a notebook server could redirect the browser to a different website. All notebook servers are technically affected, however, these maliciously crafted links can only be reasonably made for known notebook server hosts. A link to your notebook server may appear safe, but ultimately redirect to a spoofed server on the public internet. The issue is patched in version 6.1.5.

In WordPress before 5.2.3, validation and sanitization of a URL in wp_validate_redirect in wp-includes/pluggable.php could lead to an open redirect if a provided URL path does not start with a forward slash.

Before WordPress 4.9.5, the redirection URL for the login page was not validated or sanitized if forced to use HTTPS.

In Apache HTTP Server 2.4.0 to 2.4.41, redirects configured with mod_rewrite that were intended to be self-referential might be fooled by encoded newlines and redirect instead to an an unexpected URL within the request URL.

By exploiting an Open Redirect vulnerability on a website, an attacker could have spoofed the site displayed in the download file dialog to show the original site (the one suffering from the open redirect) rather than the site the file was actually downloaded from. This vulnerability affects Firefox < 81, Thunderbird < 78.3, and Firefox ESR < 78.3.

Open Redirect vulnerability in Drupal Core allows a user to be tricked into visiting a specially crafted link which would redirect them to an arbitrary external URL. This issue affects: Drupal Drupal Core 7 version 7.70 and prior versions.

node-fetch is vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

Open redirect vulnerability in URL-related API functions in Drupal 6.x before 6.35 and 7.x before 7.35 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via vectors involving the "//" initial sequence.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. In aiohttp before version 3.7.4 there is an open redirect vulnerability. A maliciously crafted link to an aiohttp-based web-server could redirect the browser to a different website. It is caused by a bug in the `aiohttp.web_middlewares.normalize_path_middleware` middleware. This security problem has been fixed in 3.7.4. Upgrade your dependency using pip as follows "pip install aiohttp >= 3.7.4". If upgrading is not an option for you, a workaround can be to avoid using `aiohttp.web_middlewares.normalize_path_middleware` in your applications.

In WordPress before 4.7.5, a cross-site scripting (XSS) vulnerability exists when attempting to upload very large files, because the error message does not properly restrict presentation of the filename.

MediaWiki before 1.27.4, 1.28.x before 1.28.3, and 1.29.x before 1.29.2 has XSS when the $wgShowExceptionDetails setting is false and the browser sends non-standard URL escaping.

A jQuery cross site scripting vulnerability is present when making Ajax requests to untrusted domains. This vulnerability is mitigated by the fact that it requires contributed or custom modules in order to exploit. For Drupal 8, this vulnerability was already fixed in Drupal 8.4.0 in the Drupal core upgrade to jQuery 3. For Drupal 7, it is fixed in the current release (Drupal 7.57) for jQuery 1.4.4 (the version that ships with Drupal 7 core) as well as for other newer versions of jQuery that might be used on the site, for example using the jQuery Update module.

In Drupal 8 prior to 8.3.7; When using the REST API, users without the correct permission can post comments via REST that are approved even if the user does not have permission to post approved comments. This issue only affects sites that have the RESTful Web Services (rest) module enabled, the comment entity REST resource enabled, and where an attacker can access a user account on the site with permissions to post comments, or where anonymous users can post comments.

Drupal 8.4.x versions before 8.4.5 and Drupal 7.x versions before 7.57 has a Drupal.checkPlain() JavaScript function which is used to escape potentially dangerous text before outputting it to HTML (as JavaScript output does not typically go through Twig autoescaping). This function does not correctly handle all methods of injecting malicious HTML, leading to a cross-site scripting vulnerability under certain circumstances. The PHP functions which Drupal provides for HTML escaping are not affected.

Incorrect application of sandboxing in Blink in Google Chrome prior to 62.0.3202.62 allowed a remote attacker to inject arbitrary scripts or HTML (UXSS) via a crafted MHTML page.

Cross-site scripting (XSS) vulnerability in the nav_path function in lib/viewvc.py in ViewVC before 1.0.14 and 1.1.x before 1.1.26 allows remote attackers to inject arbitrary web script or HTML via the nav_data name.

Go before 1.16.12 and 1.17.x before 1.17.5 on UNIX allows write operations to an unintended file or unintended network connection as a consequence of erroneous closing of file descriptor 0 after file-descriptor exhaustion.

Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Networking). Supported versions that are affected are Java SE: 7u221, 8u212, 11.0.3 and 12.0.1; Java SE Embedded: 8u211. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.0 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).

The consentAdmin module in SimpleSAMLphp through 1.14.15 is vulnerable to a Cross-Site Scripting attack, allowing an attacker to craft links that could execute arbitrary JavaScript code on the victim's web browser.

Incorrect handling of negative zero in V8 in Google Chrome prior to 72.0.3626.81 allowed a remote attacker to perform arbitrary read/write via a crafted HTML page.

Google Chrome before 28.0.1500.71 does not properly determine the circumstances in which a renderer process can be considered a trusted process for sign-in and subsequent sync operations, which makes it easier for remote attackers to conduct phishing attacks via a crafted web site.

In Redmine before 3.2.8, 3.3.x before 3.3.5, and 3.4.x before 3.4.3, XSS exists in app/helpers/application_helper.rb via a multi-value field with a crafted value that is mishandled during rendering of issue history.

Insufficient policy enforcement in Omnibox in Google Chrome prior to 63.0.3239.84 allowed a socially engineered user to XSS themselves by dragging and dropping a javascript: URL into the URL bar.

In Redmine before 3.2.8, 3.3.x before 3.3.5, and 3.4.x before 3.4.3, XSS exists in app/helpers/queries_helper.rb via a multi-value field with a crafted value that is mishandled during rendering of an issue list.