CVE-2022-39359

Executive Summary

CVE-2022-39359 is a server-side request forgery (SSRF) vulnerability in Metabase, an open-source business intelligence and data visualization platform. The flaw exists in the custom GeoJSON map URL validation logic, which fails to prevent the application from following HTTP redirects to disallowed addresses such as link-local or private-network targets. An attacker able to configure a custom GeoJSON map URL could leverage this weakness to access internal network resources that should be unreachable from the public internet. The issue affects all Metabase versions prior to 0.44.5, 1.44.5, 0.43.7, 1.43.7, 0.42.6, 1.42.6, 0.41.9, and 1.41.9, and has been patched in these release lines.

Technical Analysis

Metabase is data visualization software that allows users to create dashboards, charts, and maps from various data sources. One of its features permits users to supply custom GeoJSON map URLs to render geographic data on interactive maps. This feature enforces a security control that is intended to prevent the server from making requests to certain restricted address classes, including link-local (e.g., 169.254.0.0/16) and private-network (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) ranges.

According to the NVD description, prior to the patched versions, the custom GeoJSON map URL validation would "follow redirects to addresses that were otherwise disallowed." This indicates that the access control mechanism performed a check on the initial URL supplied by the user, but when an HTTP redirect (e.g., 301, 302, 303, 307) was returned by the target server, the redirect target was not subjected to the same validation. This is a classic SSRF bypass pattern: the validation logic is applied at the input stage rather than on every subsequent request made during the redirect chain.

The attack mechanism is straightforward:

1. The user (or attacker) specifies a custom GeoJSON map URL that points to an initially allowed address (e.g., a public domain the attacker controls).
2. The attacker's server responds with a redirect to an internal address, such as http://169.254.169.254/latest/meta-data/ (cloud metadata endpoint) or http://192.168.1.1/.
3. Metabase follows the redirect and fetches the internal resource, then displays the content (or error messages) to the user — leaking internal data or enabling further reconnaissance.

The issue is not limited to cloud metadata services; it also permits access to internal HTTP services on the private network where the Metabase instance is deployed. The NVD description explicitly mentions "link-local or private-network" addresses as the restricted targets.

The patch takes two actions:

1. Redirect disabling: Metabase no longer follows redirects on GeoJSON map URLs. This closes the SSRF bypass at the network layer.
2. Feature kill switch: An environment variable MB_CUSTOM_GEOJSON_ENABLED was added, which disables the custom GeoJSON feature entirely when set to false (the default is true, preserving backward compatibility).

From a code-level perspective, the vulnerability is in the URL validation routine for custom GeoJSON map URLs. Prior to the patch, the validation was likely performed using a URL parsing function that checked the hostname/IP of the initial URL but did not recursively validate redirect locations. The patched version either removes the redirect-following behavior entirely or adds recursive validation — the NVD description indicates the former approach was chosen.

The CVSS score of 6.5 (Medium) reflects the network attack vector, low attack complexity, no privileges or user interaction required, and an impact that is limited to confidentiality and integrity but not availability.

Exploitation Scenarios

Note: No public PoC or exploit code has been identified for this vulnerability. The attack chain described below is inferred from the vulnerability class (SSRF via redirect bypass) and the NVD description.

1. Reconnaissance / Target Identification

An attacker first identifies a Metabase instance that is publicly accessible and running a version prior to the fixed releases (0.44.5, 1.44.5, 0.43.7, 1.43.7, 0.42.6, 1.42.6, 0.41.9, 1.41.9). The attacker may fingerprint the application by observing Metabase-specific login pages, error messages, or by probing the API. The custom GeoJSON feature is a core dashboard functionality, so no special configuration is required beyond having access to the dashboard creation or editing interface.

2. Triggering the Flaw

The attacker creates or modifies a dashboard map visualization and supplies a custom GeoJSON map URL. The URL initially points to an attacker-controlled server. Metabase's validation logic checks this URL against its blocklist (link-local, private-network ranges) — the initial URL passes the check because it is a public address.

3. Payload / Execution Method

The attacker's server is configured to respond to the GeoJSON fetch request with an HTTP redirect (e.g., HTTP 302) pointing to a disallowed internal target. Example internal targets:

