A vulnerability, which was classified as problematic, was found in CodeAstro Internet Banking System 1.0. This affects an unknown part of the file pages_client_signup.php. The manipulation of the argument Client Full Name with the input <meta http-equiv="refresh" content="0; url=https://vuldb.com" /> leads to open redirect. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-251697 was assigned to this vulnerability.

Open Redirect vulnerability exists in IceWarp MailServer IceWarp Server Deep Castle 2 Update 1 (13.0.1.2) via the referer parameter.

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.

Horilla is a free and open source Human Resource Management System (HRMS). In versions up to and including 1.3, an attacker can craft a Horilla URL that refers to an external domain. Upon clicking and logging in, the user is redirected to an external domain. This allows the redirection to any arbitrary site, including phishing or malicious domains, which can be used to impersonate Horilla and trick users. Commit 1c72404df6888bb23af73c767fdaee5e6679ebd6 fixes the issue.

The WordPress Toolbar WordPress plugin through 2.2.6 redirects to any URL via the "wptbto" parameter. This makes it possible for unauthenticated attackers to redirect users to potentially malicious sites if they can successfully trick them into performing an action.

A CWE-601 URL Redirection to Untrusted Site vulnerability exists that could cause an openredirect vulnerability leading to a cross site scripting attack. By providing a URL-encoded input attackers can cause the software’s web application to redirect to the chosen domain after a successful login is performed.

The Payment Gateway for Telcell WordPress plugin through 2.0.1 does not validate the api_url parameter before redirecting the user to its value, leading to an Open Redirect issue

In JetBrains TeamCity before 2025.03.2 open redirect was possible on editing VCS Root page

A CWE-601:URL Redirection to Untrusted Site (‘Open Redirect’) vulnerability exists that could cause disclosure of information through phishing attempts over HTTP.

Gitpod before 0.6.0 allows unvalidated redirects.

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 flaw was found in mod_auth_mellon where it does not sanitize logout URLs properly. This issue could be used by an attacker to facilitate phishing attacks by tricking users into visiting a trusted web application URL that redirects to an external and potentially malicious server. The highest threat from this liability is to confidentiality and integrity.

URI.js is vulnerable to URL Redirection to Untrusted Site

Open redirect vulnerability in the Countries Management’s edit region page in Liferay Portal 7.4.3.45 through 7.4.3.101, and Liferay DXP 2023.Q3 before patch 6, and 7.4 update 45 through 92 allows remote attackers to redirect users to arbitrary external URLs via the _com_liferay_address_web_internal_portlet_CountriesManagementAdminPortlet_redirect parameter.

@misskey-dev/summaly is a tool for getting a summary of a web page. Starting in version 3.0.1 and prior to version 5.2.1, a logic error in the main `summaly` function causes the `allowRedirects` option to never be passed to any plugins, and as a result, isn't enforced. Misskey will follow redirects, despite explicitly requesting not to. Version 5.2.1 contains a patch for the issue.

An attacker could construct a URL within the application that causes a redirection to an arbitrary external domain and could be leveraged to facilitate phishing attacks against application users.

Jenkins OpenId Connect Authentication Plugin 2.6 and earlier improperly determines that a redirect URL after login is legitimately pointing to Jenkins, allowing attackers to perform phishing attacks.

Open redirect vulnerability in PowerCMS (6 Series, 5 Series, and 4 Series) allows a remote unauthenticated attacker to redirect users to arbitrary web sites via a specially crafted URL. Note that all versions of PowerCMS 3 Series and earlier which are unsupported (End-of-Life, EOL) are also affected by this vulnerability.

A vulnerability was found in openstack-nova's console proxy, noVNC. By crafting a malicious URL, noVNC could be made to redirect to any desired URL.

HCL DRYiCE MyXalytics is impacted by an Open Redirect vulnerability which could allow an attacker to redirect users to malicious sites, potentially leading to phishing attacks or other security threats.

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

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Pexle Chris Library Viewer.This issue affects Library Viewer: from n/a through 2.0.6.

XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions prior to 14.10.4 it's possible to exploit well known parameters in XWiki URLs to perform redirection to untrusted site. This vulnerability was partially fixed in the past for XWiki 12.10.7 and 13.3RC1 but there is still the possibility to force specific URLs to skip some checks, e.g. using URLs like `http:example.com` in the parameter would allow the redirect. The issue has now been patched against all patterns that are known for performing redirects. This issue has been patched in XWiki 14.10.4 and 15.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.

An open redirect vulnerability exists in the /preauth Servlet in Zimbra Collaboration Suite through 9.0. To exploit the vulnerability, an attacker would need to have obtained a valid zimbra auth token or a valid preauth token. Once the token is obtained, an attacker could redirect a user to any URL via isredirect=1&redirectURL= in conjunction with the token data (e.g., a valid authtoken= value).

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.

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.

Umbraco CMS before 7.15.7 is vulnerable to Open Redirection due to insufficient url sanitization on booting.aspx.

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.

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.

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.

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.

