CVE-2026-55864: 
Java vulnerability analysis and mitigation

CVE-2026-55864 is an unauthenticated Server-Side Request Forgery (SSRF) vulnerability in the GeoNetwork Web Module's SLD tooling endpoint. It affects GeoNetwork versions 4.4.0–4.4.11 and 4.0.0–4.2.16 (Maven package org.geonetwork-opensource:gn-web-app). The vulnerability was published on August 31, 2026, and patched releases were made available on September 9, 2026. It carries a CVSS v4.0 base score of 7.7 (High) (Github Advisory, GeoNetwork Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the POST /api/tools/ogc/sld endpoint accepts a caller-supplied WMS server URL and performs an unvalidated server-side HTTP GET to that URL. No authentication is required to invoke this endpoint, and no allowlist or URL validation is applied to the supplied target. When the response from the outbound request is XML-formatted, the fetched content can be stored and retrieved by the attacker, making this a non-blind SSRF — the attacker can read internal responses directly. The fix, implemented in pull request #9343, removes the vulnerable SLD API endpoints entirely (POST /sld, GET /sld, DELETE /sld, GET /sld/{id}.xml, GET /sldform) and eliminates the associated SLDUtil methods and TextFile persistence layer (GeoNetwork Advisory, GeoNetwork PR #9343).

Any unauthenticated attacker can leverage this vulnerability to make the GeoNetwork server issue arbitrary HTTP requests to internal network hosts that are not publicly accessible. If internal services return XML responses, the attacker can read those responses directly, enabling disclosure of sensitive configuration files, internal API data, or other XML-formatted resources. This also facilitates internal network reconnaissance (port scanning, service enumeration) and potential authorization bypass against internal services that trust requests originating from the GeoNetwork server (Github Advisory).

No public proof-of-concept exploit code has been identified at this time, and there is no confirmed evidence of in-the-wild exploitation. The vulnerability requires no authentication, no user interaction, and no special preconditions, making it trivially exploitable by any anonymous user with network access to the GeoNetwork instance. The CVE status is currently listed as "Reserved," and it has not been added to the CISA Known Exploited Vulnerabilities catalog. Ethiack researchers (castilho101 and ethiack-admin) are credited as reporters (Github Advisory, Ethiack Research).

1. Reconnaissance: Identify publicly accessible GeoNetwork instances running versions 4.4.0–4.4.11 or 4.0.0–4.2.16 using search engines (Shodan, Censys) or by checking the GeoNetwork version endpoint (e.g., /geonetwork/srv/api/info).
2. Identify the vulnerable endpoint: Confirm the POST /api/tools/ogc/sld endpoint is accessible without authentication by sending a test request.
3. Craft the SSRF payload: Construct a POST request to /api/tools/ogc/sld with a body containing a WMS server URL pointing to an internal target (e.g., http://169.254.169.254/latest/meta-data/ for cloud metadata, or http://internal-host:8080/config.xml for internal services).
4. Send the request: Submit the crafted request as an unauthenticated user. The GeoNetwork server will perform a server-side HTTP GET to the attacker-supplied URL.
5. Retrieve the response: If the internal service returns an XML response, the fetched content is stored and can be downloaded by the attacker, revealing internal data such as configuration files, credentials, or network topology information (GeoNetwork Advisory, Ethiack Research).

• Network: Unexpected outbound HTTP GET requests from the GeoNetwork server to internal IP ranges (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (169.254.169.254); outbound requests to unusual ports or hostnames originating from the GeoNetwork process.
• Logs: Web server access logs showing unauthenticated POST requests to /api/tools/ogc/sld or /geonetwork/srv/api/tools/ogc/sld from external IP addresses; repeated requests with varying URL parameters in the POST body.
• Application Logs: GeoNetwork application logs recording HTTP client activity to internal hosts or non-standard URLs; errors from failed connection attempts to internal services.
• File System: Unexpected XML files stored in the GeoNetwork data directory corresponding to fetched internal responses (prior to patching, the SLD endpoint persisted fetched XML content via the TextFile JPA entity) (GeoNetwork Advisory).

Upgrade to the patched releases GeoNetwork 4.4.12 or 4.2.17, which remove the vulnerable SLD API endpoints entirely. No configuration-based workaround is documented; the fix eliminates the vulnerable code path rather than adding validation. Organizations unable to upgrade immediately should consider blocking external access to the /api/tools/ogc/sld endpoint via a web application firewall or reverse proxy rule as a temporary measure (Github Advisory, GeoNetwork PR #9343).

The vulnerability was discovered and reported by researchers at Ethiack (castilho101 and ethiack-admin), who published a research post on the finding. The fix was coordinated by GeoNetwork maintainer jodygarnett and implemented by contributor juanluisrp. No significant broader media coverage or notable community debate has been identified beyond the advisory and the Ethiack research post (Ethiack Research, GeoNetwork Advisory).