• Cloud metadata services: http://169.254.169.254/latest/meta-data/ (AWS, GCP, Azure)
• Internal web services: http://10.0.0.5:8080/, http://192.168.1.1/admin/
• Link-local services: http://169.254.169.254/computeMetadata/v1/ (GCP)

Metabase's vulnerable code follows the redirect without re-validating the destination address, thereby fetching the internal resource. The response body is then rendered or exposed through the map visualization, leaking the internal data.

4. Post-Exploitation Impact

The attacker can:

• Extract cloud instance metadata: This may contain IAM temporary credentials, instance ID, security group details, and more.
• Scan internal network services: The attacker can probe internal IPs and ports by iterating through redirect targets, potentially identifying services like internal dashboards, admin panels, databases, or other applications.
• Exfiltrate sensitive data: If the internal service returns data (e.g., configuration files, API responses), that data may be visible in the Metabase UI or obtainable via timing/error-based side channels.

The attack requires the attacker to have an account with permission to create or edit dashboards. Metabase's default installation grants this to admin users, and in many deployments the default credentials (admin@metabase.com / metabase1) are not changed, further lowering the barrier to exploitation.

Impact Assessment

CVSS Score: 6.5 (Medium) — The vector reflects an unauthenticated network attack (AV:N/AC:L/PR:N/UI:N) with impacts on confidentiality and integrity (C:L/I:L/A:N). However, note that while the CVSS vector suggests no privileges are required, practical exploitation requires the ability to create or modify a dashboard containing a custom GeoJSON map — this typically requires an authenticated session with at least editor-level privileges. The CVSS scoring likely assumes default Metabase installation where the initial admin user is created on first run and may be left with default credentials.

Business Impact:

• Data breach: The most severe impact is the exfiltration of cloud metadata (potentially including IAM credentials) or internal service data.
• Internal network reconnaissance: The SSRF primitive effectively turns the Metabase server into a proxy for internal HTTP requests, enabling an attacker to map the internal network and identify additional attack surfaces.
• Pivot point: Compromised internal service data can be used to attack other internal systems, turning the Metabase server into a foothold for lateral movement.

Affected Systems: All Metabase deployments using versions prior to the patched releases. This includes both Open Source (0.x line) and Enterprise (1.x line) editions. The vulnerability is relevant across all deployment models: self-hosted packages, Docker containers, and cloud marketplace images.

Blast Radius: The blast radius is constrained by the network reachability of the Metabase server. In a typical deployment where Metabase is hosted in a cloud VPC alongside other services, the SSRF can reach all internal HTTP endpoints. If the Metabase server has access to the cloud metadata service (which it typically does on AWS EC2, GCP, or Azure VMs), the cloud instance IAM credentials are exposed.

Exploitation likelihood: The EPSS score is 0.00582 (44.8th percentile), indicating a relatively low probability of exploitation in the wild. No CISA KEV listing and no known exploit code have been published. However, SSRF is a well-understood vulnerability class, and the attack requires only a redirecting web server, so exploitation is well within the capabilities of a moderately skilled attacker.

Detection Guidance

General guidance for detection: Monitor for Metabase server requests to unexpected internal IP addresses (169.254.x.x, 10.x.x.x, 172.16-31.x.x, 192.168.x.x) originating from the Metabase process. Also monitor for outbound HTTP redirect chains that end at internal addresses. The following rules target these detection opportunities.

Sigma Rule

title: Metabase SSRF via GeoJSON Redirect (CVE-2022-39359)
id: 534dc3bf-0f5f-4ae3-8e10-6ef7b37497b1
status: experimental
description: Detects Metabase server-side requests to internal network addresses via custom GeoJSON map URL redirects. This rule targets HTTP responses to Metabase that are redirects (3xx) to RFC1918 or link-local addresses.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2022-39359
tags:
    - attack.t1190
    - attack.tactic.initial-access
    - cve.2022-39359
logsource:
    category: webserver
    product: metabase
    definition: 'Web server or proxy logs capturing Metabase HTTP traffic. Look for requests to Metabase endpoints that serve custom GeoJSON content.'
