CVE-2026-53573: 
Java 취약성 분석 및 완화

CVE-2026-53573 is an Open Redirect vulnerability (CWE-601) in GeoNetwork, an open-source catalog application for managing spatially referenced resources. The flaw exists in the post-login redirect handling of GeonetworkOAuth2LoginAuthenticationFilter and KeycloakAuthenticationProcessingFilter, where insufficient validation of the redirectUrl parameter allows an attacker-controlled external redirect after a successful login. Affected versions span from 3.12.0 through 3.12.12, 4.0.0-alpha.1 through 4.0.6, 4.2.0 through 4.2.15, and 4.4.0 through 4.4.10. The vulnerability was published on July 31, 2026, with a CVSS v4.0 base score of 4.8 (Medium) (GitHub Advisory).

The root cause (CWE-601) lies in both GeonetworkOAuth2LoginAuthenticationFilter and KeycloakAuthenticationProcessingFilter using URI.isAbsolute() as the sole check to validate the client-supplied redirectUrl query parameter after login. This check fails to reject protocol-relative URLs (e.g., //evil.example.com) and other non-absolute URI forms that browsers still resolve as external hosts, allowing the validation to be bypassed. The fix introduced a centralized RedirectUtil helper class that enforces strict server-local relative path validation — requiring a single leading /, rejecting // and /\ prefixes, and verifying the URI carries no scheme, host, or authority component (GitHub Advisory, PR #9307). Exploitation requires active user interaction (the victim must click a crafted login link) and low privileges on the attacker's side (GitHub Advisory).

Successful exploitation allows an attacker to redirect a victim to an arbitrary external site immediately after completing a legitimate GeoNetwork OAuth2/OIDC or Keycloak login flow. This can be leveraged for phishing attacks — for example, presenting a fake login page to harvest credentials — or to chain into other externally hosted attacks. The vulnerability does not bypass authentication, expose GeoNetwork data directly, or affect confidentiality or availability of the GeoNetwork instance itself (GitHub Advisory).

1. Identify target: Locate a GeoNetwork instance (versions 3.12.0–3.12.12, 4.0.0-alpha.1–4.0.6, 4.2.0–4.2.15, or 4.4.0–4.4.10) configured with OAuth2/OIDC or Keycloak SSO login.
2. Craft malicious login URL: Construct a login URL targeting the OAuth2/OIDC or Keycloak login endpoint with a redirectUrl parameter set to a protocol-relative or otherwise bypass-capable URL, e.g.: https://geonetwork.example.org/geonetwork/signin?redirectUrl=//attacker.example.com/fake-login
3. Deliver to victim: Send the crafted URL to the target user via phishing email, social engineering, or embedded link, leveraging the legitimacy of the GeoNetwork domain to build trust.
4. Victim completes login: The victim authenticates normally through the OAuth2/OIDC or Keycloak flow on the legitimate GeoNetwork server.
5. Redirect executes: Upon successful authentication, the vulnerable filter reads the redirectUrl parameter, passes the URI.isAbsolute() check (since //attacker.example.com is not considered absolute by Java's URI parser), and issues a redirect to the attacker-controlled site.
6. Attacker objective achieved: The victim's browser lands on the attacker's site, where a fake login page or other malicious content can be presented to harvest credentials or deliver further payloads (GitHub Advisory, PR #9307).

• Network: HTTP requests to GeoNetwork OAuth2/OIDC or Keycloak login endpoints containing a redirectUrl query parameter with values starting with //, /\, or an external hostname (e.g., redirectUrl=//attacker.example.com or redirectUrl=https://external-site.com).
• Logs: GeoNetwork application security logs (look for the Geonet.SECURITY log category) showing entries such as "Refused unsafe login redirect to '...'" — note these entries only appear in patched versions; their absence on unpatched systems does not confirm safety. Web/proxy access logs showing 302 redirects from GeoNetwork login endpoints to external domains immediately following successful authentication.
• Network: Outbound HTTP redirects (302 responses) from the GeoNetwork server to domains not matching the configured SYSTEM_SERVER_HOST value, triggered immediately after a login completion event.

Upgrade to GeoNetwork 4.2.16 or 4.4.11, which introduce a centralized RedirectUtil helper that strictly validates post-login redirect targets to server-local relative paths only, rejecting protocol-relative URLs and any external hosts (GitHub Advisory, Release 4.2.16, Release 4.4.11). GeoNetwork 3.x and 4.0.x are archived and will not receive patches; operators running those versions must migrate to a supported release. No configuration-based workaround is available — upgrading is the only remediation.