CVE-2026-72898: Metabase SQL Injection and KEV Risk

CVE-2026-72898 is not another theoretical SQL injection finding that can be placed into a normal quarterly patch queue. It is a critical, unauthenticated Metabase SQL injection vulnerability with a CVSS v3.1 score of 10.0, confirmed active exploitation, and inclusion in the CISA Known Exploited Vulnerabilities catalog. Metabase disclosed the security incident on August 6, 2026, after discovering that its Cloud environment had been attacked using what was, at the time, an unknown zero-day vulnerability. CISA subsequently added CVE-2026-72898 to KEV on August 11, 2026. (github.com)

The vulnerability is especially dangerous because Metabase often sits at an unusually sensitive trust boundary. It is not merely a web frontend. A Metabase deployment may hold application configuration, user and administrator information, API keys, and credentials that allow it to connect to business databases or data warehouses. Successful exploitation can therefore turn compromise of the analytics layer into access to a much larger data environment.

Metabase states that CVE-2026-72898 allows a remote unauthenticated attacker to inject arbitrary SQL into the Metabase application database, potentially obtaining administrator access to the Metabase instance. From there, the attacker may be able to modify application configuration, steal stored credentials for connected databases, read data available through those database connections, and export data. (ギットハブ)

That distinction matters. CVE-2026-72898 should not be inaccurately described as an unauthenticated endpoint that directly provides arbitrary SQL execution against every production database connected to Metabase. The initial SQL injection targets the application database. The wider enterprise-data risk emerges after that injection enables administrator-level compromise and access to credentials and capabilities already trusted by Metabase.

CVE-2026-72898 at a Glance

属性	CVE-2026-72898
製品	Metabase
脆弱性	Unauthenticated SQL injection
Affected endpoint	/api/session/reset_password
Authentication required	いいえ
User interaction	いいえ
攻撃ベクトル	ネットワーク
Attack complexity	低い
CVSS v3.1	10.0 Critical
CVSS vector	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
主な影響	SQL injection into Metabase application DB and potential administrator access
Active exploitation	Confirmed by Metabase
CISA KEV	はい
KEV addition	August 11, 2026
CISA due date	August 14, 2026
Temporary workaround	Block /api/session/reset_password
Cloud status	Metabase says Cloud customers have already been patched

The upstream GitHub security advisory gives CVE-2026-72898 the maximum CVSS 3.1 score of 10.0. Its vector reflects the unusually favorable conditions from an attacker’s perspective: the attack is network accessible, low complexity, requires neither credentials nor victim interaction, and can lead to high confidentiality, integrity, and availability impact across a changed security scope. (ギットハブ)

What Is CVE-2026-72898?

CVE-2026-72898 is a SQL injection vulnerability exposed through Metabase’s password-reset functionality.

The affected route is:

POST /api/session/reset_password

The endpoint can be reachable before authentication, which is one of the characteristics that makes the vulnerability so serious. An attacker capable of reaching a vulnerable Metabase web interface does not first need to compromise an ordinary account.

According to Metabase’s security advisory, exploitation can cause attacker-controlled SQL to reach the Metabase application database. Successful exploitation can then provide administrator access to the application. (ギットハブ)

Conceptually, the security boundary looks like this:

Internet
   |
   v
Metabase Web/API
   |
   | unauthenticated request
   v
/api/session/reset_password
   |
   | vulnerable SQL handling
   v
Metabase Application Database
   |
   | administrator-level compromise
   v
Metabase Administration
   |
   +-----------------------+
   |                       |
   v                       v
Stored credentials      API keys / configuration
   |
   v
Connected databases and data warehouses

The final stages are what make the flaw operationally dangerous.

An analytics application may legitimately possess access to high-value databases. If the application itself is taken over, an attacker does not necessarily need a second vulnerability in those databases. Existing credentials and permissions can become the attack path.

CVE-2026-72898 Was Exploited as a Zero-Day

The exploitation status is one of the most important facts surrounding CVE-2026-72898.

On August 6, 2026, Metabase disclosed that its Cloud platform had been attacked using an unknown zero-day affecting versions 1.58 and above. Metabase said it blocked the endpoints involved, identified the vulnerability, and deployed a patch. The company also confirmed in its GitHub advisory that CVE-2026-72898 had been actively exploited. (metabase.com)

