Express OpenID Connect is an Express JS middleware implementing sign on for Express web apps using OpenID Connect. Users of the `requiresAuth` middleware, either directly or through the default `authRequired` option, are vulnerable to an Open Redirect when the middleware is applied to a catch all route. If all routes under `example.com` are protected with the `requiresAuth` middleware, a visit to `http://example.com//google.com` will be redirected to `google.com` after login because the original url reported by the Express framework is not properly sanitized. This vulnerability affects versions prior to 2.7.2. Users are advised to upgrade. There are no known workarounds.
auth0-lock is Auth0's signin solution. Versions of nauth0-lock before and including `11.30.0` are vulnerable to reflected XSS. An attacker can execute arbitrary code when the library's `flashMessage` feature is utilized and user input or data from URL parameters is incorporated into the `flashMessage` or the library's `languageDictionary` feature is utilized and user input or data from URL parameters is incorporated into the `languageDictionary`. The vulnerability is patched in version 11.30.1.
The Auth0 Next.js SDK is a library for implementing user authentication in Next.js applications. Versions before and including `1.4.1` are vulnerable to reflected XSS. An attacker can execute arbitrary code by providing an XSS payload in the `error` query parameter which is then processed by the callback handler as an error message. You are affected by this vulnerability if you are using `@auth0/nextjs-auth0` version `1.4.1` or lower **unless** you are using custom error handling that does not return the error message in an HTML response. Upgrade to version `1.4.1` to resolve. The fix adds basic HTML escaping to the error message and it should not impact your users.
A stored cross-site scripting (XSS) vulnerability exists in the Auth0 plugin before 4.0.0 for WordPress via the settings page.
The Login by Auth0 plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the ‘wle’ parameter in all versions up to, and including, 4.6.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.
omniauth-auth0 (rubygems) versions >= 2.3.0 and < 2.4.1 improperly validate the JWT token signature when using the `jwt_validator.verify` method. Improper validation of the JWT token signature can allow an attacker to bypass authentication and authorization. You are affected by this vulnerability if all of the following conditions apply: 1. You are using `omniauth-auth0`. 2. You are using `JWTValidator.verify` method directly OR you are not authenticating using the SDK’s default Authorization Code Flow. The issue is patched in version 2.4.1.
The Auth0 wp-auth0 plugin 3.11.x before 3.11.3 for WordPress allows XSS via a wle parameter associated with wp-login.php.
Auth0 Lock before 11.21.0 allows XSS when additionalSignUpFields is used with an untrusted placeholder.
Auth0 is an authentication broker that supports both social and enterprise identity providers, including Active Directory, LDAP, Google Apps, and Salesforce. In versions before `11.33.0`, when the “additional signup fields” feature [is configured](https://github.com/auth0/lock#additional-sign-up-fields), a malicious actor can inject invalidated HTML code into these additional fields, which is then stored in the service `user_metdata` payload (using the `name` property). Verification emails, when applicable, are generated using this metadata. It is therefor possible for an actor to craft a malicious link by injecting HTML, which is then rendered as the recipient's name within the delivered email template. You are impacted by this vulnerability if you are using `auth0-lock` version `11.32.2` or lower and are using the “additional signup fields” feature in your application. Upgrade to version `11.33.0`.
The Login by Auth0 plugin before 4.0.0 for WordPress allows stored XSS on multiple pages, a different issue than CVE-2020-5392.
showdoc is vulnerable to URL Redirection to Untrusted Site
An open redirect vulnerability in the sanitize_url() parameter of CouchCMS v2.3 allows attackers to redirect a victim user to an arbitrary web site via a crafted URL.
Open Redirect vulnerability in Hitachi Device Manager before 8.5.2-01 and Hitachi Tuning Manager before 8.5.2-00 allows remote attackers to redirect authenticated users to arbitrary web sites.
showdoc is vulnerable to URL Redirection to Untrusted Site
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.
The Jupyter Server provides the backend (i.e. the core services, APIs, and REST endpoints) for Jupyter web applications like Jupyter notebook, JupyterLab, and Voila. In Jupyter Server before version 1.1.1, an open redirect vulnerability could cause the jupyter server to redirect the browser to a different malicious website. All jupyter servers running without a base_url prefix are technically affected, however, these maliciously crafted links can only be reasonably made for known jupyter server hosts. A link to your jupyter server may *appear* safe, but ultimately redirect to a spoofed server on the public internet. This same vulnerability was patched in upstream notebook v5.7.8. This is fixed in jupyter_server 1.1.1. If upgrade is not available, a workaround can be to run your server on a url prefix: "jupyter server --ServerApp.base_url=/jupyter/".
EyouCMS 1.5.4 is vulnerable to Open Redirect. An attacker can redirect a user to a malicious url via the Logout function.
An open redirect vulnerability has been reported to affect QNAP device running QcalAgent. If exploited, this vulnerability allows attackers to redirect users to an untrusted page that contains malware. We have already fixed this vulnerability in the following versions of QcalAgent: QcalAgent 1.1.7 and later
An Open Redirect vulnerability exists prior to version 1.52.117, where the built-in QR scanner in Brave Browser Android navigated to scanned URLs automatically without showing the URL first. Now the user must manually navigate to the URL.
The Nested Pages WordPress plugin <= 3.1.15 was vulnerable to an Open Redirect via the `page` POST parameter in the `npBulkActions`, `npBulkEdit`, `npListingSort`, and `npCategoryFilter` `admin_post` actions.
URL Redirection to Untrusted Site ('Open Redirect') vulnerability in CRM Perks Integration for HubSpot and Contact Form 7, WPForms, Elementor, Ninja Forms.This issue affects Integration for HubSpot and Contact Form 7, WPForms, Elementor, Ninja Forms: from n/a through 1.2.8.
Open Redirect vulnerability in Hitachi Device Manager before 8.5.2-01 allows remote attackers to redirect users to arbitrary web sites.
textview_uri_security_check in textview.c in Claws Mail before 3.18.0, and Sylpheed through 3.7.0, does not have sufficient link checks before accepting a click.
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.
Open Redirect vulnerability in Micro Focus Network Automation, affecting Network Automation versions 10.4x, 10.5x, 2018.05, 2018.11, 2019.05, 2020.02, 2020.08, 2020.11, 2021.05. The vulnerability could allow redirect users to malicious websites after authentication.
An open redirect vulnerability exists in Nagios XI before version 5.8.5 that could lead to spoofing. To exploit the vulnerability, an attacker could send a link that has a specially crafted URL and convince the user to click the link.
Next.js is an open source website development framework to be used with the React library. In affected versions specially encoded paths could be used when pages/_error.js was statically generated allowing an open redirect to occur to an external site. In general, this redirect does not directly harm users although can allow for phishing attacks by redirecting to an attacker's domain from a trusted domain. We recommend everyone to upgrade regardless of whether you can reproduce the issue or not. The issue has been patched in release 11.1.0.
openwhyd is vulnerable to URL Redirection to Untrusted Site
URL redirection in Login page in HCL BigFix WebUI allows malicious user to redirect the client browser to an external site via redirect URL response header.
URI.js is vulnerable to URL Redirection to Untrusted Site
The specific function of the Orca HCM digital learning platform does not filter input parameters properly, which causing the URL can be redirected to any website. Remote attackers can use the vulnerability to execute phishing attacks.
A vulnerability in the web-based management interface of Cisco Orbital could allow an unauthenticated, remote attacker to redirect users to a malicious webpage. This vulnerability is due to improper validation of URL paths in the web-based management interface. An attacker could exploit this vulnerability by persuading a user to click a crafted URL. A successful exploit could allow the attacker to redirect a user to a malicious website. This vulnerability, known as an open redirect attack, is used in phishing attacks to persuade users to visit malicious sites.
Jamf Pro before 10.30.1 allows for an unvalidated URL redirect vulnerability affecting Jamf Pro customers who host their environments on-premises. An attacker may craft a URL that appears to be for a customer's Jamf Pro instance, but when clicked will forward a user to an arbitrary URL that may be malicious. This is tracked via Jamf with the following ID: PI-009822
Multiple vulnerabilities in the web-based management interface of Cisco Firepower Management Center (FMC) Software could allow an attacker to execute a cross-site scripting (XSS) attack or an open redirect attack. For more information about these vulnerabilities, see the Details section of this advisory.
Open redirect vulnerability in the Notifications module in Liferay Portal 7.0.0 through 7.3.1, and Liferay DXP 7.0 before fix pack 94, 7.1 before fix pack 19 and 7.2 before fix pack 8, allows remote attackers to redirect users to arbitrary external URLs via the 'redirect' parameter.
Umbraco CMS before 7.15.7 is vulnerable to Open Redirection due to insufficient url sanitization on booting.aspx.
SAP NetWeaver Knowledge Management allows remote attackers to redirect users to arbitrary websites and conduct phishing attacks via a URL stored in a component. This could enable the attacker to compromise the user's confidentiality and integrity.
A misconfiguration flaw was found in Keycloak. This issue can allow an attacker to redirect users to an arbitrary URL if a 'Valid Redirect URI' is set to http://localhost or http://127.0.0.1, enabling sensitive information such as authorization codes to be exposed to the attacker, potentially leading to session hijacking.
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, `oidc_validate_redirect_url()` does not parse URLs the same way as most browsers do. As a result, this function can be bypassed and leads to an Open Redirect vulnerability in the logout functionality. This bug has been fixed in version 2.4.9 by replacing any backslash of the URL to redirect with slashes to address a particular breaking change between the different specifications (RFC2396 / RFC3986 and WHATWG). As a workaround, this vulnerability can be mitigated by configuring `mod_auth_openidc` to only allow redirection whose destination matches a given regular expression.
GNU Wget through 1.21.1 does not omit the Authorization header upon a redirect to a different origin, a related issue to CVE-2018-1000007.
Products.isurlinportal is a replacement for isURLInPortal method in Plone. Versions of Products.isurlinportal prior to 1.2.0 have an Open Redirect vulnerability. Various parts of Plone use the 'is url in portal' check for security, mostly to see if it is safe to redirect to a url. A url like `https://example.org` is not in the portal. The url `https:example.org` without slashes is considered to be in the portal. When redirecting, some browsers go to `https://example.org`, others give an error. Attackers may use this to redirect victims to their site, especially as part of a phishing attack. The problem has been patched in Products.isurlinportal 1.2.0.
Tenancy multi-tenant is an open source multi-domain controller for the Laravel web framework. In some situations, it is possible to have open redirects where users can be redirected from your site to any other site using a specially crafted URL. This is only the case for installations where the default Hostname Identification is used and the environment uses tenants that have `force_https` set to `true` (default: `false`). Version 5.7.2 contains the relevant patches to fix this bug. Stripping the URL from special characters to prevent specially crafted URL's from being redirected to. As a work around users can set the `force_https` to every tenant to `false`, however this may degrade connection security.
The slashify package 1.0.0 for Node.js allows open-redirect attacks, as demonstrated by a localhost:3000///example.com/ substring.
The redirect URI in the LTI authorization endpoint required extra sanitizing to prevent reflected XSS and open redirect risks. Moodle versions 3.10 to 3.10.3, 3.9 to 3.9.6, 3.8 to 3.8.8 and earlier unsupported versions are affected.
The Python "Flask-Security-Too" package is used for adding security features to your Flask application. It is an is an independently maintained version of Flask-Security based on the 3.0.0 version of Flask-Security. All versions of Flask-Security-Too allow redirects after many successful views (e.g. /login) by honoring the ?next query param. There is code in FS to validate that the url specified in the next parameter is either relative OR has the same netloc (network location) as the requesting URL. This check utilizes Pythons urlsplit library. However many browsers are very lenient on the kind of URL they accept and 'fill in the blanks' when presented with a possibly incomplete URL. As a concrete example - setting http://login?next=\\\github.com will pass FS's relative URL check however many browsers will gladly convert this to http://github.com. Thus an attacker could send such a link to an unwitting user, using a legitimate site and have it redirect to whatever site they want. This is considered a low severity due to the fact that if Werkzeug is used (which is very common with Flask applications) as the WSGI layer, it by default ALWAYS ensures that the Location header is absolute - thus making this attack vector mute. It is possible for application writers to modify this default behavior by setting the 'autocorrect_location_header=False`.
Flask-AppBuilder is an application development framework, built on top of Flask. In affected versions if using Flask-AppBuilder OAuth, an attacker can share a carefully crafted URL with a trusted domain for an application built with Flask-AppBuilder, this URL can redirect a user to a malicious site. This is an open redirect vulnerability. To resolve this issue upgrade to Flask-AppBuilder 3.2.2 or above. If upgrading is infeasible users may filter HTTP traffic containing `?next={next-site}` where the `next-site` domain is different from the application you are protecting as a workaround.
Advantech WebAccess/SCADA Versions 9.0.1 and prior is vulnerable to redirection, which may allow an attacker to send a maliciously crafted URL that could result in redirecting a user to a malicious webpage.
An open redirect vulnerability is present in Piwigo 2.9 and probably prior versions, allowing remote attackers to redirect users to arbitrary web sites and conduct phishing attacks. The identification.php component is affected by this issue: the "redirect" parameter is not validated.
Movary is a web application to track, rate and explore your movie watch history. Prior to 0.69.0, the login page accepts a redirect parameter without validation, allowing attackers to redirect authenticated users to arbitrary external sites. This vulnerability is fixed in 0.69.0.
An issue was discovered in Joomla! 4.2.0 through 4.3.1. Lack of input validation caused an open redirect and XSS issue within the new mfa selection screen.