☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 5.3 🐛 CWE-200
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2024-38524

CVE-2024-38524 Information Disclosure in Geoserver
📅 PUBLISHED: 2025-06-10 14:43 UTC 🔄 UPDATED: 2026-09-23 20:31 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.44%
👁️
0.44% probability
11.0× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
5.3
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

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.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

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.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
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:

  1. 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
    
  2. Access the front page and observe the storage location disclosure.
  3. 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/, or C:\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:

  1. Upgrade GeoServer to version 2.25.6 or 2.26.2 (or later).
  2. If immediate upgrade is not possible, set the system property GEOWEBCACHE_HIDE_STORAGE_LOCATIONS=true in the Java startup parameters (e.g., -DGEOWEBCACHE_HIDE_STORAGE_LOCATIONS=true).
  3. 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

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-38524/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.