This changes how vulnerability teams should prioritize the issue.

A traditional vulnerability-management workflow might consider:

CVSS
+
asset criticality
+
internet exposure
+
patch availability

CVE-2026-72898 adds another much stronger signal:

confirmed exploitation

This is no longer primarily a question of whether attackers 可能性がある exploit the weakness.

They already have.

CISA Added CVE-2026-72898 to the KEV Catalog

On August 11, 2026, CISA added CVE-2026-72898 to its Known Exploited Vulnerabilities Catalog based on evidence of exploitation. The KEV catalog describes the issue as a Metabase SQL injection vulnerability allowing an unauthenticated attacker to inject arbitrary SQL and obtain administrator access. (cisa.gov)

CISA lists a remediation due date of:

August 14, 2026. (cisa.gov)

For organizations directly subject to CISA’s KEV remediation requirements, that date has operational significance. For everyone else, KEV inclusion should still be treated as a strong prioritization signal because it separates vulnerabilities with evidence of real exploitation from the much larger population of disclosed CVEs.

The combination here is unusually severe:

CVSS 10.0 + unauthenticated network access + zero user interaction + confirmed exploitation + KEV listing + direct access to a data-management platform.

That is enough to justify emergency remediation for exposed deployments.

Which Metabase Versions Are Vulnerable?

Metabase’s August 6 security notice provides the clearest operational approach: users on the affected 58 through 63 release branches should update to at least the minimum safe point release for their branch.

Metabase branch	Minimum safe release
63	0.63.5
62	0.62.9
61	0.61.11
60	0.60.17
59	0.59.21
58	0.58.24

Metabase says releases below version 58 are not affected by this vulnerability. It also states that customers running Metabase Cloud have already been upgraded and patched. (metabase.com)

For Enterprise installations that use the 1.x version prefix, administrators should use the corresponding patched Enterprise release for the same branch. The upstream GitHub advisory provides patched releases across x.58 through x.63. (ギットハブ)

The safest operational rule is therefore simple:

Do not rely on remembering a complicated vulnerable-version range. Determine the branch you run and make sure the deployed point release is at least the vendor’s minimum safe release.

例えば、こうだ：

0.58.x  -> 0.58.24 or later
0.59.x  -> 0.59.21 or later
0.60.x  -> 0.60.17 or later
0.61.x  -> 0.61.11 or later
0.62.x  -> 0.62.9 or later
0.63.x  -> 0.63.5 or later

These minimum safe releases come directly from Metabase’s security update. (metabase.com)

Why a Metabase SQL Injection Can Become a Data-Breach Problem

It is easy to underestimate CVE-2026-72898 by focusing only on the vulnerability class.

SQL injection is old.

The architecture surrounding this SQL injection is what makes the vulnerability modern and dangerous.

Metabase is designed to connect analytics users to data. Those connections can involve credentials and permissions that are significantly more valuable than the Metabase web application’s own data.

Metabase explicitly warns that administrator compromise following exploitation could allow attackers to steal stored credentials for connected databases, read any data that those connections can access, and export data. (ギットハブ)

A realistic impact chain therefore looks like:

CVE-2026-72898
      |
      v
Unauthenticated SQL injection
      |
      v
Metabase application database manipulation
      |
      v
Administrator access
      |
      +--> Configuration changes
      |
      +--> Unexpected administrator accounts
      |
      +--> API-key abuse
      |
      +--> Connected-database credential exposure
      |
      v
Access to data available through Metabase connections
      |
      v
Potential data theft / export

This is why remediation teams should inventory not only the vulnerable Metabase server, but also what that Metabase instance can reach.

A development Metabase instance connected only to synthetic test data and a production-facing analytics server containing credentials to customer or financial databases do not have the same business impact, even though both may technically contain the vulnerable code.

Internet Exposure Makes the Risk Worse

The attack requires network access to the vulnerable application endpoint, not prior authentication. The official CVSS vector therefore assigns:

AV:N
AC:L
PR:N
UI:N

That means network attack vector, low attack complexity, no privileges required, and no user interaction required. (ギットハブ)

An internet-accessible vulnerable Metabase server consequently deserves the highest remediation priority.