detection:
    selection_redirect_status:
        cs-method: GET
        sc-status:
            - 301
            - 302
            - 303
            - 307
            - 308
    selection_location_header:
        cs-uri-query|contains:
            - 'geojson'
            - 'map'
    selection_internal_destination:
        cs-host|startswith:
            - '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.'
            - '169.254.'
    condition: selection_redirect_status and selection_location_header and selection_internal_destination
    falsepositives:
        - 'Legitimate internal GeoJSON sources if allowed by policy before patch. Very unlikely in practice as internal URLs were blocked.'
level: high

YARA Rule

rule CVE_2022_39359_Metabase_GeoJSON_SSRF {
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects Metabase configuration or log artifacts referencing custom GeoJSON URLs with redirect patterns indicating SSRF exploitation attempts."
        cve = "CVE-2022-39359"
        date = "2025-01-01"
        threat_level = "medium"
    strings:
        $a = "MB_CUSTOM_GEOJSON_ENABLED" ascii wide nocase
        $b = "geoJSON" ascii wide nocase
        $c = "customGeoJSON" ascii wide nocase
        $d = "map_url" ascii wide nocase
        $e = "redirect" ascii wide nocase
        $f = "169.254" ascii wide
        $g = "10." ascii wide
        $h = "192.168." ascii wide
        $i = "172.1" ascii wide
    condition:
        // Configuration files showing disabled feature
        (uint16(0) == 0x5B7B or uint16(0) == 0x3C21) and any of ($a, $b, $c, $d) and any of ($e)
        // Logs containing internal URL references after redirect
        or (any of ($b, $c) and any of ($f, $g, $h, $i))
}

Suricata IDS Rule

alert http any any -> $METABASE_SERVERS any (msg:"CVE-2022-39359 - Metabase GeoJSON SSRF Redirect to Internal Network"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"geojson"; nocase; http.response; status; content:"!302"; http.response; status; content:"!301"; http.location; content:"169.254."; http.location; content:"10."; http.location; content:"192.168."; http.location; content:"172.16."; http.location; content:"172.31."; classtype:attempted-recon; sid:202239359; rev:1; metadata:created_at 2025_01_01, updated_at 2025_01_01, cve CVE-2022-39359, mitre_tactic TA0001, mitre_technique T1190;)

Elastic Detection

// Elastic EQL query to detect Metabase SSRF attempts via redirect to internal networks
sequence by process.entity_id with maxspan=5s
  [ network where event.action == "connection_attempted" and
    process.name == "java" and
    destination.ip : ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "169.254.0.0/16") and
    destination.port == "80" or destination.port == "443" ]
  [ http where event.action == "response" and
    http.response.status_code in (301, 302, 303, 307, 308) and
    http.request.referrer == "customGeoJSON" ]

Splunk SPL Query

index=proxy OR index=web
  sourcetype=*metabase*
  (status_code=301 OR status_code=302 OR status_code=303 OR status_code=307 OR status_code=308)
  (uri="*geojson*" OR uri="*map*")
  (dest_ip="10.*" OR dest_ip="172.16.*" OR dest_ip="172.17.*" OR dest_ip="172.18.*" OR
   dest_ip="172.19.*" OR dest_ip="172.20.*" OR dest_ip="172.21.*" OR dest_ip="172.22.*" OR
   dest_ip="172.23.*" OR dest_ip="172.24.*" OR dest_ip="172.25.*" OR dest_ip="172.26.*" OR
   dest_ip="172.27.*" OR dest_ip="172.28.*" OR dest_ip="172.29.*" OR dest_ip="172.30.*" OR
   dest_ip="172.31.*" OR dest_ip="192.168.*" OR dest_ip="169.254.*")
  OR (src_ip IN ($METABASE_SERVERS$) AND dest_ip IN (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16))
  | table _time, src_ip, dest_ip, uri, status_code, http_referrer
  | sort - _time

Wazuh OSSEC Rule

<rule id="202238" level="12">
  <decoded_as>json</decoded_as>
  <field name="url">\.geojson|geojson|map_url</field>
  <field name="status">301|302|303|307|308</field>
  <field name="dstip">^10\.|^172\.(1[6-9]|2[0-9]|3[01])\.|^192\.168\.|^169\.254\.</field>
  <description>Metabase SSRF attempt via GeoJSON redirect to internal network (CVE-2022-39359)</description>
  <group>ssrf,metabase,cve_2022_39359,</group>
  <mitre>
    <id>T1190</id>
  </mitre>
