CVE-2024-23818

Executive Summary

CVE-2024-23818 is a stored cross-site scripting (XSS) vulnerability in GeoServer, an open-source Java-based server for sharing and editing geospatial data. An authenticated administrator with workspace-level privileges can inject a malicious JavaScript payload into the GeoServer catalog. This payload executes in the context of another user's browser when they view a WMS GetMap request using the OpenLayers Output Format. The vulnerability affects versions prior to 2.23.3 and 2.24.1. The CVSS score is 4.8 (Medium), and while the EPSS score is 0.0%, the risk is elevated due to the stored nature of the XSS and the default availability of the WMS OpenLayers Format. No public exploit code or Nuclei template is available at this time.

Supply Chain & Package Security

GeoServer is a Java-based application distributed as a WAR file or via Docker images. The vulnerability is in the core application code, not in a third-party package. However, administrators should verify the integrity of their GeoServer distribution by checking checksums or signatures provided by the official GeoServer project. The patch is included in versions 2.23.3 and 2.24.1, which are available from the official GeoServer website and Maven repository.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N
• Base Score: 4.8 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: High (PR:H) – requires an authenticated administrator with workspace-level privileges.
• User Interaction: Required (UI:R) – the victim must view the crafted WMS GetMap request in the OpenLayers Output Format.
• Scope: Changed (S:C) – the vulnerability can impact resources beyond the vulnerable component.
• Confidentiality Impact: Low (C:L) – limited information disclosure.
• Integrity Impact: Low (I:L) – limited modification of data.
• Availability Impact: None (A:N)

Threat Level: Medium. The requirement for authenticated administrator privileges reduces the attack surface, but the stored XSS can lead to session hijacking, data theft, or further compromise within the GeoServer environment.

Deep Dive & Mechanics

The vulnerability resides in the WMS GetMap OpenLayers Output Format. When a user requests a WMS GetMap with the format=application/openlayers parameter, GeoServer generates an HTML page containing an OpenLayers map viewer. This page includes user-controlled parameters from the request, such as layer names, styles, and other configuration options.

An authenticated administrator with workspace-level privileges can craft a malicious WMS GetMap request that includes a JavaScript payload in one of these parameters. This payload is stored in the GeoServer catalog (e.g., as a layer name or style name). When another user views the same layer or style via the OpenLayers Output Format, the payload is rendered in the HTML page without proper sanitization, leading to XSS execution.

The vulnerability is stored because the payload persists in the catalog until removed. The WMS OpenLayers Format is enabled by default, making it accessible to all users, though data and service security may limit which layers a user can view.

Vulnerable vs. Patched Code

The vulnerable code is in the org.geoserver.wms.map.OpenLayersMapOutputFormat class (or similar). The patch sanitizes user-controlled input before including it in the generated HTML.

Vulnerable Code (Conceptual):

// Vulnerable: Directly includes user input in HTML
String layerName = request.getLayerName();
String html = "<div id='map' data-layer='" + layerName + "'></div>";

Patched Code (Conceptual):

// Patched: Sanitizes user input using HTML encoding
String layerName = request.getLayerName();
String sanitizedLayerName = StringEscapeUtils.escapeHtml4(layerName);
String html = "<div id='map' data-layer='" + sanitizedLayerName + "'></div>";

The patch ensures that any user-controlled data (layer names, styles, etc.) is HTML-encoded before being placed in the response, preventing script injection.

Exploitation & Lab Setup

Red Team

Prerequisites:

• An authenticated administrator account with workspace-level privileges.
• Access to the GeoServer web interface.
• A target user who will view the crafted WMS GetMap request.

Exploitation Steps:

1. Log in to GeoServer as an administrator.
2. Create a new layer or style with a malicious name containing a JavaScript payload. For example, set the layer name to: <img src=x onerror=alert('XSS')>.
3. Save the layer/style.
4. Craft a WMS GetMap URL that uses the OpenLayers Output Format and references the malicious layer. Example:

   http://target/geoserver/wms?service=WMS&version=1.1.0&request=GetMap&layers=workspace:malicious_layer&format=application/openlayers
   

5. Send this URL to the target user (e.g., via email or social engineering).
6. When the target user opens the URL, the JavaScript payload executes in their browser.

Note: No public exploit code is available. The above steps are conceptual.

Blue Team

Detection and Response:

1. Monitor GeoServer logs for unusual WMS GetMap requests with format=application/openlayers and suspicious layer names or styles.
2. Review GeoServer catalog entries for layer or style names containing HTML or JavaScript code.
3. Implement Web Application Firewall (WAF) rules to block requests with suspicious parameters (e.g., <script>, onerror=, etc.).
4. Restrict access to the WMS OpenLayers Format to trusted users only, if possible.
5. Ensure GeoServer is updated to version 2.23.3 or 2.24.1.

Indicators of Compromise (IOCs)

• Network IOCs:
  • WMS GetMap requests with format=application/openlayers and suspicious layer names containing HTML/JavaScript.
  • Unusual HTTP responses containing embedded JavaScript in the OpenLayers HTML page.
• File IOCs:
  • GeoServer catalog entries (e.g., in data_dir/workspaces/) with layer or style names containing <script>, onerror, onload, or other event handlers.
• Log IOCs:
  • GeoServer logs showing repeated WMS GetMap requests with format=application/openlayers from a single IP.
  • Log entries indicating failed validation of layer names or styles.

Detection Engineering

YARA Rule

rule CVE_2024_23818_GeoServer_XSS {
    meta:
        description = "Detects stored XSS payloads in GeoServer catalog files"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-23818"
    strings:
        $xss_payload = /<[^>]*script[^>]*>|<[^>]*onerror[^>]*=|<[^>]*onload[^>]*=/
    condition:
        $xss_payload
}

Sigma Rule

title: GeoServer Stored XSS via WMS OpenLayers Format
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects WMS GetMap requests with format=application/openlayers and suspicious layer names
author: Valters IT
date: 2024-01-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-23818
logsource:
    category: webserver
    product: geoserver
detection:
    selection:
        cs-method: 'GET'
        cs-uri-query|contains: 'format=application/openlayers'
        cs-uri-query|contains|all:
            - 'layers='
            - '<script>'
            - 'onerror='
    condition: selection
falsepositives:
    - Legitimate use of special characters in layer names (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-23818 GeoServer Stored XSS via WMS OpenLayers Format";
    flow:to_server,established;
    content:"GET";
    http_method;
    content:"format=application/openlayers";
    http_uri;
    content:"layers=";
    http_uri;
    pcre:"/layers=.*<[^>]*script[^>]*>|layers=.*onerror=|layers=.*onload=/Ui";
    classtype:web-application-attack;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade GeoServer to version 2.23.3 or 2.24.1.
2. If upgrade is not immediately possible, disable the WMS OpenLayers Output Format by removing or commenting out the relevant configuration in web.xml or the GeoServer configuration files.
3. Review and sanitize all existing layer and style names in the GeoServer catalog for any suspicious content.

Long-term Mitigations:

• Implement strict input validation and output encoding for all user-controlled data in GeoServer.
• Use a Web Application Firewall (WAF) to filter malicious requests.
• Regularly audit GeoServer configurations and catalog entries.
• Follow the principle of least privilege for GeoServer administrator accounts.

Valters IT Signature

This report was generated by Valters IT DevSecOps & CTI Expert System.
For further analysis, contact Valters IT.