Landscape allowed URLs which caused open redirection.

PowerMux is a drop-in replacement for Go's http.ServeMux. In PowerMux versions prior to 1.1.1, attackers may be able to craft phishing links and other open redirects by exploiting the trailing slash redirection feature. This may lead to users being redirected to untrusted sites after following an attacker crafted link. The issue is resolved in v1.1.1. There are no existing workarounds.

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.

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.

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.

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`.

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.

Open Redirect vulnerability in /c/portal/edit_info_item parameter redirect in Liferay Portal 7.4.3.86 through 7.4.3.131, and Liferay DXP 2024.Q3.1 through 2024.Q3.9, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.12 and 7.4 update 86 through update 92 allows an attacker to exploit this security vulnerability to redirect users to a malicious site.

Due to insufficient sanitization in the SAP BusinessObjects Content Administrator Workbench, attackers could craft malicious URLs and execute scripts in a victim�s browser. This could potentially lead to the exposure or modification of web client data, resulting in low impact on confidentiality and integrity, with no impact on application availability.

Due to an open redirect vulnerability in SAP NetWeaver Application Server ABAP, an unauthenticated attacker could craft a URL link embedding a malicious script at a location not properly sanitized. When a victim clicks on this link, the script executes within the victim's browser, redirecting them to a site controlled by the attacker. This allows the attacker to access and/or modify restricted information related to the web client. While the vulnerability poses no impact on data availability, it presents a considerable risk to confidentiality and integrity.

The Protect WP Admin WordPress plugin before 4.0 discloses the URL of the admin panel via a redirection of a crafted URL, bypassing the protection offered.

The slashify package 1.0.0 for Node.js allows open-redirect attacks, as demonstrated by a localhost:3000///example.com/ substring.

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.

An open redirect vulnerability exists in BF-630, BF-450M, BF-430, BF-431, BF631-W, BF830-W, Webpass, and SEMAC devices from CHIYU Technology that can be exploited by sending a link that has a specially crafted URL to convince the user to click on it.

URL Redirection to Untrusted Site ('Open Redirect') vulnerability in PluginOps MailChimp Subscribe Form, Optin Builder, PopUp Builder, Form Builder.This issue affects MailChimp Subscribe Form, Optin Builder, PopUp Builder, Form Builder: from n/a through 4.0.9.3.

Blackboard Learning and Community Portal System in Academic Suite 6.3.1.424, 6.2.3.23, and other versions before 6 allows remote attackers to redirect users to other URLs and conduct phishing attacks via a modified url parameter to frameset.jsp, which loads the URL into a frame and causes it to appear to be part of a valid page.

Pomerium from version 0.10.0-0.13.3 has an Open Redirect in the user sign-in/out process

Prometheus is an open-source monitoring system and time series database. In 2.23.0, Prometheus changed its default UI to the New ui. To ensure a seamless transition, the URL's prefixed by /new redirect to /. Due to a bug in the code, it is possible for an attacker to craft an URL that can redirect to any other URL, in the /new endpoint. If a user visits a prometheus server with a specially crafted address, they can be redirected to an arbitrary URL. The issue was patched in the 2.26.1 and 2.27.1 releases. In 2.28.0, the /new endpoint will be removed completely. The workaround is to disable access to /new via a reverse proxy in front of Prometheus.

The OAuth implementation in workers-oauth-provider that is part of MCP framework https://github.com/cloudflare/workers-mcp , did not correctly validate that redirect_uri was on the allowed list of redirect URIs for the given client registration. Fixed in:  https://github.com/cloudflare/workers-oauth-provider/pull/26 https://github.com/cloudflare/workers-oauth-provider/pull/26 Impact: Under certain circumstances (see below), if a victim had previously authorized with a server built on workers-oath-provider, and an attacker could later trick the victim into visiting a malicious web site, then attacker could potentially steal the victim's credentials to the same OAuth server and subsequently impersonate them. In order for the attack to be possible, the OAuth server's authorized callback must be designed to auto-approve authorizations that appear to come from an OAuth client that the victim has authorized previously. The authorization flow is not implemented by workers-oauth-provider; it is up to the application built on top to decide whether to implement such automatic re-authorization. However, many applications do implement such logic. Note: It is a basic, well-known requirement that OAuth servers should verify that the redirect URI is among the allowed list for the client, both during the authorization flow and subsequently when exchanging the authorization code for an access token. workers-oauth-provider implemented only the latter check, not the former. Unfortunately, the former is the much more important check. Readers who are familiar with OAuth may recognize that failing to check redirect URIs against the allowed list is a well-known, basic mistake, covered extensively in the RFC and elsewhere. The author of this library would like everyone to know that he was, in fact, well-aware of this requirement, thought about it a lot while designing the library, and then, somehow, forgot to actually make sure the check was in the code. That is, it's not that he didn't know what he was doing, it's that he knew what he was doing but flubbed it.