CVE-2026-53573: Open Redirect Bypass in GeoNetwork OAuth2/OIDC and Keycloak Login Filters

The open redirect vulnerability, tracked as CVE-2026-53573, resides within the authentication and session management filters of core-geonetwork, an open-source catalog application designed for managing spatially referenced resources. Specifically, the flaw exists within GeonetworkOAuth2LoginAuthenticationFilter and KeycloakAuthenticationProcessingFilter. These filters fail to adequately validate user-supplied redirect parameters post-authentication, leaving users susceptible to external redirection.

The attack surface exists primarily in the OAuth2, OpenID Connect (OIDC), and Keycloak single sign-on (SSO) integration paths, where users are redirected to a destination specified in parameters like redirectUrl or targetUrlParameter. If an unauthenticated or low-privilege attacker can manipulate these parameters, they can force the application to redirect successfully authenticated clients to arbitrary external domains.

The underlying vulnerability class is CWE-601: URL Redirection to Untrusted Site ('Open Redirect'). The issue occurs because the validation logic assumes relative URLs starting with a forward slash are inherently safe, failing to account for protocol-relative or mixed-slash constructs that modern browsers normalize into absolute external URLs.

The root cause of CVE-2026-53573 lies in how the Java-based backend and client-side web browsers interpret relative paths. In legacy versions of core-geonetwork, JeevesNodeAwareLogoutSuccessHandler.java validated the target redirect URL by checking if it started with a single forward slash. If the URL met this condition, the filter bypassed the host, protocol, and port verification under the false assumption that any path starting with a single slash was internal to the application.

This check is flawed because it fails to account for protocol-relative URLs (such as //attacker.com) or mixed slashes (such as /\attacker.com). Modern browsers automatically normalize backslashes into forward slashes during parsing. They treat a leading double slash as an absolute, protocol-relative URL, resolving it to http://attacker.com or https://attacker.com depending on the current page's protocol scheme.

Similarly, in filters handling SSO authentication, such as GeonetworkOAuth2LoginAuthenticationFilter and KeycloakAuthenticationProcessingFilter, the code parsed the target redirect with the java.net.URI class. It called the isAbsolute() method to verify if the URL was absolute. However, in java.net.URI, a protocol-relative URI like //attacker.com has no explicit scheme, causing isAbsolute() to return false. The application subsequently treated the URI as relative and allowed the browser-directed redirect.

To resolve the issue, the maintainers implemented a centralized validator utility, RedirectUtil.java, and refactored authentication filters to enforce strict redirection rules. The new utility performs comprehensive normalization of backslashes before running any validation. This ensures mixed-slash payloads such as /\attacker.com are evaluated correctly.

The core of the fix is located in the isRelativeRedirect method inside RedirectUtil.java, which explicitly checks for double-slash combinations and denies them:

String normalized = redirectUrl.replace('\\', '/');
if (!normalized.startsWith("/") || normalized.startsWith("//")) {
    return false;
}

Additionally, the utility verifies that the java.net.URI object does not expose a host or authority, which is a key indicator of a protocol-relative exploit attempt:

URI redirectUri = new URI(redirectUrl);
if (redirectUri.isAbsolute() || redirectUri.getHost() != null || redirectUri.getAuthority() != null) {
    return false;
}

The filters were updated to replace custom, inline redirection parsing with calls to RedirectUtil.sendSafeRedirect or RedirectUtil.isSafeRedirect, ensuring consistent and secure redirection processing across all entry points.

An attacker exploits this vulnerability by crafting a link to a GeoNetwork instance that contains a malicious redirect payload. The primary prerequisite is that the target GeoNetwork server must have OAuth2, OIDC, or Keycloak SSO enabled, or the attacker must target the logout handler. The attacker distributes this crafted URL to potential victims using spearphishing techniques or other social engineering vectors.

When a victim visits the crafted link, they are initially presented with the authentic GeoNetwork portal. The victim logs in normally, entering their credentials and potentially completing multi-factor authentication. Since the host is legitimate, standard network defenses and email filters may permit the link, and browser indicators (such as SSL locks) remain valid during the authentication process.

Upon successful login, the server evaluates the redirect parameter. The backend validates the malformed string (e.g., //evil.com), incorrectly classifies it as a relative local path, and returns an HTTP 302 Redirect to the victim's browser. The victim's browser normalizes the location header to https://evil.com, seamlessly redirecting the victim to the attacker's server to facilitate credential harvesting or session hijacking.

The impact of CVE-2026-53573 is primarily centered on integrity and authentication flows. While an open redirect vulnerability does not allow direct remote code execution or data extraction on the host system itself, it serves as a critical facilitator for complex phishing campaigns. Attackers leverage the reputation of the trusted GeoNetwork domain to bypass email security gateways and link analyzers.

The vulnerability is assigned a CVSS v4.0 score of 4.8, reflecting low confidentiality and integrity impact from the perspective of the application server, but highlighting the potential for downstream user compromise. If an attacker successfully redirects an administrative user to a credential-harvesting site, they can capture active sessions or access tokens, leading to a complete compromise of the metadata catalog.

Furthermore, because GeoNetwork is used to manage spatially referenced resources and geographical catalogs (often within government or defense sectors), compromised credentials can lead to unauthorized modification of critical geospatial datasets or access to restricted geographic information.

Remediation requires upgrading core-geonetwork to versions 4.2.16 or 4.4.11, which contain the comprehensive RedirectUtil implementation. If upgrading immediately is not feasible, administrators can deploy Web Application Firewall (WAF) rules to detect and drop requests containing protocol-relative strings within redirection parameters.

Deploying a custom regex-based filter on reverse proxies or WAFs can mitigate the risk by blocking URL-encoded slash variants. An example regex pattern matches double-forward slashes or forward-backslash combinations in parameters like redirectUrl:

(?i)(?:redirecturl|target|redirect_uri)=\s*(?://|/\\|\\/)

In addition, implementing a strong Content Security Policy (CSP) can help limit where form submissions and network requests are directed, reducing the likelihood of successful data exfiltration even if a user is redirected. Security teams should also inspect server access logs for anomalous redirect destinations or warning logs containing the message 'Refused unsafe login redirect' which indicates blocked exploitation attempts.