CVE-2026-86806: opengeos GeoLibre SSRF Vulnerability

CVE-2026-86806 Overview

CVE-2026-86806 is a Server-Side Request Forgery (SSRF) vulnerability in opengeos GeoLibre versions up to 2.3.0. The flaw resides in the _is_within_roots function, which fails to properly validate URLs before the application issues outbound requests. Attackers can exploit this weakness remotely without authentication or user interaction, causing the server to make requests to unintended destinations. The issue is categorized under CWE-918: Server-Side Request Forgery. The maintainers addressed the issue in GeoLibre 2.4.0 with patch commit b745f62e29fa37364686525a21eee5e5c0f8a369.

Critical Impact
Remote, unauthenticated attackers can coerce the GeoLibre server into issuing arbitrary HTTP requests, potentially reaching internal services or metadata endpoints not exposed to the internet.

Affected Products

opengeos GeoLibre versions up to and including 2.3.0
The vulnerable component is the _is_within_roots root-path validation function
Fixed in GeoLibre 2.4.0

Discovery Timeline

2026-09-08 - CVE-2026-86806 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86806

Vulnerability Analysis

The vulnerability exists in GeoLibre's _is_within_roots function, which is intended to constrain path or URL resolution to a trusted set of roots. Because the check is insufficient, an attacker-controlled input reaches downstream request logic and causes the server to issue an HTTP request to an attacker-chosen destination. SSRF flaws of this type typically enable reconnaissance of internal networks, interaction with cloud metadata services, and pivoting to services that trust the application server's identity. The patch commit b745f62e29fa37364686525a21eee5e5c0f8a369 also mentions broader hardening for sidecar authentication, path sandboxing, plugin trust, and AI code execution, indicating the fix is part of a larger security-hardening pass.

Root Cause

The root cause is inadequate validation inside _is_within_roots. The function was intended to enforce that resource requests remain within an allowed root set, but the check can be bypassed, allowing user-supplied values to influence server-initiated network requests. This is a classic SSRF pattern where an allowlist or path-containment check does not fully normalize or canonicalize its input before comparison.

Attack Vector

Exploitation is remote and requires no authentication or user interaction. An attacker submits a crafted request to a GeoLibre endpoint that eventually invokes the vulnerable validation routine. The server then performs an outbound request to a URL controlled by the attacker or targeting an internal resource such as 127.0.0.1, RFC1918 ranges, or cloud instance metadata endpoints (for example, 169.254.169.254).

rust

// Excerpt from the security patch in
// apps/geolibre-desktop/src-tauri/src/native_duckdb.rs
        )
        .expect("write prj sidecar");

-        let crs = read_prj_sidecar_crs(&shp_path.to_string_lossy())
-            .expect("prj sidecar resolves a CRS");
+        let crs =
+            read_prj_sidecar_crs(&shp_path.to_string_lossy()).expect("prj sidecar resolves a CRS");
        assert_eq!(
            crs,
            "PROJCS[\"British_National_Grid\",GEOGCS[\"GCS_OSGB_1936\"]]"
// Source: https://github.com/opengeos/GeoLibre/commit/b745f62e29fa37364686525a21eee5e5c0f8a369

The full patch scope, including the changes to _is_within_roots, is documented in the GeoLibre commit details and the associated pull request #1571.

Detection Methods for CVE-2026-86806

Indicators of Compromise

Outbound HTTP requests from the GeoLibre server process to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or loopback addresses.
Requests originating from GeoLibre to cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal.
Unusual DNS lookups from the GeoLibre host for attacker-controlled or internal-only hostnames.

Detection Strategies

Inspect GeoLibre application logs for requests that reach path- or URL-handling endpoints with unexpected schemes (file://, gopher://) or hostnames.
Correlate application request logs with egress firewall or proxy logs to identify server-initiated traffic that does not match legitimate map-tile or data-source patterns.
Deploy web application firewall (WAF) rules that inspect and normalize URL parameters passed to GeoLibre before they reach the _is_within_roots code path.

Monitoring Recommendations

Enforce egress filtering and alert on any GeoLibre outbound connection to non-allowlisted destinations.
Monitor for anomalous spikes in outbound request volume from GeoLibre hosts, which may indicate SSRF-driven scanning.
Alert on GeoLibre-initiated requests to cloud instance metadata services, which is a strong signal of SSRF exploitation in cloud deployments.

How to Mitigate CVE-2026-86806

Immediate Actions Required

Upgrade GeoLibre to version 2.4.0 or later, which contains patch commit b745f62e29fa37364686525a21eee5e5c0f8a369.
Inventory all GeoLibre deployments and confirm none remain on versions up to 2.3.0.
Restrict outbound network access from GeoLibre hosts to only the destinations required for legitimate operation.

Patch Information

The fix is available in GeoLibre 2.4.0. Review the GeoLibre Release v2.4.0, the patch commit, and the issue tracker entry #1573 for full context. Additional advisory information is available at VulDB CVE-2026-86806.

Workarounds

Place GeoLibre behind a reverse proxy that validates and normalizes URL parameters before forwarding requests.
Block outbound requests from GeoLibre to link-local, loopback, and RFC1918 address ranges at the network layer.
In cloud environments, use IMDSv2 or equivalent metadata service protections to prevent SSRF from retrieving instance credentials.

bash

# Example egress restriction using iptables to block GeoLibre access
# to cloud metadata and internal ranges (run as the GeoLibre service user context)
iptables -A OUTPUT -m owner --uid-owner geolibre -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner geolibre -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner geolibre -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner geolibre -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner geolibre -d 192.168.0.0/16 -j REJECT