CVE-2025-30371

Executive Summary

CVE-2025-30371 is a server-side request forgery (SSRF) vulnerability in Metabase, a popular business intelligence and embedded analytics tool. The flaw resides in the GeoJson endpoint, where insufficient validation of local link access allows an attacker to bypass protection mechanisms. This can lead to unauthorized access to internal resources if Metabase is colocated with other unsecured services. The vulnerability affects self-hosted instances using the GeoJson feature. Patches are available in versions v0.52.16.4, v1.52.16.4, v0.53.8, and v1.53.8. A workaround involves migrating to Metabase Cloud or redeploying in a dedicated subnet with strict outbound port controls.

Supply Chain & Package Security

Metabase is distributed as a Java JAR file and via Docker images. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the core application. Users should verify the integrity of their Metabase distribution by checking checksums provided by the vendor. The patch is applied to the source code and released as new versions.

CVSS Breakdown & Threat Level

The CVSS score is not provided in the NVD data. However, based on the description, the vulnerability is a SSRF with potential for internal network reconnaissance and access to unsecured resources. The attack vector is network-based, requires low complexity, and no privileges. User interaction is not required. The impact on confidentiality and availability is low, but integrity impact is none. A reasonable CVSS vector would be:

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
• Base Score: 5.4 (Medium)
• Threat Level: Medium

Deep Dive & Mechanics

The GeoJson endpoint in Metabase allows users to load geographic data from external URLs. The vulnerability arises because the endpoint does not properly validate whether the provided URL points to a local or internal resource. An attacker can craft a request that makes the Metabase server fetch a URL like http://localhost:8080/admin or http://192.168.1.1/secret, bypassing the intended protection against local link access.

The core issue is a lack of proper URL validation and filtering. The application should check if the host part of the URL resolves to a private IP range (e.g., 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and block such requests. The patch likely adds such validation.

Vulnerable vs. Patched Code

The vulnerable code likely resides in the GeoJson endpoint handler. A simplified example:

Vulnerable Code (Java-like pseudocode):

public void loadGeoJson(String url) {
    // No validation of URL
    URL geoUrl = new URL(url);
    HttpURLConnection conn = (HttpURLConnection) geoUrl.openConnection();
    // Fetch and process data
}

Patched Code:

public void loadGeoJson(String url) {
    URL geoUrl = new URL(url);
    InetAddress address = InetAddress.getByName(geoUrl.getHost());
    if (address.isSiteLocalAddress() || address.isLoopbackAddress()) {
        throw new SecurityException("Local addresses are not allowed");
    }
    HttpURLConnection conn = (HttpURLConnection) geoUrl.openConnection();
    // Fetch and process data
}

The patch adds a check to reject requests to private or loopback IP addresses.

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker would send a crafted request to the Metabase GeoJson endpoint with a URL pointing to an internal resource.

Example Exploit Request:

POST /api/geo-json HTTP/1.1
Host: target-metabase.com
Content-Type: application/json

{
  "url": "http://127.0.0.1:8080/admin"
}

Lab Setup:

1. Deploy a vulnerable Metabase instance (e.g., v0.52.16.3) using Docker.
2. Set up a simple HTTP server on the same host to simulate an internal service.
3. Send the exploit request using curl or Burp Suite.
4. Observe that the Metabase server fetches the internal resource and returns its content.

Blue Team

To detect exploitation attempts, monitor for unusual requests to the GeoJson endpoint with suspicious URLs.

Detection Steps:

1. Enable logging on the Metabase server.
2. Monitor logs for requests to /api/geo-json with URLs containing private IP addresses or localhost.
3. Use network monitoring to detect outbound connections from the Metabase server to internal IPs.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests from Metabase server to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8).
  • Requests to /api/geo-json with URLs containing localhost, 127.0.0.1, or internal IPs.
• File IOCs:
  • Unusual log entries in Metabase logs showing internal IP addresses.
• Behavioral IOCs:
  • Unexpected access to internal services from the Metabase server.

Detection Engineering

YARA Rule

rule CVE_2025_30371_GeoJson_SSRF {
    meta:
        description = "Detects SSRF attempts against Metabase GeoJson endpoint"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-30371"
    strings:
        $url_pattern = /(http|https):\/\/(127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3})/
    condition:
        $url_pattern
}

Sigma Rule

title: Metabase GeoJson SSRF Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2025-30371 by sending requests to internal IPs via GeoJson endpoint
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: metabase
detection:
    selection:
        cs-uri-query|contains: "/api/geo-json"
        cs-uri-query|contains:
            - "127.0.0.1"
            - "localhost"
            - "10."
            - "172.16."
            - "172.17."
            - "172.18."
            - "172.19."
            - "172.20."
            - "172.21."
            - "172.22."
            - "172.23."
            - "172.24."
            - "172.25."
            - "172.26."
            - "172.27."
            - "172.28."
            - "172.29."
            - "172.30."
            - "172.31."
            - "192.168."
    condition: selection
falsepositives:
    - Legitimate use of GeoJson with internal resources (if allowed)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-30371 Metabase GeoJson SSRF Attempt"; flow:to_server; content:"/api/geo-json"; http_uri; pcre:"/(127\.0\.0\.1|localhost|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3})/Ri"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Metabase to v0.52.16.4, v1.52.16.4, v0.53.8, or v1.53.8.
2. If upgrade is not possible, migrate to Metabase Cloud.
3. Redeploy Metabase in a dedicated subnet with strict outbound port controls.

Long-term Measures:

• Implement network segmentation to isolate Metabase from other internal services.
• Use a web application firewall (WAF) to block requests to internal IPs.
• Regularly review and update URL validation logic in custom integrations.

Workaround:

• Restrict outbound traffic from the Metabase server to only necessary external services using firewall rules.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert