Skip to main content
Stopping PHP2SHELL: How SentinelOne Protects Customers From This Attack TechniqueRead More
Vulnerability Database/CVE-2026-55864

CVE-2026-55864: GeoNetwork SSRF Vulnerability

CVE-2026-55864 is an SSRF vulnerability in GeoNetwork that lets attackers force the server to make unauthorized requests to internal hosts, potentially exposing sensitive data. This article covers technical details, versions at risk, and fixes.

Published:

CVE-2026-55864 Overview

GeoNetwork is an open-source catalog application used to manage spatially referenced resources. CVE-2026-55864 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] affecting the POST /api/tools/ogc/sld endpoint. The endpoint accepted a caller-supplied Web Map Service (WMS) URL and performed a server-side HTTP GET without destination validation. An unauthenticated attacker can force the GeoNetwork server to issue requests to internal hosts that are not publicly reachable. When the outbound response is XML, the endpoint stores and returns the fetched body, turning the SSRF into a non-blind primitive suitable for internal data disclosure, authorization bypass, and network reconnaissance.

Critical Impact

Anonymous attackers can pivot into internal networks, read XML responses from internal services, and enumerate reachable hosts through the GeoNetwork server.

Affected Products

  • GeoNetwork core versions prior to 4.2.17
  • GeoNetwork core versions prior to 4.4.12
  • Deployments exposing the /api/tools/ogc/sld endpoint to anonymous callers

Discovery Timeline

  • 2026-09-15 - CVE-2026-55864 published to the National Vulnerability Database (NVD)
  • 2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-55864

Vulnerability Analysis

The vulnerable endpoint POST /api/tools/ogc/sld accepted a WMS server URL as user-controlled input. GeoNetwork issued an outbound HTTP GET to that URL without validating the destination. There was no allowlist, no scheme restriction, and no filtering of loopback, link-local, or private IP ranges.

Because the endpoint returned the fetched response body when the payload was XML, the SSRF is non-blind. Attackers receive the response content directly, which supports reconnaissance of internal HTTP services and exfiltration of XML documents accessible to the GeoNetwork process. The endpoint was reachable anonymously, removing any authentication barrier.

Root Cause

The root cause is missing destination validation on a caller-supplied URL passed to a server-side HTTP client. The SLD (Styled Layer Descriptor) tooling did not restrict outbound targets or normalize URLs prior to issuing the request. The GeoNetwork maintainers addressed the issue by removing the unused SLD API endpoints entirely, along with the supporting TextFile entity and TextFileRepository used to persist fetched content.

Attack Vector

Exploitation requires only network access to the GeoNetwork instance. An anonymous attacker sends a crafted POST request to /api/tools/ogc/sld with a WMS URL pointing at an internal target, such as a metadata service, admin console, or internal API. GeoNetwork fetches the URL and, when the response is XML, returns the body to the attacker. This enables authorization bypass against services that trust the GeoNetwork server's network position.

java
// Patch (removed code) - domain/src/main/java/org/fao/geonet/domain/TextFile.java
// The TextFile entity used to persist fetched SLD content was removed as part of the fix.
-package org.fao.geonet.domain;
-
-import javax.persistence.*;
-
-@Entity
-@Table(name = "files")
-@SequenceGenerator(name= TextFile.ID_SEQ_NAME, initialValue=1, allocationSize=1)
-public class TextFile extends GeonetEntity {
-
-    static final String ID_SEQ_NAME = "files_id_seq";
-
-    private int _id;
-    private String _content;
-    private String _mimeType;
-
-    @Id
-    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = TextFile.ID_SEQ_NAME)
-    @Column(nullable = false)
-    public int getId() {
-        return this._id;
-    }
-
-    @Column(nullable = false)
-    @Lob
-    public String getContent() {

Source: GitHub Commit 17fdae28

java
// Patch (removed code) - domain/src/main/java/org/fao/geonet/repository/TextFileRepository.java
// The repository used to store SLD content fetched from attacker-supplied URLs was removed.
-package org.fao.geonet.repository;
-
-import org.fao.geonet.domain.TextFile;
-
-/**
- * Data Access object for the {@link TextFile} entities.
- */
-public interface TextFileRepository extends GeonetRepository<TextFile, Integer> {}

Source: GitHub Commit a80d535c (4.2.x backport)

Detection Methods for CVE-2026-55864

Indicators of Compromise

  • HTTP POST requests to /api/tools/ogc/sld from anonymous or unexpected clients
  • Request bodies referencing loopback (127.0.0.1), link-local (169.254.169.254), or private RFC1918 addresses as the WMS URL
  • Outbound HTTP GET traffic from the GeoNetwork host targeting internal-only services or cloud metadata endpoints
  • Unusually large XML responses returned by the /api/tools/ogc/sld endpoint to external callers

Detection Strategies

  • Correlate inbound requests to /api/tools/ogc/sld with outbound HTTP connections initiated by the GeoNetwork process within a short time window
  • Alert on outbound requests from the application server to cloud metadata IPs (169.254.169.254, fd00:ec2::254) or internal management subnets
  • Baseline normal outbound destinations of the GeoNetwork JVM and flag deviations to non-WMS hosts

Monitoring Recommendations

  • Enable and forward GeoNetwork access logs to a centralized log platform for retention and query
  • Monitor egress from the GeoNetwork host at a network chokepoint; SSRF traffic often bypasses host-level controls
  • Track authentication state on requests to /api/tools/ogc/sld; anonymous invocations after patching should be zero

How to Mitigate CVE-2026-55864

Immediate Actions Required

  • Upgrade GeoNetwork to version 4.2.17 or 4.4.12, which remove the vulnerable SLD API endpoints
  • Block anonymous access to /api/tools/ogc/ paths at the reverse proxy until upgrade is complete
  • Restrict egress from the GeoNetwork host to only the WMS/WFS endpoints it legitimately needs to reach
  • Review access logs for prior invocations of /api/tools/ogc/sld and investigate any that targeted internal URLs

Patch Information

The fix is delivered in GeoNetwork 4.2.17 and GeoNetwork 4.4.12. The maintainers removed the unused SLD API endpoints along with the supporting TextFile entity and TextFileRepository in Pull Request #9343 and Pull Request #9344. See the GHSA-5hx7-j24v-rffj advisory for the full disclosure.

Workarounds

  • Deny requests to /api/tools/ogc/sld at the reverse proxy or web application firewall (WAF) until patches are applied
  • Place GeoNetwork behind an egress proxy that enforces an allowlist of permitted outbound WMS destinations
  • Deploy the GeoNetwork server on a network segment without routable access to internal management interfaces or cloud metadata services
bash
# Example NGINX configuration to block the vulnerable endpoint pre-upgrade
location = /api/tools/ogc/sld {
    return 403;
}

# Optional: block the wider tools path if not required by clients
location ^~ /api/tools/ogc/ {
    deny all;
    return 403;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne