CVE-2026-50148: Metabase Snowflake Connection RCE
TL;DR - Critical Metabase RCE, CVSS 10.0, caused by abuse of a Snowflake JDBC file-write flaw. - Affects Metabase users who can add or edit database connections. - Upgrade immediately to the fixed release for your branch and review Snowflake connection changes.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-50148 |
| CVSS Score | 10.0 |
| Attack Vector | Network, through the Metabase application |
| Auth Required | Yes. Attacker needs a Metabase user account with permission to add or edit a database connection |
| Patch Available | Yes |
This vulnerability is a server-side remote code execution issue in Metabase. The documented attack path requires an authenticated Metabase user with enough application-level privilege to create or modify a database connection. That requirement is important, but it should not be treated as a strong safety boundary in environments where analytics administrators, developers, BI engineers, or power users regularly onboard data sources.
The published description ties exploitation to a malicious Snowflake connection. By pointing Metabase at an attacker-controlled server and abusing a flaw in the Snowflake JDBC driver, the attacker can write arbitrary files on the Metabase host. That file-write primitive can then be escalated into code execution by replacing one of Metabase’s own database driver files, which is later loaded inside the Metabase process.
What Is This Vulnerability?
At its core, CVE-2026-50148 is an arbitrary file write leading to remote code execution. The vulnerable condition is not described as a generic unauthenticated internet exploit against every Metabase instance. Instead, the issue depends on a specific workflow inside Metabase: configuring a Snowflake database connection. When that connection points to infrastructure controlled by an attacker, a flaw in the Snowflake JDBC driver can be abused to write files to arbitrary locations on the Metabase server.
That arbitrary file write is what turns a dangerous integration flaw into an RCE. Metabase relies on database driver files on disk. If an attacker can overwrite one of those files, they can potentially cause Metabase to load malicious content during normal application behavior. Once loaded, that content executes within the Metabase process, meaning the attacker may gain code execution with the same permissions as the service account running Metabase.
From an operational perspective, this is a classic example of a trusted connector path becoming an execution path. Security teams sometimes focus on external exposure and miss the risk created by internal application permissions. Here, the security boundary is not just the public login page. It is also the set of users allowed to manage database connections, especially in shared analytics environments where access control may be broad for convenience.
Technical Notes
The public description confirms this chain at a high level:
- Authenticated Metabase user can add or edit a database connection.
- User configures a Snowflake connection to an attacker-controlled server.
- Snowflake JDBC flaw permits arbitrary file write on the Metabase host.
- Attacker replaces a Metabase database driver file.
- Metabase later loads that file, resulting in RCE in the Metabase process.
Because the primary sources provided do not publish packet-level or file-path specifics, defenders should avoid guessing exact overwritten paths and instead monitor for unexpected file changes in the Metabase installation and plugin/driver directories.
Who Is Affected?
The affected product is Metabase, and the vulnerable ranges are specifically identified in the published record. The issue affects versions from 1.54.0 onward in multiple release trains until their respective fixed point releases. That means this is not limited to one narrow branch; organizations running recent Metabase versions should check the exact build number rather than assume they are safe because they are not on the latest major train.
The vulnerable version ranges are:
- 1.54.x before 1.54.24
- 1.55.x before 1.55.24
- 1.56.x before 1.56.25
- 1.57.x before 1.57.19
- 1.58.x before 1.58.14
- 1.59.x before 1.59.10
- 1.60.x before 1.60.4
The fixed versions are explicitly listed as:
- 1.54.24
- 1.55.24
- 1.56.25
- 1.57.19
- 1.58.14
- 1.59.10
- 1.60.4
Who is realistically exposed? Any Metabase deployment where non-core admins can define or edit database connections deserves attention first. In many organizations, data teams are delegated that ability so they can onboard Snowflake, PostgreSQL, MySQL, or other sources without involving platform operations for each change. In those environments, compromise of one user account with connection-management rights could become compromise of the Metabase host.
Internet exposure is not the only risk factor. Even internally deployed Metabase instances are at risk if an insider, contractor, or attacker using stolen credentials can reach the application and has the required permissions. Treat this as a high-priority privilege-escalation-to-RCE scenario within the application trust model.
CVSS Score Breakdown
The published base score is 10.0, which places this issue in the highest severity category. The exact CVSS vector string was not provided in the supplied research note, so defenders should not assume individual metric values beyond what is directly supported by the published summary. Still, the score itself signals that the resulting impact on confidentiality, integrity, and availability is considered severe.
Why does a flaw with an authentication requirement still rate this high? Because the end state is remote code execution on the server. In practical terms, successful exploitation can give an attacker the ability to run arbitrary code under the Metabase service context, tamper with application data, steal secrets available to the process, pivot to connected systems, and establish persistence. For an analytics platform, that may include access to database credentials, query histories, dashboard definitions, and sensitive business data.
The attack complexity also appears low from the public description once the attacker has the necessary Metabase permissions. They do not need local shell access to the host first. They use a supported application workflow, configure a malicious Snowflake endpoint, and leverage the file-write condition to corrupt a driver artifact. That is exactly the kind of chain that tends to justify a critical rating even when some privilege is required up front.
In the absence of the vector string, defenders should treat the score as a prioritization signal rather than reverse-engineer unsupported metric details. The safe assumption is simple: if your environment allows users to manage connections and runs a vulnerable build, your risk is significant enough to patch immediately.
Exploitation Status
Based on the supplied primary-source summary, there is no confirmed evidence of active exploitation in the wild at the time of writing. The research note also states that CVE-2026-50148 is not listed in CISA KEV. That matters because KEV inclusion often reflects stronger evidence of exploitation against real-world targets, especially in government and enterprise tracking workflows.
There is also no confirmed public proof of concept in the provided source set. That does not mean exploitation is difficult or unlikely. It only means the available sources used for this article do not confirm a public repository, weaponized sample, or vendor statement of active attacks. For a CVSS 10.0 issue with a clear exploit chain, defenders should assume public exploit development may follow quickly even if it was not visible at publication time.
So the most accurate statement is:
- PoC public? No confirmed public PoC in the supplied sources.
- Active exploitation? No confirmed in-the-wild exploitation in the supplied sources.
- CISA KEV status? Not listed at time of lookup.
Operationally, that should drive a measured but urgent response. You do not need confirmed botnet-scale exploitation to justify emergency patching here. If an attacker can obtain or already has a connection-management-capable account, the path to server compromise is severe enough to prioritize.
How to Detect It
Detection should focus on three areas: Metabase administrative activity, unexpected outbound connection behavior related to Snowflake configuration, and filesystem changes affecting Metabase driver files. Because the public advisory summary describes the exploit through an attacker-controlled Snowflake server, any recent creation or modification of Snowflake connections should be treated as suspicious until reviewed.
Start by auditing who has permission to add or edit database connections and identifying all recent connection changes. If your organization rarely uses Snowflake in Metabase, the sudden appearance of a new Snowflake connection deserves immediate investigation. If Snowflake is used routinely, look for unusual hostnames, IP addresses, test connections initiated by unexpected users, or connection updates outside normal change windows.
You should also check for filesystem modifications in the Metabase installation path, plugin directory, or driver storage locations. The supplied sources do not specify exact filenames or paths involved in every deployment method, so defenders should baseline normal contents and alert on changes, especially to JAR files and driver artifacts. In containerized deployments, compare the runtime filesystem to the signed image or redeploy from a trusted image and inspect diffs.
Technical Notes
Review Metabase and reverse-proxy logs for connection-management actions and unusual Snowflake-related requests. Exact log formats vary by deployment, but practical starting patterns include:
snowflake
/api/database
POST /api/database
PUT /api/database/
/api/database/validate
Example grep workflow on an application or proxy log set:
grep -Ei 'snowflake|/api/database|/api/database/validate' /var/log/nginx/access.log /var/log/metabase/*.log
If you centralize logs in Splunk, a basic hunt query could be:
index=app_logs (source=*metabase* OR source=*nginx* OR source=*proxy*)
("snowflake" OR "/api/database" OR "/api/database/validate")
| stats count min(_time) as firstSeen max(_time) as lastSeen by user, src_ip, uri_path, http_method
| convert ctime(firstSeen) ctime(lastSeen)
For filesystem monitoring on Linux, look for recent JAR changes under common Metabase paths:
find /opt/metabase /app /plugins -type f \( -name "*.jar" -o -name "*.zip" \) -mtime -7 -ls 2>/dev/null
If you have EDR or auditd, alert on write events to Metabase directories by the Metabase service account. In the absence of path-specific vendor guidance, assume any unexpected driver-file change after a database connection edit is high signal.
Mitigation and Patching
The primary mitigation is to upgrade to the fixed point release for your branch. The published fixed versions are 1.54.24, 1.55.24, 1.56.25, 1.57.19, 1.58.14, 1.59.10, and 1.60.4. Choose the fixed release that matches your supported branch or move to the latest fixed train approved by your change process.
If you cannot patch immediately, reduce exposure by restricting who can add or edit database connections in Metabase. This is not a substitute for patching, but it narrows the set of users who can trigger the vulnerable workflow. You should also review existing Snowflake connections, temporarily disable unneeded ones, and block Metabase from reaching unapproved external destinations where feasible. Egress filtering can help limit attacker-controlled endpoint use, though it may not eliminate all risk in environments that legitimately connect to Snowflake.
Because this issue can involve arbitrary file writes on the host, teams should consider the possibility of post-exploitation tampering even after patching. If you suspect abuse, do not just upgrade and move on. Redeploy Metabase from a trusted package or image, rotate secrets available to the service, review application admin accounts, and inspect the host for persistence.
Technical Notes
Upgrade examples will vary by deployment model. The exact package name in your environment may differ, so verify with your vendor-approved installation method.
For Docker deployments, pin to a fixed release explicitly:
docker pull metabase/metabase:v1.60.4
docker stop metabase
docker rm metabase
docker run -d --name metabase -p 3000:3000 metabase/metabase:v1.60.4
For Docker Compose:
sed -i 's#metabase/metabase:.*#metabase/metabase:v1.60.4#' docker-compose.yml
docker compose pull
docker compose up -d
For Kubernetes, update the image tag and roll out:
kubectl set image deployment/metabase metabase=metabase/metabase:v1.60.4 -n analytics
kubectl rollout status deployment/metabase -n analytics
If you cannot patch immediately, apply a permissions-based workaround by removing database-connection edit capability from non-essential users and restricting outbound access from the Metabase host to approved Snowflake endpoints only. Also consider temporarily disabling new Snowflake connection onboarding until the upgrade is complete.
After upgrading, validate the running version and inspect for tampering:
docker inspect --format='{{.Config.Image}}' metabase
find /opt/metabase /app /plugins -type f -name "*.jar" -exec sha256sum {} \;
References
The primary reference for this CVE is the Metabase GitHub Security Advisory associated with the issue. That advisory is the best vendor-linked source for exact affected and fixed version ranges, and it aligns with the published NVD description used in this article.
The NVD record provides the standardized vulnerability summary and publication metadata. CISA KEV status is also relevant here because the issue is not listed in KEV at the time of lookup, which means there is no KEV-backed confirmation of exploitation in the provided source set.
- NVD CVE record for CVE-2026-50148
- Metabase GitHub Security Advisory: https://github.com/metabase/metabase/security/advisories/GHSA-r6x2-rchx-q9g9
- Metabase Security Advisories Index: https://github.com/metabase/metabase/security/advisories
- Metabase security update page: https://www.metabase.com/blog/security-vulnerability
- Metabase postmortem page: https://www.metabase.com/blog/security-vulnerability-postmortem
For further understanding of security vulnerabilities and their implications, you can also explore our articles on what is SIEM? and what is SOC 2?.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.