But private networking should not be treated as equivalent to patching.

An internally reachable Metabase instance can still become relevant after an attacker compromises another endpoint, VPN account, workstation, cloud workload, or service inside the trusted environment. Network restriction decreases exposure; it does not remove the vulnerable code path.

How to Detect Possible CVE-2026-72898 Exploitation

Metabase published an unusually useful attack pattern for defenders.

The company says observed attack behavior looks like:

POST /api/session/reset_password
HTTP status: 400

followed by:

GET /api/user/current
HTTP status: 200

Metabase states that finding this pattern in application or ingress logs means the instance is likely compromised. (metabase.com)

That is valuable because the first request alone might appear to represent a failed operation.

A 400 バッドリクエスト can easily be ignored by generic monitoring.

The meaningful security signal is the transition:

password reset request -> apparently unsuccessful
                         |
                         v
                  HTTP 400
                         |
                         v
            authenticated-user request
                         |
                         v
                  HTTP 200

The sequence is more important than either event alone.

Basic Log Hunting

For authorized defensive investigation, defenders can begin with straightforward searches such as:

grep '/api/session/reset_password' access.log
grep '/api/user/current' access.log

The next step is to correlate requests by source IP and timestamp.

A simplified investigation workflow would be:

1. Find POST requests to /api/session/reset_password
2. Identify requests returning HTTP 400
3. Record source IP and timestamp
4. Search shortly afterward for /api/user/current
5. Identify HTTP 200 responses from the same source
6. Correlate with new sessions, admins, API keys and queries

The objective is not merely to count endpoint requests.

It is to identify the suspicious authentication transition described by Metabase.

Do Not Treat Absence of the Published Pattern as Proof of Safety

The vendor-provided pattern is a high-value indicator, but defensive teams should avoid turning one indicator into an exhaustive definition of exploitation.

An incident investigation should also examine the application state that an attacker could modify after obtaining administrator access.

Metabase specifically recommends reviewing:

• active sessions,
• API keys,
• administrator accounts,
• connected-database credentials,
• warehouse access logs,
• Metabase activity and query history. (ギットハブ)

Those are post-compromise artifacts.

The logic is important:

No known request sequence found
           !=
Proof that compromise never occurred

Logs may be incomplete, expired, stored elsewhere, or lack sufficient correlation fields.

For exposed vulnerable systems, patching plus compromise assessment is stronger than patching plus a single grep command.

Emergency Workaround for CVE-2026-72898

If upgrading cannot happen immediately, Metabase recommends temporarily blocking:

/api/session/reset_password

The vendor explicitly describes this as a temporary workaround, not a replacement for updating. (ギットハブ)

A reverse proxy can, for example, temporarily deny the route while the actual upgrade is prepared.

Conceptually:

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

The exact configuration must be adapted to the organization’s proxy, load balancer, WAF, ingress controller, or service mesh.

Blocking the endpoint reduces exposure to the known vulnerable path, but it comes with an obvious operational consequence: legitimate password-reset behavior relying on that endpoint may stop functioning.

More importantly, the workaround does nothing to remove any attacker access obtained 以前 the block was deployed.

Why Patching CVE-2026-72898 Is Not Enough

This is one of the most important lessons from the Metabase advisory.

For many vulnerabilities, installing a fixed version closes the vulnerable code path and completes most of the response.

CVE-2026-72898 is different because exploitation may already have created persistent security consequences.

Metabase recommends organizations whose password-reset endpoint was publicly accessible take several actions after upgrading. (metabase.com)

Revoke Active User Sessions

Metabase advises deleting rows from the core_session table in the Metabase application database to invalidate active sessions. (metabase.com)

The security reasoning is straightforward.

If an attacker acquired a valid administrative session before the server was patched, fixing the SQL injection does not necessarily invalidate that already-created session.

Audit API Keys

Review existing API keys and remove keys that cannot be attributed to legitimate users or integrations. Metabase explicitly includes this step in its remediation guidance. (ギットハブ)

An attacker who obtains administrator access may attempt to convert transient exploitation into persistent application access.

Review Administrator Accounts

Look for:

unexpected administrators
recently promoted users
new accounts
changed administrator details
unexplained authentication activity

Metabase specifically recommends checking administrator accounts for unexpected changes. (metabase.com)

