CVE-2024-38524
Executive Summary
CVE-2024-38524 is an information disclosure vulnerability in GeoServer, an open-source server for sharing geospatial data. The vulnerability resides in the org.geowebcache.GeoWebCacheDispatcher.handleFrontPage method, which fails to properly restrict access to sensitive storage location information. By default, this information is exposed to any user who can access the front page, potentially revealing internal system paths and configurations. The vulnerability has a CVSS score of 5.3 (Medium) and is fixed in GeoServer versions 2.25.6 and 2.26.2. No public proof-of-concept (PoC) or exploit code is currently available, and the EPSS score is 0.0%, indicating a low probability of exploitation in the wild.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
GeoServer is a Java-based application typically deployed as a WAR file in servlet containers like Apache Tomcat or Jetty. This vulnerability does not directly affect the software supply chain (e.g., NPM, PyPI, Go, Ruby packages), but it does impact the security posture of deployments. Organizations using GeoServer should verify their version and apply the patch as soon as possible to prevent information leakage.
CVSS Breakdown & Threat Level
- CVSS Score: 5.3 (Medium)
- Attack Vector: Network (AV:N)
- Attack Complexity: Low (AC:L)
- Privileges Required: None (PR:N)
- User Interaction: None (UI:N)
- Scope: Unchanged (S:U)
- Confidentiality Impact: Low (C:L)
- Integrity Impact: None (I:N)
- Availability Impact: None (A:N)
The threat level is considered Medium due to the low complexity and lack of required privileges, but the impact is limited to information disclosure. The vulnerability could be used by attackers to gather intelligence about the server's file system structure, which might aid in further attacks.
Deep Dive & Mechanics
The vulnerability is located in the GeoWebCacheDispatcher.handleFrontPage method. This method is responsible for rendering the front page of the GeoWebCache interface. The issue is that it includes storage location information (e.g., file system paths) in the response without any access control checks. A hidden system property exists to suppress this information, but it is not enabled by default.
The root cause is a missing authorization check. The method does not verify whether the requesting user should have access to this sensitive information. As a result, any unauthenticated user can view the storage locations by simply accessing the front page.
The fix involves modifying the handleFrontPage method to check for a system property (e.g., GEOWEBCACHE_HIDE_STORAGE_LOCATIONS) and only display the storage locations if that property is explicitly set to false or not set. In the patched versions, the default behavior is to hide the storage locations.
Vulnerable vs. Patched Code
Vulnerable Code (simplified):
public void handleFrontPage(HttpServletRequest request, HttpServletResponse response) {
// ... other code ...
String storageLocations = getStorageLocations(); // Always returns paths
response.getWriter().write("Storage locations: " + storageLocations);
// ... other code ...
}
Patched Code (simplified):
public void handleFrontPage(HttpServletRequest request, HttpServletResponse response) {
// ... other code ...
String hideStorage = System.getProperty("GEOWEBCACHE_HIDE_STORAGE_LOCATIONS", "false");
if (!"true".equalsIgnoreCase(hideStorage)) {
String storageLocations = getStorageLocations();
response.getWriter().write("Storage locations: " + storageLocations);
}
// ... other code ...
}
The patched version introduces a check for the system property GEOWEBCACHE_HIDE_STORAGE_LOCATIONS. If this property is set to true, the storage locations are not displayed. The default behavior in the patch is to hide the information (by checking if the property is not true).
Exploitation & Lab Setup
Red Team
Since no public exploit code is available, exploitation would involve manually crafting an HTTP request to the GeoServer front page. The following is a conceptual example using curl:
curl -v http://target:8080/geoserver/web/
If the server is vulnerable, the response will contain storage location paths. An attacker could then use this information to identify potential file inclusion or path traversal vulnerabilities.
Lab Setup:
- Deploy a vulnerable GeoServer version (e.g., 2.25.5) using Docker:
docker run -d -p 8080:8080 --name geoserver-vuln geoserver/geoserver:2.25.5 - Access the front page and observe the storage location disclosure.
- Upgrade to a patched version (e.g., 2.25.6) and verify the information is no longer exposed.
Blue Team
Detection:
- Monitor for requests to the GeoServer front page (
/geoserver/web/) from unauthenticated users. - Look for responses containing file system paths (e.g.,
/var/geoserver/data,C:\GeoServer\data).
Hunting:
- Search logs for unusual patterns in the response body, such as
Storage locations:. - Use the following Sigma rule to detect potential exploitation attempts.
Indicators of Compromise (IOCs)
- Network: HTTP requests to
/geoserver/web/or/geowebcache/from unknown IPs. - Response Body: Presence of strings like
Storage locations:,/var/geoserver/, orC:\GeoServer\in the HTTP response. - Logs: Access logs showing
GET /geoserver/web/with a 200 status code.
Detection Engineering
YARA Rule
rule CVE_2024_38524_GeoServer_InfoDisclosure {
meta:
description = "Detects GeoServer responses containing storage location information"
author = "Valters IT"
date = "2025-04-17"
reference = "CVE-2024-38524"
strings:
$s1 = "Storage locations:" ascii wide nocase
$s2 = "/var/geoserver" ascii wide nocase
$s3 = "C:\\GeoServer" ascii wide nocase
condition:
any of them
}
Sigma Rule
title: GeoServer Storage Location Disclosure
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP responses from GeoServer that may indicate CVE-2024-38524 exploitation
author: Valters IT
date: 2025-04-17
references:
- https://nvd.nist.gov/vuln/detail/CVE-2024-38524
logsource:
category: webserver
product: apache
service: http
detection:
selection:
cs-uri-query|contains:
- "/geoserver/web/"
- "/geowebcache/"
sc-status: 200
cs-content-type: "text/html"
response_body|contains: "Storage locations:"
condition: selection
falsepositives:
- Legitimate administrative access
level: medium
Suricata Rule
alert http any any -> any any (msg:"CVE-2024-38524 GeoServer Storage Location Disclosure"; flow:to_server,established; content:"GET"; http_method; content:"/geoserver/web/"; http_uri; content:"Storage locations:"; http_server_body; classtype:attempted-recon; sid:1000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Upgrade GeoServer to version 2.25.6 or 2.26.2 (or later).
- If immediate upgrade is not possible, set the system property
GEOWEBCACHE_HIDE_STORAGE_LOCATIONS=truein the Java startup parameters (e.g.,-DGEOWEBCACHE_HIDE_STORAGE_LOCATIONS=true). - Restrict network access to the GeoServer web interface using a firewall or reverse proxy.
Long-term Mitigations:
- Implement a Web Application Firewall (WAF) to block requests to sensitive endpoints.
- Regularly audit GeoServer configurations and apply security patches.
- Use network segmentation to limit exposure of GeoServer to untrusted networks.
Valters IT signature: Valters IT Senior DevSecOps Engineer