core-geonetwork has an Open Redirect BypassGHSA-pjp7-q6wp-97qx
NONEFix: geonetwork/core-geonetwork#9307GHSA-pjp7-q6wp-97qx is a none-severity (CVSS 0) Open Redirect vulnerability in org.geonetwork-opensource:geonetwork. A fix is available for org.geonetwork-opensource:geonetwork — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-pjp7-q6wp-97qx.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
org.geonetwork-opensource:geonetwork☕org.geonetwork-opensource:geonetwork☕org.geonetwork-opensource:geonetwork☕org.geonetwork-opensource:geonetworkReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
GeoNetwork's post-login redirect handling can be bypassed to redirect users to an attacker-controlled external site, even though the code attempts to restrict redirect targets to relative, in-application URLs. This affects both supported SSO login methods: OAuth2/OIDC and Keycloak.
Details
Both the OAuth2/OIDC and Keycloak login filters validate the client-supplied post-login redirect target before forwarding the browser to it, but the validation does not correctly reject every kind of URL that causes the browser to leave the GeoNetwork origin. As a result, a value that is treated as a safe, in-application relative path by the filter can still cause the browser to be redirected to an external, attacker-controlled host.
Impact
An attacker can craft a link to a legitimate GeoNetwork OAuth2/OIDC or Keycloak login endpoint that, after the login flow completes, redirects the victim to an arbitrary external site. This can be used for phishing (e.g., presenting a fake login form) or to chain into other attacks hosted externally. This does not bypass authentication or expose GeoNetwork data directly; the impact is Open Redirect (CWE-601).
GeoNetwork 3.x and 4.0.x are archived/unmaintained and will not receive a fix for this issue. Instances running those lines should upgrade to a supported release (4.2.16 or later, or 4.4.11 or later).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.geonetwork-opensource:geonetwork | ≥ 3.12.0 | No fix |
| ☕Maven | org.geonetwork-opensource:geonetwork | ≥ 4.0.0-alpha.1 | No fix |
| ☕Maven | org.geonetwork-opensource:geonetwork | ≥ 4.2.0&&< 4.2.16 | 4.2.16org.geonetwork-opensource:geonetwork:4.2.16 |
| ☕Maven | org.geonetwork-opensource:geonetwork | ≥ 4.4.0&&< 4.4.11 | 4.4.11org.geonetwork-opensource:geonetwork:4.4.11 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.geonetwork-opensource:geonetwork, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
No patched version of org.geonetwork-opensource:geonetwork has shipped for GHSA-pjp7-q6wp-97qx yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Workarounds
Stop reflecting attacker-controlled destinations: resolve every redirect target against an allowlist of paths or hosts you own, prefer a server-side key over a full URL in the request, and reject absolute URLs entirely where the flow only ever needs a relative one.
Frequently Asked Questions
Is GHSA-pjp7-q6wp-97qx in your dependencies?
Find it across Maven, including transitive dependencies.