Rotate Connected Database Credentials

This is critical.

If a vulnerable Metabase deployment stored credentials that an attacker could have accessed, the database password should be treated as potentially compromised even after the Metabase software itself has been fixed.

Metabase explicitly instructs affected organizations to rotate credentials for connected databases. (ギットハブ)

This turns remediation from:

patch Metabase

into:

patch Metabase
+
remove attacker sessions
+
remove persistence
+
rotate downstream secrets
+
investigate downstream access

That is a much more accurate representation of CVE-2026-72898 response.

Review the Data Warehouse, Not Just the Metabase Server

Metabase also advises reviewing data-warehouse logs for signs of unauthorized access. (metabase.com)

That recommendation reflects an important architectural reality.

After application compromise, the security incident can cross the boundary between:

Metabase logs

and:

database / warehouse logs

Suppose a Metabase service identity normally performs predictable analytics queries during business hours.

After suspected CVE-2026-72898 exploitation, defenders should consider investigating deviations such as unusually broad queries, abnormal export activity, unexpected access times, changes in data-access patterns, or queries inconsistent with historical Metabase usage.

Not every abnormal query proves exploitation.

The purpose is correlation.

A strong investigation connects:

web request
   ->
Metabase session
   ->
administrator activity
   ->
database connection
   ->
warehouse query
   ->
data access

That evidence chain is much more valuable than simply recording that the vulnerable package existed.

Vulnerability Scanning Versus CVE Verification

CVE-2026-72898 also illustrates the difference between vulnerability identification and actual security validation.

A scanner may determine:

Metabase detected
+
version appears vulnerable
=
CVE-2026-72898 finding

That is useful for rapid inventory.

But during remediation, security teams usually need answers to several separate questions:

Was the vulnerable service actually exposed?

Was the affected endpoint reachable?

Has the application been patched?

Is the endpoint still exposed unnecessarily?

Did suspicious activity occur before the patch?

Were attacker-controlled sessions or credentials created?

Were downstream database credentials potentially exposed?

Does the patched deployment resist the previously affected behavior?

These are verification questions rather than simple detection questions.

Penligent’s public material describes an agentic penetration-testing workflow focused on CVE validation, tool-driven testing, evidence collection, and operator-controlled execution. In an authorized CVE-2026-72898 assessment, that kind of workflow is most useful for organizing exposure checks, confirming patch state, collecting HTTP and version evidence, and preserving remediation results rather than simply producing another vulnerability alert. (寡黙)

For an actively exploited KEV vulnerability, the distinction matters. The operational goal should be:

Discover -> Verify -> Remediate -> Retest -> Preserve Evidence

not:

Scan -> Generate Ticket -> Assume Closed

A Safe CVE-2026-72898 Validation Workflow

Security teams performing authorized testing can structure the work in four phases.

Phase 1: Identify Metabase Assets

Inventory:

internet-facing Metabase systems
internal Metabase systems
containerized deployments
cloud workloads
reverse-proxy routes
old staging deployments
forgotten analytics environments

Do not limit discovery to the primary production domain.

Analytics platforms are frequently deployed on separate hostnames or subdomains.

Phase 2: Determine Version and Patch State

For each instance, identify the actual running release and compare it with Metabase’s minimum safe version for the appropriate branch. (metabase.com)

A clean asset record might look like:

Host: analytics.example.com
Product: Metabase
Branch: 62
Observed version: 0.62.x
Required minimum: 0.62.9
Internet reachable: Yes
Reset endpoint exposed: Yes/No
Patch status: Vulnerable / Patched / Unknown

Unknown should not silently become safe.

Phase 3: Investigate Historical Exposure

If the system was vulnerable and reachable before remediation, inspect historical logs.

Look specifically for the vendor-published sequence involving:

POST /api/session/reset_password -> 400
GET  /api/user/current           -> 200

and correlate it with application and warehouse activity. (metabase.com)

Phase 4: Retest After Remediation

After patching:

verify deployed version
verify old containers were replaced
verify load-balanced nodes are all patched
verify rollback images are controlled
verify temporary proxy rules behave as intended
review active sessions
review administrator state
review API keys
confirm credential rotation
preserve evidence

This is particularly important in orchestrated environments.

