Metabase by metabase: custom GeoJSON URL validation bypass enables SSRF

Metabase through 0.63.18 fails to properly validate the unspecified address 0.0.0.0 in custom GeoJSON URLs, allowing unauthenticated attackers to reach loopback services. Attackers can save a malicious GeoJSON entry with 0.0.0.0 and trigger requests that return loopback service responses to unauthenticated callers.

• metabase Metabase: the default status is unaffected, but versions from 0 through 0.63.18, inclusive, are marked affected under semantic versioning.
• No additional parallel release branch is identified in the record.
• The patch_available field indicates that a patch exists, but the evidence does not identify an exact fixed release.
• Do not infer that every release after the affected boundary is safe without verifying each release branch.

The flaw is in Metabase's custom GeoJSON retrieval flow. The non-link-local-dns-resolver checks for link-local addresses, while url->geojson performs an HTTP request to the configured URL, allowing the unspecified address 0.0.0.0 to bypass the existing validation. The technical analysis reports that, on Linux, connections to 0.0.0.0 can be delivered to the loopback interface, causing a request from the Metabase host to reach a local service. The GET /api/geojson/:key endpoint uses read-url-and-respond to read and return the saved URL content, so a loopback service response can be relayed to an unauthenticated caller. The attack path requires an account with high privileges, or equivalent access, to save a malicious custom GeoJSON entry, but the request that triggers retrieval can be sent by an unauthenticated caller. The available evidence does not fully establish the authorization model for every configuration-write path or customized deployment.

• The flaw is reachable over the network through the custom GeoJSON URL functionality.
• An attacker needs high privileges, or equivalent access, to save a malicious entry, so the complete attack chain is not anonymous end to end.
• After an entry has been saved, an unauthenticated caller can trigger Metabase to retrieve the configured URL.
• Public technical material describes using 0.0.0.0 to reach a loopback service and return its response to the caller; public reproduction material is available.
• The supplied record does not establish whether the flaw has been exploited in the wild.

The technical outcome is that Metabase can make a server-side request to a loopback service and expose the response through the GeoJSON API. This may disclose information within the network reach of the Metabase host, but the amount and sensitivity of exposed data depend on the services present and the deployment's network namespace.

The attacker needs high privileges to create or change the malicious entry, while the response-retrieval step may not require authentication. The record does not establish arbitrary writes, code execution, or service disruption; the confirmed consequence is focused on confidentiality.

The flaw can expose data returned by services that are reachable only through the loopback interface of the Metabase host. If those internal services return sensitive information, credentials, or administrative data, relaying the response to a caller could create a confidentiality breach or enable internal reconnaissance; these are possible consequences, not specific assets confirmed by the record.

Operational impact depends on which services listen on the host or Metabase network namespace and on the permissions available to the Metabase process. The record describes a primary confidentiality impact and does not establish data modification or service disruption.

1. Apply the metabase vendor patch for the deployed release branch first. The record confirms that a patch is available but does not name an exact fixed release, so obtain and verify the fixed release through the vendor or CNA release process before upgrading.
2. Until the upgrade is complete, review and remove unnecessary custom GeoJSON entries, especially entries targeting 0.0.0.0, loopback, or internal networks. Treat this as containment, not a substitute for patching.
3. If the business function permits, temporarily disable custom GeoJSON URL retrieval or restrict Metabase egress so it cannot reach loopback and unnecessary internal network ranges.
4. Review configuration changes made by high-privilege accounts and assess whether suspicious GeoJSON responses were returned to unauthenticated callers. If exposure is suspected, handle credentials or other secrets that may have appeared in responses through the incident response process.
5. After upgrading, verify through inventory and defensive testing that URLs using unspecified addresses are rejected, and reassess every release branch in use.

1. Inventory every Metabase instance and compare its version with the affected scope in the record.
2. Inspect custom GeoJSON configuration, especially URLs containing 0.0.0.0, loopback addresses, or unexpected internal destinations.
3. Review access to GET /api/geojson/:key and changes to custom GeoJSON settings. If audit logging is available, correlate configuration changes with the identities and times of subsequent requests.
4. Monitor outbound connections created by the Metabase process to the loopback interface or internal ports that are not expected for the deployment. This is precautionary monitoring, not a confirmed CVE-specific indicator.
5. Do not treat an absence of matching log evidence as proof that an instance is safe; combine version, configuration, and network review.