Metabase Unauthenticated Admin Access Vulnerability Exploited as Zero-Day — Patching, Detection, and Response Guide

Introduction

Metabase — the open-source business intelligence platform sitting in thousands of corporate networks, frequently connected directly to production databases — has patched a critical vulnerability that allows unauthenticated, remote attackers to gain administrative access to exposed instances. According to SecurityWeek's reporting, the flaw was exploited as a zero-day before a fix shipped, which means defenders must operate on the assumption of prior compromise, not just future risk.

This is exactly the class of vulnerability that keeps IR teams busy. Metabase is a force multiplier for attackers: it holds database connection strings, query credentials, and cached query results containing sensitive business data. An attacker with admin access to Metabase is, in practice, an attacker with a beachhead into your data tier. If you run self-hosted Metabase — especially anything reachable from the internet or a broad internal segment — treat this as an emergency change window, not a routine patch cycle.

What Happened

The vendor released a fix for a security defect enabling pre-authentication administrative takeover of Metabase instances. No authentication, no valid session, no user interaction — a remote attacker who can reach the Metabase web interface (default port 3000) can escalate to full administrative control of the application. Exploitation was observed in the wild prior to patch availability, elevating this from a theoretical exposure to an active-compromise scenario.

Technical Analysis

Affected Products and Exposure

• Product: Metabase (self-hosted open-source and Enterprise editions)
• Attack surface: The Metabase web application, typically exposed on TCP 3000, frequently fronted by a reverse proxy (nginx, Apache, ALB/Cloudflare)
• Attacker requirements: Network reachability to the Metabase HTTP(S) interface. No credentials or session required.
• Impact: Administrative access to the Metabase application — which cascades into access to configured database connections, stored credentials, user accounts, and the ability to execute arbitrary SQL queries against connected data sources.

Why This Is Worse Than a Typical Web App Bug

From a defender's perspective, the blast radius of a Metabase compromise extends far beyond the application itself:

1. Credential harvesting: Metabase stores database connection details. Depending on configuration and secrets handling, attackers can extract or abuse these to pivot directly into production databases.
2. Arbitrary query execution: Admin-level access to Metabase's native query editor means SQL against every connected data warehouse, lake, or operational database.
3. Persistence: Attackers can create local admin accounts, modify SMTP settings for phishing infrastructure, or abuse the platform's extensibility. Historical Metabase exploitation (the setup-token class of bugs) showed attackers immediately deploying web shells and cryptominers via the underlying JVM.
4. JVM-level execution risk: Metabase runs on the JVM (metabase.jar). Prior exploitation campaigns against Metabase bugs have chained app-level access into OS command execution on the host. Hunt accordingly — do not assume the compromise stopped at the application layer.

Exploitation Status

• Confirmed in-the-wild exploitation prior to patch release (zero-day).
• Assume internet-wide scanning and opportunistic exploitation followed public disclosure, consistent with every prior Metabase critical advisory.

