Contribution
This post adds a detection chain that the individual advisories do not spell out: join the Metabase exploit fingerprint to changes inside the analytics application, then follow the affected database identity into warehouse audit logs. The contribution is a portable three-stage correlation that separates an exploit attempt from administrator takeover, credential theft and data collection, while preserving useful evidence when one logging layer is missing.
The pattern
Metabase disclosed on 6 August 2026 that an attacker had exploited an unknown vulnerability in Metabase Cloud and that self-hosted releases in the 58 through 63 branches were also affected. The Metabase security update says the vulnerable unauthenticated endpoint allowed arbitrary SQL injection against the application's own database. That distinction matters. The first database reached is not necessarily the customer's warehouse. It is the application database that holds Metabase configuration, sessions, accounts and connection details.
The resulting chain is much more serious than a bad query against an analytics dashboard. Arbitrary SQL against the application database can give the attacker administrator access to Metabase. An administrator can inspect connected databases, run questions against data visible to those connections and export results. Metabase also warns that the attacker could steal stored credentials for connected databases. Those credentials can outlive the web exploit and can be used outside Metabase, from infrastructure that produces no further requests to the vulnerable endpoint.
The GitHub security advisory GHSA-vwf4-m7j8-wcjf confirms active exploitation, now assigns CVE-2026-72898 and lists affected and fixed point releases. This remains an incident-led detection problem: a CVE identifier does not tell a responder whether an exposed instance was used. The vendor's minimum fixed releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5. Blocking the endpoint is a temporary measure, not a substitute for upgrading and investigating.
Metabase published one unusually useful exploit fingerprint. Its 6 August advisory and GHSA show POST /api/session/reset_password returning HTTP 400 followed by GET /api/user/current returning HTTP 200. The later vendor postmortem renders the first path as /api/session/password-reset. Because the two official records disagree, hunt both spellings and confirm the route emitted by the deployed version or ingress normalisation before productionising the detector. The first result looks like a failed request when viewed alone. The second shows that the caller has acquired a valid application context. A SOC that alerts only on successful requests will discard the strongest entry signal; a SOC that alerts on every 400 response will drown in client errors. The value lies in the ordered pair, on the same Metabase host and from the same source or request context within a short interval.
Public reporting supplies victim evidence for the next part of the chain. Framework customers discussed the company's breach notice, and BleepingComputer reported that Framework and Tally had disclosed data theft linked to the Metabase flaw. These reports do not prove that every exploited instance reached a warehouse, nor do they reveal one universal exfiltration query. They do show why patch confirmation alone is an incomplete response. The investigation boundary has to include the data sources trusted by Metabase.
Three evidence planes therefore matter. The ingress plane records the exploit sequence. The application plane records sessions, administrators, API keys, activity and query history. The warehouse plane records use of the connected database identities. Treating these as separate alerts creates three weak queues. Joining them around the first suspicious request turns them into an incident timeline.
Why it matters to cloud defenders
Metabase often sits between people and several high-value data systems. A single instance may hold connections to Amazon RDS, Aurora, Azure SQL, Cloud SQL, Snowflake or a self-managed warehouse. The application account commonly has broad read access because dashboards and saved questions span many tables. That makes an analytics service a practical collection broker: compromise one application, inherit its view of multiple repositories.
Cloud control-plane logs do not, by themselves, show the whole incident. AWS CloudTrail can record changes to an RDS instance, but it does not record the SQL statements sent through an existing database connection. Azure Activity Log covers resource operations, while Azure SQL auditing records selected database events. Google Cloud Audit Logs cover administrative operations on Cloud SQL; PostgreSQL statement auditing needs pgAudit. A clean cloud control-plane trail therefore does not clear the database identity used by Metabase.
The reverse is also true. A burst of SELECT statements under the normal Metabase database user may resemble ordinary dashboard activity. Warehouse telemetry becomes useful when it is anchored to the exploit time and compared with that identity's established behaviour. The useful questions are concrete: Did the Metabase user connect from a new client address? Did it query schemas not seen in its normal dashboard workload? Did result volume, statement count or session duration jump? Did access continue after Metabase sessions were revoked?
Credential rotation is part of containment because a stolen connection secret breaks the assumption that all activity comes through the Metabase host. If investigators only search application query history, direct use of the same database credential can pass unseen. If they only search warehouse logs for an unknown account, the familiar Metabase user can be mistaken for expected service traffic. The join has to treat identity and network origin as separate dimensions.
This is cloud-relevant even when Metabase itself runs in a container or virtual machine outside the managed database service. The data plane still terminates in cloud databases, and the warehouse audit surface is where collection may survive after the exposed application is patched. Cloud defenders own that side of the boundary.
ATT&CK mapping
The entry maps to T1190, Exploit Public-Facing Application. An unauthenticated caller abuses an internet-facing Metabase endpoint and gains an application administrator context. The observable entry signal is the ordered POST 400 then GET 200 sequence, not a generic spike in web errors.
Credential access is a second, distinct step. Metabase says an administrator can steal stored credentials for connected databases. That behaviour fits T1555, Credentials from Password Stores, with the exact storage and protection mechanism dependent on the deployment. It should remain a hypothesis until application-database evidence, secret access records or direct use of a connected-database credential supports it. The incident report does not establish that every compromise included credential extraction.
The data payoff maps to T1213, Data from Information Repositories, more specifically its Databases sub-technique T1213.006. The repository is the connected warehouse rather than the Metabase application database. Collection can occur through Metabase questions and exports or through a direct database session using stolen credentials. Those paths need different evidence, but both end in reads from information repositories.
This end-to-end mapping avoids a common blind spot. T1190 answers how the attacker entered; it does not describe what they took. T1213 answers where the valuable data was collected; it does not identify the exploit. T1555 links the two when the application stores a reusable warehouse secret. The core detection chain therefore uses T1190 and T1213, while T1555 and T1213.006 sharpen the analysis when credential evidence and database-specific collection records exist.
Detection guidance
Start with an ingress correlation. Normalise reverse-proxy, load-balancer or Kubernetes ingress records to the fields below. Keep the raw event alongside the normalised record so analysts can recover headers and request identifiers without guessing what the parser dropped.
stage_1 = request where
method == "POST" and
path in ("/api/session/reset_password", "/api/session/password-reset") and
status == 400
stage_2 = request where
method == "GET" and
path == "/api/user/current" and
status == 200
alert when stage_2 occurs within 5 minutes after stage_1
on the same Metabase host
and with the same source IP, forwarded client IP, session cookie hash,
or request-chain identifier
The five-minute interval is an operator starting point, not a vendor claim. Replay known benign password-reset failures to measure the normal delay and identity fields in your environment. Alert at high priority when one stable request context links the pair. Keep a lower-confidence hunt for cases where the source changes but the Metabase host, user agent and timing line up, because proxies and attacker infrastructure can break a simple source-IP join.
Do not make the pair the only gate. Missing ingress logs, endpoint blocking or a changed exploit path can remove it. Build a second-stage hunt from the vendor's response guidance: inspect Metabase administrators, API keys, active sessions, activity records and query history for changes or use beginning at the earliest suspicious request. Compare against a known-good snapshot if one exists. Newly created or modified administrators and unrecognised API keys deserve immediate containment. Query and export activity is stronger when it targets a database or collection the principal has not used before.
Next, resolve every database connection configured in the affected instance to a warehouse identity. Record the database service, account name, expected Metabase egress addresses, permitted schemas and credential rotation time. This inventory is the bridge between the application incident and cloud telemetry. Without it, the SOC cannot distinguish normal dashboard traffic from direct use of a stolen credential.
For Amazon RDS and Aurora, collect engine audit or statement logs and publish supported database logs to CloudWatch Logs where appropriate. AWS documents that each engine produces its own log types, so the exact statement fields depend on PostgreSQL, MySQL, SQL Server, Oracle, MariaDB or Db2. Hunt for the Metabase account from a client address outside the approved application egress set. Within the incident window, rank sessions that read unusual schemas, run for much longer than the account's baseline or continue after credential rotation. CloudTrail remains useful for concurrent control-plane changes, but it cannot replace SQL auditing.
For Azure SQL Database, send auditing records to Log Analytics, Event Hubs or storage. Microsoft's auditing documentation states that the service records selected database events and can expose suspicious activity, while warning that very high activity or network load can leave gaps. Filter first on the Metabase database principal, then split its activity by client address and database. A new client address plus read activity on previously unused objects is a stronger signal than statement count alone. Preserve the possibility of missing audit events rather than treating silence as proof of no access.
For Cloud SQL for PostgreSQL, enable pgAudit before an incident and route its Data Access records to Cloud Logging. Google's Cloud SQL pgAudit guide documents the cloudsql_database resource, the cloudaudit.googleapis.com/data_access log and fields including auditClass, command, database, statement and user. The following filter finds recorded read operations by the Metabase identity; replace the account and project values with local values:
resource.type="cloudsql_database"
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access"
protoPayload.request.@type="type.googleapis.com/google.cloud.sql.audit.v1.PgAuditEntry"
protoPayload.request.auditClass="READ"
protoPayload.request.user="METABASE_DB_USER"
Group those records by database session and compare the statement set with normal dashboard queries. Flag access from an unexpected route or identity context using the surrounding connection logs. Google notes that pgAudit ingestion has capacity limits and that exhausted disk space can lose records, so an empty result must be paired with configuration and health evidence.
Across providers, use a simple incident score rather than one brittle signature. Raise severity when the ingress pair is present, when an administrator or API key changed, when the Metabase warehouse identity appears from a new origin, or when query scope departs from its baseline. Any two planes should trigger incident handling. All three support a high-confidence compromise finding. A warehouse-only anomaly still deserves review because stolen credentials can be used after web evidence has aged out.
False positives cluster around legitimate password recovery, planned administrator changes and scheduled analytical jobs. Suppress only after joining to change records and stable workload attributes. Do not suppress the vendor's request pair merely because the source belongs to a corporate proxy. Do not suppress a new warehouse origin merely because it uses the correct password. Correct credentials are part of the suspected path.
What to do now
Upgrade every affected Metabase deployment to a fixed release. If an emergency change cannot be made immediately, block the reset endpoint documented for the deployed version; until the vendor's two published spellings are reconciled, cover both
/api/session/reset_passwordand/api/session/password-resetat the edge and keep the incident investigation open.Search retained ingress logs for the vendor-published request sequence. Establish the earliest matching request, preserve the raw records and widen the time range around that point. Absence of the pair is not a clean bill if the endpoint was public or logs are incomplete.
Revoke active Metabase sessions, remove unrecognised API keys, inspect administrator accounts and review activity and query history. These actions come directly from the Metabase advisory. Capture evidence before destructive cleanup where incident policy allows.
Rotate every credential held by the affected instance for a connected database. Treat each old warehouse identity as exposed until its audit history has been reviewed. Where practical, replace shared passwords with narrowly scoped identities and restrict connections to approved Metabase egress addresses.
Search warehouse audit logs from the first possible exploit time through credential rotation. Look for the Metabase principal from new client origins, new databases or schemas, abnormal read volume and sessions continuing after application containment. Check audit configuration and ingestion health before interpreting a lack of records.
Keep the three evidence planes in one case. Record ingress matches, application changes and warehouse reads on a common timeline. That structure tells responders whether they stopped an exploit attempt, contained an application takeover or need to investigate data collection and direct credential use.