CVE-2025-32382

Executive Summary

CVE-2025-32382 is a security vulnerability in Metabase, an open-source Business Intelligence and Embedded Analytics tool. The flaw resides in the Snowflake connection migration logic. When an administrator updates Snowflake connection details (e.g., changing a password or switching between password and private key authentication), Metabase attempts to test each connection method sequentially. Upon finding a successful connection, it logs the connection details—including the username and password—to the application log file. This exposes sensitive credentials to anyone with read access to the logs, violating the principle of least privilege and potentially leading to credential theft.

This vulnerability affects Metabase versions 52.0.0 through 52.17.0, 53.0.0 through 53.9.4, and 54.0.0 through 54.1.4. Versions 51 and lower are not impacted. The issue is fixed in versions 52.17.1, 53.9.5, and 54.1.5.

Supply Chain & Package Security

Metabase is distributed as a Java JAR file and as a Docker image. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the application's core logic. However, organizations using Metabase should verify their deployment source (official releases only) and ensure no tampered builds are in use.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (NVD) – However, based on the impact, a more accurate score is 6.5 (Medium).

Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

• Attack Vector (AV): Network – The attacker can access logs remotely if logs are stored or transmitted over the network.
• Attack Complexity (AC): Low – No special conditions required.
• Privileges Required (PR): High – Requires admin-level access to trigger the migration.
• User Interaction (UI): None – No user action needed beyond the admin action.
• Scope (S): Unchanged – The vulnerable component is the same as the impacted component.
• Confidentiality (C): High – Credentials are exposed.
• Integrity (I): None – No data modification.
• Availability (A): None – No denial of service.

Threat Level: Medium. The vulnerability requires admin privileges to trigger, but once triggered, credentials are exposed in logs, which may be accessible to lower-privileged users or external attackers if logs are not properly secured.

Deep Dive & Mechanics

The vulnerability is in the Snowflake database connection migration logic. When an admin changes Snowflake connection details (e.g., updating a password or switching from password to private key), Metabase attempts to connect using the new method. If successful, it logs the connection details for debugging purposes.

Root Cause: The log/infof function is called with the full connection details, including the password, when a successful connection is found. The code does not sanitize or redact sensitive fields before logging.

Affected Code Path:

1. Admin updates Snowflake connection details via the UI or API.
2. Metabase iterates through connection methods (password, private key, etc.).
3. For each method, it attempts to connect to Snowflake.
4. If a connection succeeds, it logs: "Successfully connected, migrating to: %s" (pr-str test-details).
5. The test-details map includes the username and password in plaintext.

Impact: Any user or process with read access to the Metabase application logs can retrieve the Snowflake credentials. This could lead to unauthorized data access, data exfiltration, or lateral movement within the Snowflake environment.

Vulnerable vs. Patched Code

Vulnerable Code (Example):

;; In the Snowflake connection migration logic
(when (successful-connection? test-details)
  (log/infof "Successfully connected, migrating to: %s" (pr-str test-details))
  ;; ... proceed with migration
)

Patched Code (Example):

;; Redact sensitive fields before logging
(let [sanitized-details (dissoc test-details :password :private-key)]
  (log/infof "Successfully connected, migrating to: %s" (pr-str sanitized-details))
  ;; ... proceed with migration
)

The patch removes the :password and :private-key keys from the details map before logging, preventing credential exposure.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Admin access to a Metabase instance (versions 52.0.0-52.17.0, 53.0.0-53.9.4, or 54.0.0-54.1.4).
• A Snowflake database connection configured.

Exploitation Steps:

1. Log in as an admin to the Metabase instance.
2. Navigate to the Snowflake database connection settings.
3. Change the password (or switch authentication method).
4. Save the changes. Metabase will attempt to connect and log the credentials.
5. Access the application logs (e.g., /var/log/metabase/metabase.log or via Docker logs).
6. Search for the string "Successfully connected, migrating to:" to extract the credentials.

Example Log Entry:

2025-04-01 12:34:56,789 INFO metabase.core: Successfully connected, migrating to: {:dbname "SNOWFLAKE_DB", :user "admin", :password "SuperSecret123!", :host "snowflake.example.com", :port 443}

Blue Team

Detection:

• Monitor logs for the string "Successfully connected, migrating to:".
• Alert on any occurrence of this log message, as it indicates credential exposure.

Prevention:

• Apply the patch immediately (upgrade to 52.17.1, 53.9.5, or 54.1.5).
• Restrict log access to only authorized personnel.
• Use centralized logging with access controls and audit trails.
• Implement log redaction for sensitive fields (e.g., using Logstash or Fluentd filters).

Hunting:

• Search existing logs for the vulnerable log pattern.
• Check for any unauthorized access to Snowflake using credentials found in logs.

Indicators of Compromise (IOCs)

• Log Pattern: "Successfully connected, migrating to:" followed by a map containing :password or :private-key.
• Log File: Metabase application log (e.g., metabase.log).
• Affected Versions: 52.0.0-52.17.0, 53.0.0-53.9.4, 54.0.0-54.1.4.
• Fixed Versions: 52.17.1, 53.9.5, 54.1.5.

Detection Engineering

YARA Rule

rule CVE_2025_32382_Metabase_Credential_Leak {
    meta:
        description = "Detects Metabase log entries exposing Snowflake credentials"
        author = "Valters IT"
        date = "2025-04-01"
        reference = "CVE-2025-32382"
    strings:
        $log_pattern = "Successfully connected, migrating to:"
        $password_field = ":password"
        $private_key_field = ":private-key"
    condition:
        $log_pattern and ($password_field or $private_key_field)
}

Sigma Rule

title: Metabase Snowflake Credential Leak in Logs
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects Metabase log entries containing Snowflake credentials due to CVE-2025-32382
author: Valters IT
date: 2025-04-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-32382
logsource:
    product: metabase
    service: application
detection:
    selection:
        message|contains: "Successfully connected, migrating to:"
    condition: selection
falsepositives:
    - None expected; this log message should not appear in patched versions.
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-32382 Metabase Snowflake Credential Leak"; flow:to_server,established; content:"Successfully connected, migrating to:"; nocase; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Metabase to version 52.17.1, 53.9.5, or 54.1.5 (or later).
2. Rotate any Snowflake credentials that may have been exposed in logs.
3. Review log access controls and ensure logs are not accessible to unauthorized users.

Long-Term Mitigations:

• Implement log redaction for all sensitive fields (passwords, keys, tokens).
• Use a centralized logging solution with encryption at rest and in transit.
• Regularly audit log access and retention policies.
• Enable audit logging for all admin actions, especially database connection changes.

Workaround (if patching is not immediately possible):

• Disable Snowflake connection migration by not changing connection details until the patch is applied.
• Manually purge old connection details from the application database before making changes.

Valters IT