</rule>

Mitigation & Patch Guidance

Patch confidence: 3/4 (LIKELY) — two independent sources (CNA and OSV) confirm the fix.

This vulnerability is confirmed patched in the following release lines:

• 0.x line (Open Source): 0.44.5, 0.43.7, 0.42.6, 0.41.9
• 1.x line (Enterprise/paid): 1.44.5, 1.43.7, 1.42.6, 1.41.9

1. Immediate Mitigations (until patch can be applied)

• Disable the custom GeoJSON feature by setting the environment variable MB_CUSTOM_GEOJSON_ENABLED=false on the Metabase server. This completely removes the attack surface regardless of the Metabase version. According to the NVD description, this variable was added in the patched versions, so if you are running an unpatched version, verify whether this variable is honored; if not, proceed directly to patching.
• Restrict outbound network access at the firewall/host level. Block Metabase server egress to private IP ranges (RFC1918) and link-local addresses (169.254.0.0/16) that are not required for legitimate operational purposes. Cloud metadata endpoints (169.254.169.254) should be specifically blocked from any non-essential processes.
• Enforce strong authentication on the Metabase instance. Ensure the default admin account (admin@metabase.com) has been changed, and force multi-factor authentication for administrative users.
• Review existing dashboard configurations: audit all existing map visualizations for any user-supplied custom GeoJSON URLs and remove any that point to unexpected or external destinations.

2. Patch / Upgrade Steps

• Upgrade to the earliest patched version corresponding to your release line:
  • For Open Source (0.x): upgrade to 0.44.5 or later (or the respective patched minor: 0.43.7, 0.42.6, 0.41.9).
  • For Enterprise (1.x): upgrade to 1.44.5 or later (or 1.43.7, 1.42.6, 1.41.9).
• Follow the official Metabase upgrade documentation for your deployment method (JAR, Docker image, Debian package, or AWS AMI). Back up the application database before applying the upgrade.
• After upgrade, verify the fix by testing that custom GeoJSON URLs that return redirects to internal addresses are no longer followed.

3. Long-Term Hardening

• Maintain up-to-date versions: subscribe to Metabase security advisories and establish a patch management SLA for the application.
• Network segmentation: place Metabase in a demilitarized zone (DMZ) or dedicated segment with restrictive outbound firewall rules. Do not allow the Metabase server to reach internal administrative networks or the cloud metadata service unless absolutely required.
• Monitoring: enable outbound HTTP request logging on the Metabase server and monitor for any requests to internal IP ranges. Configure alerts for SSRF-like patterns.
• Least privilege: limit which users can create or edit dashboards. Apply the principle of least privilege — only allow trusted users to configure map visualizations.
• Environmental control: use the MB_CUSTOM_GEOJSON_ENABLED variable to disable the custom GeoJSON feature if it is not essential to your dashboards — even post-patch, reducing the attack surface is always beneficial.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-39359
2. CNA/OSV Advisory: OSV entry for CVE-2022-39359 (packages referenced: Metabase, commit hashes: c529fe2f7a6be48354fedd8f36c940b787bafa2d, de1264e1b2c3516181a3e115803abe32b74a1b7b, ee686fcfe5a006e228090a150365d4495bbb549c)
3. Metabase Security Advisory: Refer to Metabase's official release notes for versions 0.44.5, 1.44.5, 0.43.7, 1.43.7, 0.42.6, 1.42.6, 0.41.9, 1.41.9 (available at metabase.com/releases)
4. CWE-918 (Server-Side Request Forgery): https://cwe.mitre.org/data/definitions/918.html
5. CISA KEV: Not listed — no evidence of exploitation in the wild as of this writing.

Threat actor campaigns: No known threat actor campaigns or exploit-in-the-wild evidence for CVE-2022-39359 at the time of this report. The EPSS score of 0.00582 (44.8th percentile) suggests low exploitation likelihood in the broader ecosystem. However, SSRF vulnerabilities in BI/dashboard platforms are frequently targeted in both automated scanning and targeted intrusion campaigns, especially when the affected application hosts sensitive cloud credentials — Metabase instances remain a relevant target for initial access brokers.