Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 4.4.11 or 4.2.16 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GeoNetwork's Elasticsearch-backed search API is responsible for injecting access-control and visibility filters into every request before it reaches the underlying Elasticsearch index. Under certain request conditions, that filtering step does not run, allowing an unauthenticated user to retrieve indexed metadata records that should be restricted, including records limited to specific groups. Details The search proxy layer forwards client-supplied search requests to Elasticsearch after adding GeoNetwork's own access-control and filter clauses. A flaw in how that filter-injection step is triggered means it can be skipped under certain conditions, so the affected request reaches Elasticsearch without the intended access restrictions applied. Impact This is an authorization bypass leading to information disclosure (CWE-862: Missing Authorization). The skipped filter step is responsible for enforcing several layers of access control at once: group-based record visibility, draft…
Recommended action: Upgrade to 4.4.11 or 4.2.16 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to craft a URL that causes GeoNetwork to reflect attacker-controlled content into an error page in a way that gets evaluated as a client-side template expression. Combined with known AngularJS sandbox-escape techniques, this can be used to execute arbitrary JavaScript in the victim's browser (reflected Cross-Site Scripting via client-side template injection). Details When a user requests a service URL that does not exist or that they are not authorized to access, GeoNetwork shows an error page that reflects part of the original request back to the user without adequately neutralizing it for the context it is rendered in. Because this error page is an AngularJS application, attacker-controlled content in the reflected value can be interpreted as a template expression and evaluated once the page loads in the victim's browser, rather than being displayed as inert text. Impact An attacker can trick a user (including an administrator) into visiting a crafted link.…
Recommended action: Upgrade to 4.4.10 or 4.2.15 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.