Metabase Unauthenticated SQL Injection → Admin Takeover (GHSA-vwf4-m7j8-wcjf / CVE-2026-72898)

Metabase, a widely deployed open-source business-intelligence and dashboarding tool, shipped a maximum-severity (CVSS 10.0) SQL injection flaw — tracked as GHSA-vwf4-m7j8-wcjf and, as confirmed directly from the GitHub advisory page on 2026-08-11, since assigned CVE-2026-72898 — in its unauthenticated POST /api/session/reset_password endpoint. The endpoint merges attacker-controlled JSON keys into an internal map without stripping an unexpected user-id field; when that field is supplied as a HoneySQL {:raw "..."} object it is compiled into literal, unparameterized SQL, giving a remote unauthenticated attacker blind SQL injection into the Metabase application database and, from there, the ability to mint a working administrator session. Every release from 1.58.0 through the 1.63.x branch is affected; fixed releases are 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9 and 1.63.5.

The flaw was exploited in the wild before public disclosure: Metabase itself disclosed that its own Metabase Cloud environment was attacked, and self-hosted customers Framework (laptop manufacturer), Tally (form builder), n8n (workflow automation — 136 customer records, 5 with bcrypt-hashed passwords), and Kilo Code (Slack access tokens for a subset of users) have all independently confirmed breaches traced to this vulnerability. Metabase's own CEO published the operative detection signature: a POST /api/session/reset_password call returning HTTP 400 immediately followed by a GET /api/user/current call returning HTTP 200 from the same client. That pattern is the single highest-fidelity indicator of exploitation, but it lives entirely in Metabase's own application log, a reverse proxy, or a WAF — it is not something a CrowdStrike Falcon sensor can see, because Falcon has no visibility into in-process HTTP request/response handling inside the Metabase JVM.