Updating one container image does not prove that every running replica uses it.

CVE-2026-72898 and the Problem With Version-Only Remediation

Suppose an organization has ten Metabase instances.

A vulnerability scanner finds seven affected versions.

The organization upgrades all seven.

The vulnerability dashboard becomes green.

Yet one of those servers had been publicly exploitable for several days while active exploitation was occurring.

From a patch-management perspective, the vulnerability is fixed.

From an incident-response perspective, the work may just be starting.

That is the broader lesson of CISA KEV vulnerabilities.

Once exploitation is known to be occurring, organizations need to answer two different questions:

Are we vulnerable now?

and:

Were we compromised while we were vulnerable?

CVE-2026-72898 makes the distinction especially important because the attacker may obtain administrator access and potentially access secrets that remain valid independently of the vulnerable code path. (ギットハブ)

Security Teams Should Prioritize Based on Reachability and Data Access

Not every Metabase deployment has identical business impact.

A useful prioritization model for CVE-2026-72898 is:

Priority =
Known exploitation
×
Internet reachability
×
Vulnerable version
×
Endpoint reachability
×
Downstream data sensitivity
×
Credential privilege

The first factor is already established: exploitation is known.

That means the remaining variables should help determine which vulnerable Metabase instance gets handled first, not whether remediation is necessary.

An internet-facing analytics server connected to production customer data should be treated as an emergency.

An isolated laboratory server containing no real data still needs updating, but the potential downstream impact is dramatically lower.

Why Least-Privilege Database Accounts Matter

CVE-2026-72898 is also a reminder that database permissions determine blast radius.

Metabase warns that attackers obtaining administrative control may be able to read data accessible through connected database credentials. (ギットハブ)

The phrase accessible through those connections is important.

If the Metabase database user has unrestricted access to an entire production environment, compromise can expose a much larger dataset.

If it has only the minimum read permissions required for specific analytics schemas, the potential blast radius is more constrained.

Organizations should therefore review:

Which database identities does Metabase use?

Are they shared with other applications?

Can they write data?

Can they create objects?

Can they administer the database?

Which schemas can they read?

Are production credentials reused in staging?

How quickly can those credentials be rotated?

CVE remediation should not require a redesign of the entire analytics architecture before patching.

Patch first.

But the incident provides a useful opportunity to determine whether the analytics tier has accumulated excessive privileges.

Metabase Cloud Versus Self-Hosted Metabase

Metabase states that its Cloud environment was attacked with the zero-day and that Cloud customers were subsequently upgraded and patched. (metabase.com)

Self-hosted users have a different responsibility.

Their exposure depends on the versions they deployed and whether they applied the vendor’s security releases.

This distinction is particularly important for asset inventory.

A security team should not simply ask:

“Do we use Metabase?”

It should ask:

“Do we operate any self-hosted Metabase instances, which versions are running, and which networks can reach them?”

Cloud and self-hosted deployments require different response actions.

CVE-2026-72898 Versus Ordinary SQL Injection Findings

SQL injection vulnerabilities vary enormously in operational impact.

Consider three hypothetical cases.

Case A: Authenticated Low-Privilege SQL Injection

Authentication required
Limited database permissions
Internal application
No known exploitation

Serious, but normal prioritization may be appropriate.

Case B: Internet-Facing Unauthenticated SQL Injection

No authentication
Public service
Sensitive database
No known exploitation

Critical and urgent.

CVE-2026-72898

No authentication
Network exploitable
Low complexity
No interaction
Potential administrator compromise
Stored database credentials at risk
Connected data potentially accessible
Confirmed exploitation
CISA KEV
CVSS 10.0

That combination explains why treating CVE-2026-72898 as simply another CWE-style SQL injection ticket would miss the real risk.

What Security Teams Should Do Now

For organizations operating Metabase, the immediate priority is to identify all affected self-hosted instances and upgrade them to at least the official minimum safe release for their branch. Metabase Cloud customers have already been patched by the vendor. (metabase.com)

If an upgrade truly cannot be deployed immediately, block /api/session/reset_password as a temporary control. (ギットハブ)

For systems that were publicly accessible while vulnerable, assume that patching alone is insufficient. Revoke sessions, inspect API keys and administrator accounts, rotate database credentials, and analyze Metabase and data-warehouse logs as recommended by Metabase. (metabase.com)

