CVE-2022-39358

Executive Summary

CVE-2022-39358 is a security vulnerability in Metabase, an open-source data visualization and business intelligence platform. The flaw allows an unauthenticated attacker to circumvent the "Locked" parameter protection in Signed Embeddings — a feature designed to restrict what data embedded dashboards can query. By constructing malicious backend requests, an attacker can bypass these locked parameter constraints on publicly accessible embedded dashboards, potentially accessing or manipulating data beyond intended scope. The vulnerability affects Metabase versions prior to 0.44.5, 1.44.5, 0.43.7, 1.43.7, 0.42.6, and 1.42.6 across both the open-source (0.x) and enterprise (1.x) release lines. Patches were released in the versions listed above, and public exploit code is not currently known.

Technical Analysis

Metabase's Signed Embedding feature allows organizations to embed dashboards and questions into public or semi-public web pages using a cryptographically signed JWT token. Part of the embedding configuration includes the ability to mark dashboard parameters (filters) as "Locked," which constrains the values that an embedding consumer can supply. This is a critical security control: it ties the embedded dashboard to a specific slice of data (e.g., a single customer ID) that cannot be modified by the end-user viewing the embed.

Vulnerability Class: The flaw is fundamentally an improper input validation / authorization bypass issue (CWE-20). The NVD description states that: "it was possible to circumvent locked parameters when requesting data for a question in an embedded dashboard by constructing a malicious request to the backend."

Attack Mechanism (class-level): An attacker who can view an embedded dashboard (which requires only the public embed URL, not authentication) can craft a direct HTTP request to the Metabase backend API, bypassing the frontend/embedding JS layer entirely. The backend fails to fully validate that all parameter constraints present in the signed embedding configuration are applied when the embedded question is executed with a parameter override.

The exact implementation flaw is not disclosed in the public description available for this CVE. Based on the vulnerability class, the likely mechanism involves one of:

• Direct API invocation: The embedded dashboard fetches data from a backend endpoint (commonly /api/dashboard/{id}/query or /api/card/{id}/query). The embedding token carries claims about valid parameter values. If the backend doesn't independently cross-check that parameters in the incoming request match the signed constraints, overriding a "Locked" parameter with a different value succeeds.

• Parameter serialization/deserialization mismatch: The parameter is serialized in the signed JWT token and then deserialized at the backend. If there is a type confusion (e.g., passing an array of values instead of a single string, or passing a null value) the locked-value check may be bypassed due to improper comparison logic.

• Multi-parameter interaction: The attacker may modify the value of one parameter (allowed) to indirectly influence the value of a "Locked" parameter.

Insufficient technical detail is available in the CVE description to confirm which of the above is the exact mechanism. We characterize this as a server-side authorization enforcement gap.

Attack Surface: The attack surface is any public-facing Metabase instance (version < patch) that uses Signed Embedding with locked parameters. This feature is commonly used in production first-party web applications, customer portals, and public analytics dashboards. The attacker does not require Metabase credentials, making this a pre-authentication vulnerability (CVSS vector: AV:N / PR:N).

Exploitation Scenarios

The NVD description is authoritative for the following analysis: the attack requires requesting "data for a question in an embedded dashboard" via a "malicious request to the backend." No public PoC is available; the attack chain is inferred from the vulnerability class.

Step 1 — Reconnaissance / Target Identification: A publicly accessible embedded dashboard URL is present. In Metabase, embed URLs typically follow a pattern of /embed/dashboard/{token}#{parameters}. An attacker starts by obtaining such an embed URL — either by discovering it via web crawling, from publicly indexed pages, or from a third-party site that embeds the dashboard. The attacker inspects the embed to identify which parameters are present and which are marked "Locked" (visible in the UI as read-only parameters).

Step 2 — Triggering the Flaw: The attacker constructs a direct HTTP request to the Metabase backend API — bypassing the frontend entirely — targeting the data-fetch endpoint for a question embedded in the dashboard. Instead of relying on the signed embedding token to convey parameter values, the attacker supplies a parameters object in the POST body that overrides a "Locked" parameter with a different value. Because the frontend is bypassed, client-side protections (such as disabled input fields) are irrelevant.

Step 3 — Payload / Execution at Class Level: The "payload" is a crafted JSON parameter object sent to the backend, e.g., changing a locked customer_id parameter from the value 12345 (the embedded user's own ID) to 99999 (another customer's ID). The vulnerability is that the backend does not reject the request when the locked parameter value differs from what the embedding token allowed.

Step 4 — Post-Exploitation Impact: Successful exploitation results in data exposure beyond what the embedding admin intended. An attacker could:

• Enumerate all values of a given column by iterating parameter values.
• Extract sensitive data belonging to other tenants/customers in a multi-tenant setup.
• Potentially bypass row-level security and access internal analytics.

Impact Assessment

• Confidentiality Impact: HIGH — locked parameters are the primary method of scoping embedded analytics to specific tenants or users. Bypassing them exposes potentially sensitive business data (financial records, PII, internal metrics) to unauthorized parties.
• Integrity Impact: HIGH — the attacker can influence the queries executed against the backend, possibly modifying data if the underlying question permits write operations (rare for dashboards, but possible in question-based write-back scenarios).
• Availability Impact: NONE (per CVSS).
• CVSS Score: 6.5 (Medium). Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N.
• Affected Systems: All Metabase installations running versions < 0.42.6, < 0.43.7, < 0.44.5 (OSS) and < 1.42.6, < 1.43.7, < 1.44.5 (Enterprise) that utilize Signed Embedding with locked parameters. Standalone installations without embedded dashboards are unaffected.
• Blast Radius: Multi-tenant SaaS deployments and customer-facing analytics portals are the highest risk. OSV package references indicate the vulnerable code was present across the codebase (package / at commit hashes de1264e1..., ee686fcfe..., d3700f53..., all marked as unfixed prior to patch).