This pack is built around what Falcon can see on and around the host running Metabase: anomalous child processes of the Metabase Java process, outbound network activity following compromise (including cloud instance-metadata theft, a realistic follow-on given Metabase's role holding connected-database credentials), dropped web shells or backdoor artifacts, unexpected listening ports, and persistence attempts. No attacker-attributed file hashes, C2 domains, or source IPs have been publicly disclosed for this campaign as of 2026-08-11, so every detection here is behavioral rather than atomic-indicator based.

Defender priority: patching is necessary but not sufficient. Because the flaw grants full application-admin access, treat every unpatched, internet-reachable Metabase instance as presumed-compromised until you have rotated every connected-database credential it held, purged core_session, and audited admin accounts and API keys — the exploitation window opened well before public disclosure.

Web Hunter notes: No source reviewed — including the two technical deep-dives (Wiz, Resecurity) — published attacker infrastructure (C2 IPs, domains, malware hashes). Both technical write-ups describe the injection mechanism in prose only; this pack does not reproduce working exploit payloads, consistent with defensive-content-only scope. One CVE identifier discrepancy was resolved during research: the task brief stated "no CVE assigned," which was accurate as of the original Hacker News publication, but the GitHub advisory now lists CVE-2026-72898 — independently confirmed by directly fetching the advisory page text rather than trusting a single summarization pass.

Prompt-injection check (per operating instructions): all eight fetched sources were reviewed for text addressed to an AI agent/assistant. None was found in any of the eight snapshots saved to the sources folder for this pack. Nothing from fetched content was treated as an instruction.

Hypothesis set (ordered by fidelity):

1. H1 (high): A compromised Metabase Java process spawns an unexpected shell/interpreter child process for post-exploitation recon or command execution.
2. H2 (high): An attacker with admin-level Metabase access drops a web shell or backdoor script/binary on the host to maintain access beyond patching.
3. H3 (medium): A compromised Metabase host process queries the cloud instance metadata service to escalate from stolen application-DB credentials to cloud IAM credentials.
4. H4 (medium): A compromised Metabase host opens an unexpected listening port for a backdoor/reverse-shell channel.
5. H5 (medium): A compromised Metabase host makes outbound connections to non-standard external destinations consistent with data staging or exfiltration of connected-database contents.
6. H6 (low-medium): An attacker establishes scheduled-task/cron persistence on the Metabase host.
7. H7 (medium): Post-compromise reconnaissance for stored database credentials or cloud credential files/environment variables on the Metabase host.

No attacker-attributed file hashes, C2 domains, or source IP addresses have been publicly disclosed for this campaign as of 2026-08-11. This threat is behavioral-only at the atomic-indicator level; the table below lists version fingerprints and the app-layer detection pattern rather than classic IOCs.

This is the single most important section of the pack. The vendor-published detection signature is an HTTP request/response pattern that CrowdStrike Falcon cannot see — it must be hunted in Metabase's own application log, a reverse proxy, a load balancer, or a WAF.

1. Primary exploitation signature (Metabase app log / reverse proxy / WAF / load-balancer access log)

Hunt for: POST /api/session/reset_password returning HTTP 400, followed within a short window by GET /api/user/current returning HTTP 200, from the same client IP or the same short-lived session. This is the pattern Metabase's own CEO called out as the operative compromise indicator. If request logging is not currently enabled on your Metabase deployment, enable it and forward it to your SIEM before doing anything else — without it, this entire attack class is invisible.

2. Metabase application audit log ("Admin > Audit log" / activity history)

Review for: new API key creation, new admin accounts, permission-group changes, and connected-database configuration edits in the days surrounding your earliest possible exposure date (treat the earliest of your patch date or 2026-08-01 as the start of the review window, since exploitation predates public disclosure).

3. core_session table review (Metabase application database)

Before purging core_session per the vendor remediation steps, export it for forensic review: look for session records with anomalous creation timestamps, unfamiliar source IPs, or sessions tied to admin accounts that were not actively used by legitimate staff.

4. Connected data-warehouse / database query logs

Review query logs for the Metabase service account for unusual export-style queries (large row counts, SELECT * against sensitive tables, queries outside normal business hours) in the exposure window.

5. Linux cron / systemd-timer persistence (Falcon coverage gap — supplement here)

Falcon's LogScale event model has no dedicated cron-file-write event (see Q6 and the Coverage Map for the equivalent host-based hunt and its limits). Supplement with a native auditd watch rule on /etc/cron.d/, /etc/cron.daily/, /var/spool/cron/, and /etc/systemd/system/*.timer, or a periodic file-integrity check against those paths.

All seven queries below hunt host and network telemetry around the Metabase server, not the SQL injection itself. Scope every query to your Metabase host group (by aid/ComputerName or a Falcon host group) before running — several are written broadly for portability and will be noisy run fleet-wide.

// HUNT: Unexpected child process of the Metabase Java process
// MITRE: T1190, T1059
// CONF: high
// FP: medium
// COST: low
// REQUIRES: ProcessRollup2, SyntheticProcessRollup2 on the Metabase host(s)
// FALSE POSITIVES: health-check wrapper scripts, backup jobs, or config-management agents co-located on the same host
// TUNING: exclude known deployment/orchestration parent-child chains for your Metabase image (e.g. container entrypoint scripts) after a benign baseline period; scope to your Metabase host group with aid/ComputerName before promoting to IOA
// LOOKBACK: 7d (set via console time picker)
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| ParentBaseFileName=/^java(\.exe)?$/i
| FileName=/^(sh|bash|dash|zsh|cmd|powershell|pwsh|python[0-9.]*|perl|curl|wget|nc|ncat|socat)(\.exe)?$/i
| table([aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, timestamp])

// HUNT: Metabase host outbound connection to a non-internal destination
// MITRE: T1041, T1071
// CONF: medium
// FP: high
// COST: medium
// REQUIRES: NetworkConnectIP4 on the Metabase host(s)
// FALSE POSITIVES: connections to legitimate connected data warehouses, SMTP relays, Slack/webhook integrations, and Metabase's own update/license checks
// TUNING: build an allowlist of expected outbound destinations (connected DB hosts, SMTP relay, integration endpoints) with in()/cidr() exclusions before alerting on this; best used as a pivot after Q1 or Q4 fires, not run standalone
// LOOKBACK: 7d (set via console time picker)
#event_simpleName=/NetworkConnectIP4/
| ContextBaseFileName=/^java(\.exe)?$/i
| !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","127.0.0.0/8","169.254.0.0/16","100.64.0.0/10"])
| table([aid, ComputerName, ContextBaseFileName, RemoteAddressIP4, RemotePort, LocalPort, timestamp])

// HUNT: Metabase process calling the cloud instance metadata service
// MITRE: T1552.005
// CONF: medium
// FP: medium
// COST: low
// REQUIRES: NetworkConnectIP4 on the Metabase host(s), cloud-hosted deployment
// FALSE POSITIVES: JDBC drivers or SDKs that legitimately resolve cloud-IAM database credentials via IMDS (e.g. IAM-authenticated RDS/Cloud SQL connectors)
// TUNING: if a specific connected-database driver legitimately calls IMDS, baseline and exclude that driver's known process/command-line signature rather than excluding the whole host
// LOOKBACK: 7d (set via console time picker)
#event_simpleName=/NetworkConnectIP4/
| ContextBaseFileName=/^java(\.exe)?$/i
| RemoteAddressIP4="169.254.169.254"
| table([aid, ComputerName, ContextBaseFileName, RemoteAddressIP4, RemotePort, timestamp])

// HUNT: New executable/script written by the Metabase process
// MITRE: T1505.003, T1105
// CONF: high
// FP: low
// COST: low
// REQUIRES: PeFileWritten, NewExecutableWritten, ELFFileWritten on the Metabase host(s)
// FALSE POSITIVES: legitimate JDBC/plugin driver JARs downloaded during normal Metabase driver installation
#event_simpleName=/PeFileWritten|NewExecutableWritten|ELFFileWritten/
| ContextBaseFileName=/^java(\.exe)?$/i
| table([aid, ComputerName, ContextBaseFileName, TargetFileName, SHA256HashData, timestamp])

// HUNT: Unexpected listening port on the Metabase host
// MITRE: T1071, T1572
// CONF: medium
// FP: medium
// COST: low
// REQUIRES: NetworkListenIP4 on the Metabase host(s)
// FALSE POSITIVES: JVM remote-debug (5005) or JMX/management ports intentionally opened by operations tooling
// TUNING: add your environment's actual Metabase listen port (default 3000, or 80/443/8080 if reverse-proxy fronted) plus any intentionally-open JVM debug/JMX ports to the exclusion list before promoting to IOA
// LOOKBACK: 7d (set via console time picker)
#event_simpleName=/NetworkListenIP4/
| ContextBaseFileName=/^java(\.exe)?$/i
| !in(LocalPort, values=["3000","8080","443","80"])
| table([aid, ComputerName, ContextBaseFileName, LocalPort, LocalAddressIP4, timestamp])

// HUNT: Scheduled task / service persistence on the Metabase host
// MITRE: T1053
// CONF: low
// FP: medium
// COST: low
// REQUIRES: ScheduledTaskRegistered, CreateService; host-scoped by ComputerName
// FALSE POSITIVES: routine patch/maintenance scheduled tasks, container-orchestrator health-check tasks
// TUNING: replace REPLACE_WITH_METABASE_HOSTNAME with your actual Metabase server hostname(s); this query has no Linux-cron equivalent in the Falcon event model -- pair it with the auditd hunt in Section 7 for full coverage
// LOOKBACK: 14d (set via console time picker)
#event_simpleName=/ScheduledTaskRegistered|CreateService/
| in(ComputerName, values=["REPLACE_WITH_METABASE_HOSTNAME"])
| table([aid, ComputerName, UserName, CommandLine, timestamp])

// HUNT: Credential/environment recon spawned from the Metabase process
// MITRE: T1552.001, T1518
// CONF: medium
// FP: medium
// COST: low
// REQUIRES: ProcessRollup2, SyntheticProcessRollup2 on the Metabase host(s)
// FALSE POSITIVES: legitimate ops/debugging sessions on the same host reviewing environment or credential configuration
// TUNING: exclude known admin/SRE tooling that legitimately reads environment variables on this host (e.g. a config-management agent's command-line signature)
// LOOKBACK: 7d (set via console time picker)
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| ParentBaseFileName=/^(sh|bash|dash|zsh|java)(\.exe)?$/i
| CommandLine=/(credentials|printenv|environ|GOOGLE_APPLICATION_CREDENTIALS|core_session|metabase\.db)/i
| table([aid, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine, timestamp])

Three queries are strong Custom IOA candidates once tuned against your own Metabase host baseline. The remaining four should stay Investigate-only given their FP profile.

Q2, Q5, Q6, and Q7 remain Investigate-only: Q2 and Q5 have high/medium FP that needs an environment-specific allowlist before alerting, and Q6/Q7 are best run as periodic hunts rather than always-on IOAs.

No attacker-attributed atomic indicators (hashes, C2 domains, source IPs) have been published for this campaign as of 2026-08-11. The CSV block below ships only placeholder rows for your own investigation findings; nothing in it is a real indicator. This pack's actual detection value is the behavioral signatures in the second block.

# No attacker-attributed file hashes, C2 domains, or IPs have been publicly
# disclosed for GHSA-vwf4-m7j8-wcjf / CVE-2026-72898 as of 2026-08-11.
# The rows below are placeholders for YOUR OWN incident-response findings --
# populate them from your Falcon/WAF/Metabase log investigation, do not
# invent values.
type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_SHA256,prevent,critical,2027-02-11,Metabase host post-exploitation artifact (webshell/backdoor),campaign:Metabase-GHSA-vwf4
domain,REPLACE_WITH_C2_DOMAIN,detect,high,2026-11-11,Suspected exfil/C2 destination observed from a compromised Metabase host,campaign:Metabase-GHSA-vwf4
ipv4,REPLACE_WITH_ATTACKER_IP,detect,high,2026-11-11,Suspected attacker source IP identified in Metabase app/WAF logs,campaign:Metabase-GHSA-vwf4

# PRIMARY exploitation signature -- Metabase app log / WAF / reverse-proxy
# access log ONLY. This is NOT visible in Falcon EDR telemetry.
POST /api/session/reset_password  -> HTTP 400
  immediately followed by (same client, short window)
GET  /api/user/current            -> HTTP 200

# Vulnerable version fingerprint -- query GET /api/session/properties
Vulnerable: 1.58.0-1.58.23, 1.59.0-1.59.20, 1.60.0-1.60.16,
            1.61.0-1.61.10, 1.62.0-1.62.8, 1.63.0-1.63.3
Patched:    1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9, 1.63.5

# Falcon-visible host-layer behaviors (see Q1-Q7 in Section 8)
- Shell/interpreter spawned as a direct child of the Metabase JVM
- Metabase JVM process reaching 169.254.169.254 (cloud instance metadata)
- New PE/ELF/script write events attributed to the Metabase JVM
- Unexpected listening port opened by the Metabase JVM
- New scheduled task/service on the Metabase host

GHSA:            GHSA-vwf4-m7j8-wcjf
CVE:             CVE-2026-72898
CVSS:            10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Vulnerable ep:   POST /api/session/reset_password
Root cause:      unvalidated "user-id" JSON key reaches HoneySQL as a
                 {:raw ...} raw-SQL directive, bypassing parameter binding
Vendor advisory: github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf
Vendor blog:     metabase.com/blog/security-update

[ ] Confirm current version via GET /api/session/properties
[ ] Upgrade to the fixed release for your branch
    (1.58.24 / 1.59.21 / 1.60.17 / 1.61.11 / 1.62.9 / 1.63.5)
[ ] Block POST /api/session/reset_password at the proxy/WAF until patched
[ ] Delete all rows in the core_session application-database table
[ ] Review and revoke unrecognized Metabase API keys
[ ] Audit administrator accounts for unauthorized creation/changes
[ ] Rotate every credential Metabase held for connected databases
[ ] Review connected data-warehouse access/query logs for the exposure window
[ ] Review Metabase activity history / audit log for anomalies
[ ] Run Q1, Q3, Q4 (Section 8) against the Metabase host for host-level compromise indicators

Playbook A — Emergency WAF/reverse-proxy block (nginx example)

location = /api/session/reset_password {
    deny all;
    return 403;
}

Prerequisites: a reverse proxy (nginx or equivalent) sits in front of Metabase; ability to reload its configuration.
Reboot required: no — nginx -s reload applies it live.
Rollback: remove the location block and reload; only do this after confirming the instance is patched to a fixed version.

Playbook B — Enforce IMDSv2 (AWS CLI example)

aws ec2 modify-instance-metadata-options \
  --instance-id REPLACE_WITH_INSTANCE_ID \
  --http-tokens required \
  --http-put-response-hop-limit 1 \
  --http-endpoint enabled

Prerequisites: AWS CLI configured with ec2:ModifyInstanceMetadataOptions permission; confirm no application code on the instance still calls IMDSv1 without a session token.
Reboot required: no.
Rollback: aws ec2 modify-instance-metadata-options --instance-id REPLACE_WITH_INSTANCE_ID --http-tokens optional restores IMDSv1 compatibility if a legacy integration breaks.

Playbook C — Session purge (Metabase application database)

-- Run against the Metabase APPLICATION database only
-- (never a connected data-source database).
DELETE FROM core_session;

Prerequisites: direct admin access to the Metabase application database; export the table for forensic review first (Section 7); put Metabase into maintenance mode to avoid races during the delete.
Reboot required: restart the Metabase application process afterward to clear in-memory session caches.
Rollback: none required — this only invalidates existing sessions; legitimate users simply re-authenticate.

Playbook D — Container hardening (docker-compose example)

# docker-compose.yml
services:
  metabase:
    image: metabase/metabase:REPLACE_WITH_PATCHED_TAG
    read_only: true
    user: "2000:2000"
    cap_drop: ["ALL"]
    tmpfs: ["/tmp"]

Prerequisites: confirm the patched Metabase image tolerates a read-only root filesystem (mount a writable tmpfs for its plugins/temp directories); test in staging before production.
Reboot required: container recreate (docker compose up -d).
Rollback: revert to the previous compose file (remove the read_only/user/cap_drop lines) and recreate the container.

Validation gate status (full detail in Section 11): telemetry readiness must be confirmed per host, Q1/Q2/Q5 require a benign baseline before promotion, and Q1/Q3/Q4 are the only queries currently recommended for Custom IOA promotion.

Verbatim extracted-text snapshots of all eight sources are saved alongside this pack in Metabase-GHSA-vwf4-SQLi-Hunt-sources/ for provenance verification.