Most importantly, preserve evidence.

For an actively exploited vulnerability, the goal is not merely to prove that the new version is installed.

The goal is to establish:

What was exposed?
For how long?
Was exploitation observed?
What privileges could have been obtained?
Which secrets were reachable?
Which downstream databases were accessible?
Were those credentials rotated?
Was the fixed state independently verified?

Those answers determine whether CVE-2026-72898 remains a vulnerability-management event or becomes an incident-response investigation.

CVE-2026-72898 FAQ

Is CVE-2026-72898 actively exploited?

Yes. Metabase explicitly states that it has confirmed active exploitation of the vulnerability. The company disclosed the issue after detecting an attack against Metabase Cloud involving what was then an unknown zero-day. (ギットハブ)

Is CVE-2026-72898 in CISA KEV?

Yes. CISA added CVE-2026-72898 to the Known Exploited Vulnerabilities Catalog on August 11, 2026. (cisa.gov)

What is the CVE-2026-72898 KEV due date?

CISA lists August 14, 2026 as the due date for CVE-2026-72898. (cisa.gov)

What is the CVSS score for CVE-2026-72898?

The Metabase GitHub security advisory assigns CVE-2026-72898 a CVSS v3.1 score of 10.0 Critical with the vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

(ギットハブ)

Does CVE-2026-72898 require authentication?

No. The upstream advisory describes the vulnerability as remotely exploitable without authentication. (ギットハブ)

Does CVE-2026-72898 require user interaction?

No. The CVSS vector specifies UI:N, meaning no user interaction is required. (ギットハブ)

Which endpoint is vulnerable?

The affected password-reset route is:

/api/session/reset_password

Metabase recommends temporarily blocking this endpoint when immediate upgrading is impossible. (ギットハブ)

What versions fix CVE-2026-72898?

Metabase lists the following minimum safe releases:

0.58.24
0.59.21
0.60.17
0.61.11
0.62.9
0.63.5

Organizations should use the corresponding fixed release for their Metabase branch and edition. (metabase.com)

Are Metabase versions older than 58 vulnerable?

Metabase states that versions below version 58 are not vulnerable to this issue. (metabase.com)

Are Metabase Cloud customers vulnerable now?

Metabase states that its Cloud environment was attacked during the zero-day incident but that Cloud customers have already been upgraded and patched. (metabase.com)

How can defenders detect exploitation?

Metabase identifies a particularly important sequence:

POST /api/session/reset_password -> HTTP 400
GET /api/user/current            -> HTTP 200

The vendor says observing this pattern in Metabase application or ingress logs indicates that the instance is likely compromised. (metabase.com)

Is upgrading Metabase enough after exposure?

Not necessarily.

If the vulnerable endpoint was publicly accessible, Metabase recommends revoking active sessions, reviewing API keys and administrators, rotating credentials for connected databases, and examining warehouse logs and Metabase activity for unauthorized behavior. (ギットハブ)

結論

CVE-2026-72898 should be treated as an emergency Metabase vulnerability, not a routine SQL injection ticket.

The technical ingredients already justify that conclusion: remote network exploitation, no required authentication, no user interaction, low attack complexity, administrator compromise, and a CVSS score of 10.0. The operational evidence makes the case even stronger: Metabase discovered the flaw through a real zero-day attack, confirmed active exploitation, and CISA subsequently added it to the Known Exploited Vulnerabilities Catalog. (github.com)

Organizations running self-hosted Metabase should immediately identify their deployed branches and upgrade to the minimum safe release published by Metabase. Systems that were exposed while vulnerable should also undergo compromise assessment rather than being considered clean solely because the package version changed.

The most important security lesson extends beyond Metabase.

When a business-intelligence platform is compromised, the application should not be viewed in isolation. Its database credentials, trusted connections, administrator privileges, APIs, and access to enterprise data turn it into part of the organization’s data-security boundary.

For CVE-2026-72898, therefore, successful remediation means more than:

“We installed the patch.”

It means:

“We removed the vulnerability, investigated the exposure window, invalidated potentially compromised trust, rotated downstream secrets, and verified that the environment is clean.” (metabase.com)