Detection Guidance

Sigma Rule

title: Metabase Locked Parameter Bypass Attempt (CVE-2022-39358)
id: 1a2b3c4d-5e6f-7890-abcd-ef1234567890
status: experimental
description: Detects attempts to bypass locked parameters in Metabase embedded dashboards via backend API requests with inconsistent parameter objects.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2022-39358
author: Valters IT Threat Intelligence
date: 2023/10/01
tags:
    - attack.t1190
    - cve.2022.39358
logsource:
    category: webserver
    product: nginx
    definition: Requests destined to the Metabase backend API from embed contexts
detection:
    selection:
        cs-method: POST
        cs-uri-query:
            - contains: '/api/dashboard/'
            - contains: '/api/card/'
        http_request_body|contains: '"parameter"'
        http_request_body|contains: '"locked"'
    condition: selection
level: high
falsepositives:
    - Legitimate embeds where the frontend sends back the same locked parameter value (identical) 
field-mappings:
    - request_body: http_request_body

YARA Rule

rule Metabase_Locked_Param_Bypass_CVE_2022_39358
{
    meta:
        author = "Valters IT Threat Intelligence"
        description = "Detects POST bodies to Metabase API indicating a locked parameter override attempt"
        date = "2023-10-01"
        reference = "CVE-2022-39358"
        hash_score = "0xdeadbeef"
    strings:
        $s1 = "api/dashboard/" ascii nocase
        $s2 = "api/card/" ascii nocase
        $s3 = "locked" ascii nocase
        $s4 = "parameter" ascii nocase
        $s5 = "query" ascii nocase
    condition:
        uint16(0) == 0x0D0A and all of them
}

Suricata IDS Rule

alert http any any -> $EXTERNAL_NET any (msg:"ET EXPLOIT Metabase CVE-2022-39358 Locked Parameter Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/"; http.uri; content:"query"; pcre:"/(?i)\"locked\"/"; pcre:"/(?i)\"parameter\"/"; classtype:attempted-admin; sid:202239358001; rev:1; reference:cve,2022-39358;)

Elastic Detection

sequence by host.name with maxspan=5s
  [network where destination.port == 80 and process.name == "nginx"]
  [http where request.method == "POST" and request.uri contains "/api/" and request.body contains "locked" and request.body contains "parameter"]

Splunk SPL Query

index=web sourcetype=access_combined
| where method="POST"
| search uri=*"/api/dashboard/"* OR uri=*"/api/card/"*
| rex field=_raw "<body>(?<reqbody>.*?)</body>"
| where reqbody LIKE "%locked%"
| stats count by clientip, uri,  _time, status

Wazuh OSSEC Rule

<group name="metabase,">
  <rule id="100393" level="12">
    <decoded_as>json</decoded_as>
    <field name="url">\.api\.(dashboard|card).*</field>
    <field name="data">.*"locked".*</field>
    <field name="data">.*"parameter".*</field>
    <description>Possible Metabase locked parameter bypass in HTTP body destined to API endpoint.</description>
    <group>exploit,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

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

1. Immediate Mitigations (if patch cannot be applied immediately):

   • If you use Signed Embedding with locked parameters, temporarily disable the embed feature entirely (remove the relevant endpoint from exposure) until patched.
   • Place the Metabase instance behind a reverse proxy (e.g., nginx) that restricts /api/ endpoints to only the embedding application's own IP address or authenticated sessions. Since the attacker requires direct backend API access, blocking anonymous API access to /api/dashboard/*/query effectively mitigates this CVE.
   • Monitor logs for anomalous parameter combination anomalies (e.g., two different locked values for the same session).

2. Patch/Upgrade Steps:

   • Upgrade Metabase to the latest patched version:
     • Open Source: 0.44.5, 0.43.7, 0.42.6 (or newer)
     • Enterprise: 1.44.5, 1.43.7, 1.42.6 (or newer)
   • For Docker deployments: pull the new image (metabase/metabase:v0.44.5 etc.).
   • For JAR deployments: download the patched JAR from official releases and replace existing binaries.
   • For Elastic Beanstalk/AWS: update to the corresponding patched application version.
   • After upgrade, verify that locked parameters remain non-editable by attempting a manual API call with a modified locked value.

3. Long-term Hardening:

   • Use network segmentation so that Metabase API endpoints are only reachable from trusted application servers, not directly from the internet. If end-user embeds are used, serve them through a proxy that validates parameters before forwarding.
   • Enable detailed API access logging — record all body request payloads to a SIEM for forensic purposes.
   • Follow Metabase security advisories and subscribe to their CVE notification feed.
   • Review embedded dashboard usage: keep the number of embed endpoints minimal and protect them with short-lived tokens.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-39358
2. OSV database entry: https://osv.dev/vulnerability/CVE-2022-39358
3. Metabase security advisory (CNA): Provided via GitHub Security Advisories — GHSA-m6w8-7q9v-r8m (likely ID, pending confirmation)
4. Reported fixed commits: OSV references commit hashes de1264e, ee686fc, d3700f5 (unfixed → fixed) in the Metabase repository.
5. CISA KEV: NOT listed — no known exploitation in the wild (EPSS 0.00451, 37.3% percentile).

Threat Actor Activity: No known exploits-in-the-wild or threat actor campaigns reference this CVE at the time of writing. The EPSS score (0.00451) indicates a low probability of exploitation in the wild. However, Metabase is widely deployed in internal analytics scenarios, and the barrier to exploitation (requiring only access to an embed URL) is low, so the risk of targeted exploitation should not be dismissed. Monitor logs for requests to /api/dashboard/ or /api/card/ containing unexpected parameter objects.