pygeoapi CVE-2026-42352
HIGHSeverity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Unauthenticated network SSRF (PR:N, AV:N, AC:L) with scope change to internal systems; confidentiality set to Low because the subscriber path is blind POST notification, not response-returning.
Primary rating from Vendor (https://github.com/geopython/pygeoapi).
CVSS VectorVendor: https://github.com/geopython/pygeoapi
Lifecycle Timeline
4DescriptionCVE.org
Impact
OGC API - Process execution requests can use the subscriber object to requests to internal HTTP services.
Patches
The issue has been patched in master branch and made available as part of the 0.23.3 release. The patch disables any HTTP requests made to internal resources by default (unless explicitly defined in configuration by a new allow_internal_requests directive.
The commit/fix can be found in 3a63f5b0cc6275e3ae0edb47726b13a43cdd90ef.
Workarounds
Users can update existing applications by disabling process based resources in their pygeoapi config, until 0.23.3 can be installed and deployed.
AnalysisAI
Server-side request forgery in pygeoapi 0.23.0 through 0.23.2 lets remote unauthenticated attackers coerce the server into issuing HTTP requests to internal, loopback, and link-local resources by supplying a crafted subscriber object (in_progress/success/failed URIs) in an OGC API - Processes execution request. Rated CVSS 8.6 (CWE-918), it is fixed in 0.23.3, which blocks internal-target requests by default. EPSS is low (0.04%, 14th percentile) and there is no public exploit identified at time of analysis.
Technical ContextAI
pygeoapi is a Python (pip-installed) reference implementation of the OGC API suite for geospatial data services. The flaw lives in the Processes job-notification workflow: when a process job runs, the manager (pygeoapi/process/manager/base.py) previously performed unvalidated requests.post() calls to the subscriber-supplied in_progress_uri, success_uri, and failed_uri. Because those URLs come directly from the client-controlled subscriber object and were never checked against internal address ranges, an attacker controls the destination of a server-originated request - the textbook CWE-918 SSRF pattern. The fix introduces a is_request_allowed() helper in pygeoapi/util.py that resolves the hostname via socket.gethostbyname and rejects RFC1918/private/loopback/link-local IPs unless the new per-process allow_internal_requests directive is explicitly set to True.
RemediationAI
Upgrade pygeoapi to 0.23.3 or later (Vendor-released patch: 0.23.3), which disables server-side HTTP requests to internal/loopback/link-local ranges by default and only permits them when the new per-process allow_internal_requests: True directive is set - leave that directive unset/False in production. If you cannot upgrade immediately, the vendor-recommended workaround is to disable process-based resources in the pygeoapi configuration until 0.23.3 is deployed, which stops the vulnerable subscriber-notification code path at the cost of losing OGC API - Processes functionality. As a network-layer compensating control, place egress filtering in front of the pygeoapi host to block outbound access to RFC1918, loopback, and cloud metadata endpoints (e.g. 169.254.169.254), noting this may break legitimate internal integrations the service relies on. Reference the advisory at https://github.com/geopython/pygeoapi/security/advisories/GHSA-jgvc-94c8-3chc.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-jgvc-94c8-3chc