Attack Chain (Defender's View)

1. Unauthenticated HTTP request(s) to the Metabase web interface exploiting the flaw
2. Administrative session or privilege established within the application
3. Reconnaissance of connected databases via /api/database and the query interface
4. Potential host-level execution via JVM child processes (historically: java spawning shells, curl/wget pulling second-stage payloads)
5. Persistence via new admin user creation and/or host-level implants

Detection & Response

The most reliable pre-compromise telemetry is your reverse proxy / WAF access logs and Metabase application logs; the most reliable post-compromise telemetry is process execution on the Metabase host. Focus there.

Sigma Rules

---
title: Metabase JVM Spawning Shell or Command Interpreter
id: 3f8a1c44-7b2d-4e91-a6c5-9d0e2f4b8a17
status: experimental
description: Detects the Metabase Java process spawning shell or scripting interpreters, a strong post-exploitation indicator following admin-level compromise of a Metabase instance.
references:
  - https://www.securityweek.com/metabase-patches-vulnerability-exploited-as-zero-day/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.execution
  - attack.t1059
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'metabase.jar'
      - 'metabase'
  selection_child:
    CommandLine|contains:
      - '/bin/sh'
      - '/bin/bash'
      - 'curl '
      - 'wget '
      - 'python'
      - 'perl '
      - 'ncat'
      - 'nc -'
      - 'base64'
  condition: selection_parent and selection_child
falsepositives:
  - Custom Metabase alerting or export scripts explicitly invoking shells (rare; validate against change records)
level: critical
---
title: Unauthenticated Requests to Metabase Admin and Setup API Endpoints
id: 8c2e5b19-4d7a-4f36-b821-6a3d9c1e5f42
status: experimental
description: Detects HTTP requests to sensitive Metabase administrative and setup API paths that are commonly targeted during unauthenticated exploitation attempts. Tune to your proxy log format.
references:
  - https://www.securityweek.com/metabase-patches-vulnerability-exploited-as-zero-day/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/api/setup'
      - '/api/session'
      - '/api/user'
      - '/api/util/password_check'
      - '/api/database'
  selection_status:
    sc-status:
      - 200
      - 201
  condition: selection_uri and selection_status
falsepositives:
  - Legitimate admin activity and health checks; correlate with source IP and session context — successful requests to these paths from untrusted or previously unseen external IPs are the signal
level: high
---
title: New Metabase Admin Session From External Source
id: 5d1f9a37-2e8b-4c64-a093-7f5b2e8c4d61
status: experimental
description: Detects successful authentication/session creation against Metabase originating from non-RFC1918 source addresses, indicating possible external account takeover or exploit-driven session creation.
references:
  - https://www.securityweek.com/metabase-patches-vulnerability-exploited-as-zero-day/
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1078
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri|contains: '/api/session'
    cs-method: 'POST'
    sc-status: 200
  filter_internal:
    c-ip|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.2'
      - '172.30.'
      - '172.31.'
      - '127.'
  condition: selection and not filter_internal
falsepositives:
  - Legitimate remote administrators where Metabase is intentionally internet-facing (an architecture you should reconsider)
level: high

KQL (Microsoft Sentinel / Defender)

This query hunts across proxy/WAF logs ingested via CommonSecurityLog and host telemetry via Syslog for both the web-layer attack and post-exploitation process execution on the Metabase host. If your Metabase host is onboarded to Defender for Endpoint, swap in DeviceProcessEvents for the second half.

let lookback = 14d;
let metabaseHosts = dynamic(["metabase"]);
// Stage 1: External hits to sensitive Metabase API paths via proxy/WAF logs
let WebHits = CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where RequestURL has_any ("/api/setup", "/api/session", "/api/database", "/api/user")
| where RequestMethod == "POST" and ApplicationProtocol =~ "http"
| extend IsExternal = iff(SourceIP startswith "10." or SourceIP startswith "192.168." or SourceIP startswith "172.16.", false, true)
| where IsExternal == true
| project TimeGenerated, SourceIP, RequestURL, RequestMethod, DestinationHostName, DeviceAction;
// Stage 2: Shell/network tooling spawned under the Metabase JVM on the host
let HostExec = Syslog
| where TimeGenerated > ago(lookback)
| where Computer has_any (metabaseHosts)
| where SyslogMessage has "metabase" and SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl", "wget", "nc ", "base64 -d")
| project TimeGenerated, Computer, ProcessName, SyslogMessage;
WebHits
| union HostExec
| sort by TimeGenerated desc

Velociraptor VQL

Use this artifact against your Metabase servers to identify post-exploitation process execution and outbound fetch activity originating from the Java process:

-- Hunt for shells and download tools spawned by the Metabase JVM
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(/bin/(ba)?sh|curl |wget |nc |ncat |base64 -d|python -c|perl -e)'
  AND (
    CommandLine =~ '(?i)metabase'
    OR Ppid IN (
      SELECT Pid FROM pslist() WHERE CommandLine =~ '(?i)metabase.jar'
    )
  )

Also pull active network connections for the Java process — an admin-compromised Metabase making outbound connections to unknown hosts is a beaconing indicator:

-- Enumerate network connections held by the Metabase Java process
LET metabase_pids = SELECT Pid FROM pslist() WHERE CommandLine =~ '(?i)metabase.jar'
SELECT Pid, Family, Type, LocalIP, LocalPort, RemoteIP, RemotePort, Status
FROM netstat()
WHERE Pid IN (SELECT Pid FROM metabase_pids)
  AND RemoteIP NOT IN ('127.0.0.1', '::1')

Triage / Verification Script

Run this on Metabase hosts to check the deployed version, identify suspicious child processes of the JVM, and surface recently created local artifacts:

#!/bin/bash
# metabase-triage.sh — post-advisory triage for self-hosted Metabase
set -euo pipefail

echo "=== Metabase version ==="
# Adjust path to your deployment; Docker: use 'docker exec <container> java -jar /app/metabase.jar --version'
java -jar /opt/metabase/metabase.jar version 2>/dev/null || echo "[!] metabase.jar not found at default path — locate with: find / -name 'metabase.jar' 2>/dev/null"

echo ""
echo "=== Running Metabase processes ==="
ps aux | grep -i metabase | grep -v grep

echo ""
echo "=== Child processes of Metabase JVM (post-exploitation check) ==="
MB_PID=$(pgrep -f "metabase.jar" | head -1 || true)
if [ -n "${MB_PID}" ]; then
  ps --ppid "${MB_PID}" -o pid,ppid,user,cmd 2>/dev/null || echo "[+] No child processes of PID ${MB_PID}"
else
  echo "[!] No running metabase.jar process found"
fi

echo ""
echo "=== Recent files modified under Metabase dirs (last 7 days) ==="
find /opt/metabase /usr/share/metabase ~/.metabase -type f -mtime -7 2>/dev/null | head -50

echo ""
echo "=== Outbound connections from Java (established) ==="
ss -tnp 2>/dev/null | grep -i java || echo "[+] No established java connections (or insufficient privileges)"

echo ""
echo "=== Metabase API log review reminder ==="
echo "Review Metabase application logs for POST /api/session and /api/setup from external IPs."

Remediation

1. Patch immediately. Upgrade to the latest fixed Metabase release published with this advisory. Pull the current release from the official Metabase GitHub releases page or your enterprise distribution channel, and confirm the running version post-upgrade (java -jar metabase.jar version). Do not rely on package-manager caches — verify the actual JAR/container image digest.
2. Assume compromise and hunt retroactively. Because exploitation preceded the patch, patching alone is not remediation. Review proxy/WAF logs for unauthenticated requests to /api/* admin and setup paths over at least the past 30 days, audit the Metabase admin user list for accounts you did not create, and review host process telemetry for JVM-spawned shells.
3. Rotate everything Metabase touches. Treat all database credentials configured in Metabase, Metabase local user passwords, API keys, and any SMTP/secret-store credentials as compromised if you find (or cannot rule out) exploitation. Rotate them now.
4. Remove direct internet exposure. Metabase should sit behind an authenticated reverse proxy, VPN, or identity-aware proxy (e.g., SSO fronting). An unauthenticated pre-auth admin-takeover bug is the reason BI tooling does not belong on the public internet, period.
5. Segment the data path. Restrict egress from the Metabase host to only the databases it legitimately queries. This limits post-compromise pivoting even if the application is breached again.
6. Harden the host. Run Metabase as a dedicated unprivileged service account with no sudo rights, and apply egress filtering so the JVM cannot fetch second-stage payloads from the internet.
7. Monitor the advisory channel. Subscribe to Metabase's security advisories and check whether CISA adds this flaw to the Known Exploited Vulnerabilities catalog — KEV listing carries binding remediation deadlines for federal agencies and is a reliable prioritization signal for everyone else.

Bottom Line

An unauthenticated admin-takeover bug in a platform wired into your production databases, exploited before a patch existed, is a top-of-queue event. Patch today, but do not stop there: hunt backward through your proxy and host telemetry, rotate every credential Metabase holds, and fix the architecture that made your instance reachable in the first place. The window between public disclosure and mass scanning for Metabase-class bugs is measured in hours.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub