CVE-2026-72898 is a critical, actively exploited SQL injection vulnerability in Metabase that can allow a remote, unauthenticated attacker to take control of a vulnerable Metabase instance. The flaw resides in the application’s password-reset functionality and can be exploited without valid credentials or user interaction.
The vulnerability carries a CVSS 10.0 severity rating and has been added to the U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities (KEV) catalog. CISA’s assessment classifies exploitation as active, automatable and capable of producing total technical impact.
Metabase has confirmed active exploitation and released patched versions across its supported release branches. The vendor warns that successful exploitation can give attackers administrator access to the Metabase application, exposing connected database credentials, saved queries and business data.
For organizations running self-hosted Metabase, this is not a vulnerability that should be treated as a routine patching exercise. Any internet-accessible vulnerable deployment should be considered potentially exposed until its version, logs, administrator accounts, sessions, API keys and connected data sources have been reviewed.
What Is CVE-2026-72898?
CVE-2026-72898 is an unauthenticated SQL injection vulnerability in Metabase’s password-reset endpoint.
The affected functionality is exposed through:
/api/session/reset_password
The core security problem is that an attacker can reach this functionality without first authenticating to Metabase and manipulate data supplied to the password-reset workflow in a way that ultimately reaches the application’s database layer as SQL-related input.
According to security research into the vulnerability, the attack chain involves insufficient validation of additional request fields, unsafe handling of those fields during the authentication workflow and database processing that can interpret attacker-controlled structures as expressions rather than treating them strictly as ordinary values.
A password-reset endpoint normally represents a relatively narrow authentication function. It should accept a tightly controlled set of values, perform the reset operation and return a response. In the vulnerable implementation, however, attacker-controlled input could cross boundaries between request processing, application state and database query construction.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →The result is a pre-authentication SQL injection primitive against the Metabase application database.
The official Metabase security advisory classifies the vulnerability as critical and confirms that exploitation can lead to administrator access.
Why the Vulnerability Is So Dangerous
SQL injection is not automatically equivalent to complete system compromise. The severity of CVE-2026-72898 comes from the combination of several factors.
First, the vulnerable endpoint does not require authentication. An attacker does not need an existing Metabase account, administrator privileges or a stolen session.
Second, exploitation can target the application database, which contains information fundamental to Metabase’s operation, including account and session information and configuration data.
Third, successful exploitation can result in administrator-level access to the Metabase instance. Metabase’s own advisory warns that attackers with this level of access can potentially modify application configuration, obtain credentials associated with connected databases, access data available through those connections and export information.
This creates an important security boundary problem.
Metabase is not simply another web application. It frequently sits between users and organizational databases, data warehouses and analytics infrastructure. A compromise of the BI layer can therefore become a stepping stone toward compromise or unauthorized access to the data platforms behind it.
That makes CVE-2026-72898 particularly serious for organizations where Metabase has connections to production databases, customer information, financial systems, internal analytics platforms or sensitive business intelligence.
How CVE-2026-72898 Works
At a high level, exploitation begins with an attacker interacting with the unauthenticated password-reset API.
The vulnerable request is sent to the Metabase session-reset functionality. Instead of supplying only the expected password-reset information, an attacker can manipulate the structure of the request so that additional attacker-controlled data reaches the application’s internal processing pipeline.
Security researchers have described three important elements in the vulnerable flow.
1. Insufficient request validation
The endpoint accepts additional fields that should not influence the password-reset operation. This creates an opportunity for attacker-controlled structures to survive further into the application.
2. Unsafe state handling
Those unexpected fields can become part of the application’s internal state during processing rather than being discarded at the API boundary.
This is significant because security controls are often strongest at the outer edge of an application. If unexpected data is allowed to travel deeper into authentication and database logic, assumptions made by downstream components can become security vulnerabilities.
3. Unsafe database interpretation
The final problem occurs when attacker-controlled structures reach database query construction.
Instead of being handled exclusively as scalar values, the input can be interpreted in a manner that permits SQL injection against the Metabase application database.
The resulting attack does not require the attacker to first bypass Metabase authentication. The SQL injection itself provides the mechanism for manipulating the application’s underlying state.
This is why the vulnerability is best understood as a pre-authentication SQL injection leading to administrative compromise, rather than simply a password-reset bug.
From SQL Injection to Administrator Access
The most important consequence is the ability to manipulate Metabase’s internal application state.
A successful attacker can potentially alter information associated with users, sessions or administrative privileges. This can turn an unauthenticated request into an authenticated administrative foothold.
Once administrative access has been obtained, the attacker is no longer limited to the original SQL injection vulnerability.
The Metabase administrative interface becomes a high-value control plane.
Depending on the permissions and database connections configured by the victim organization, an attacker may be able to inspect or modify application configuration, access saved queries, interact with connected databases, obtain connection credentials and extract data accessible through Metabase. Metabase explicitly warns that successful exploitation can expose stored credentials and data available through connected database systems.
This creates a potentially devastating attack path:
Internet exposure → unauthenticated password-reset endpoint → SQL injection → application-state manipulation → administrator access → access to connected data sources
The downstream impact depends on how Metabase was deployed and what privileges its database connections possess.
Potential Path to Operating-System-Level Compromise
The risk can extend beyond the Metabase application itself.
In environments where the Metabase process has access to a powerful database account or where the underlying database exposes functionality that can interact with the host operating system, an attacker who has already obtained administrative control may attempt to pivot from the application layer toward the database server and ultimately the operating system.
A common example in PostgreSQL environments is abuse of privileged database functionality to cross the boundary between SQL execution and operating-system interaction.
That does not mean every vulnerable Metabase installation automatically results in remote code execution or root access. The final stage depends heavily on the database configuration, operating-system permissions, containerization, service-account privileges and local privilege-escalation controls.
However, the possibility illustrates why organizations should not stop their investigation after finding evidence of Metabase administrator compromise.
The security question should become:
What could the compromised Metabase instance reach?
If the Metabase service has powerful credentials to a PostgreSQL database, broad network access, access to sensitive files or excessive operating-system privileges, compromise of the BI platform can become the first stage of a larger intrusion.
Why PostgreSQL Configuration Matters
Metabase deployments commonly interact with PostgreSQL and other database platforms. The security posture of those underlying systems therefore becomes an important factor in determining the ultimate impact of CVE-2026-72898.
A database account with excessive privileges increases the attacker’s options after application compromise. Conversely, a tightly restricted database account, network segmentation and strong operating-system isolation can limit the blast radius.
This is an important defensive lesson from the vulnerability.
Patching Metabase fixes the initial vulnerability, but least privilege determines how far an attacker can go if the application is compromised.
Organizations should therefore review:
- The privileges assigned to Metabase database accounts.
- Which databases and schemas those accounts can access.
- Whether Metabase can reach production systems unnecessarily.
- Whether database credentials are shared across multiple applications.
- Whether the Metabase host can communicate with sensitive internal networks.
- Whether the operating-system account running Metabase has unnecessary privileges.
- Whether container or VM isolation limits lateral movement.
- Whether database activity is centrally logged and monitored.
Affected Metabase Versions
The vulnerability affects supported Metabase branches beginning with the 0.58/1.58 generation.
The safest approach is to compare the deployed version against the corresponding fixed release rather than assuming that a version merely described as “0.6x” is safe.
Metabase branch Fixed version 0.58.x / corresponding Enterprise branch 0.58.24 / 1.58.24 0.59.x / corresponding Enterprise branch 0.59.21 / 1.59.21 0.60.x / corresponding Enterprise branch 0.60.17 / 1.60.17 0.61.x / corresponding Enterprise branch 0.61.11 / 1.61.11 0.62.x / corresponding Enterprise branch 0.62.9 / 1.62.9 0.63.x / corresponding Enterprise branch 0.63.5 / 1.63.5
The official Metabase advisory lists the corresponding fixed releases, while NVD’s CPE data identifies the affected ranges across the 0.58 through 0.63 branches and their Enterprise equivalents.
Organizations should use the fixed release for their specific branch rather than simply installing the newest version available in a different branch.
CVSS 10.0: What the Score Actually Means
CVE-2026-72898 carries a CVSS 3.1 score of 10.0, with the vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
The score reflects an attack that is:
- Network accessible
- Low complexity
- Requires no privileges
- Requires no user interaction
- Capable of affecting confidentiality, integrity and availability
- Capable of crossing a security scope boundary
The newer CVSS 4.0 assessment is also 10.0 Critical, with high confidentiality, integrity and availability impacts to both the vulnerable system and subsequent affected systems.
The “no privileges required” and “no user interaction” elements are especially important for defenders.
There is no requirement for an employee to click a malicious link, approve a login request or submit a password-reset form. An attacker can directly target an exposed Metabase installation.
Active Exploitation Changes the Risk Calculation
The most important detail is not the CVSS score. It is the fact that the vulnerability is already being exploited.
CISA added CVE-2026-72898 to its Known Exploited Vulnerabilities catalog on August 11, 2026, identifying it as an actively exploited vulnerability. The CISA assessment also classifies exploitation as automatable and the technical impact as total.
Security researchers have independently reported exploitation attempts against internet-facing Metabase deployments. Upwind reported observing active exploitation and described attacks against the unauthenticated reset-password endpoint.
CVE-2026-72898 has moved beyond that stage.
The vulnerability is public, the vulnerable endpoint is remotely accessible and exploitation techniques have been analyzed publicly. As a result, exposed Metabase installations should be treated as likely targets for automated scanning and opportunistic exploitation.
What Defenders Should Look For
Patching should be accompanied by investigation, particularly if the vulnerable endpoint was reachable from the public internet.
One particularly useful detection pattern reported by security researchers is an unusual sequence involving the password-reset endpoint followed by an authenticated user-status request. Upwind identified the pattern of:
POST /api/session/reset_password returning HTTP 400
followed by:
GET /api/user/current returning HTTP 200
as a potentially significant compromise indicator when the activity cannot be explained by legitimate application behavior.
Security teams should also investigate:
Suspicious password-reset activity
Look for repeated or automated requests to the reset-password endpoint, particularly where there is no corresponding legitimate password-reset activity.
Requests originating from unfamiliar external infrastructure, unusual geographic locations or automated scanners deserve additional scrutiny.
Abnormal response timing
Security researchers have reported exploitation involving time-based SQL injection techniques. Consequently, unusual clusters of requests with consistent multi-second response delays may warrant investigation, particularly when directed at the reset-password endpoint.
Unexpected administrator accounts
Review the Metabase administrator and superuser population.
Any newly created or modified privileged account that cannot be tied to a legitimate administrative action should be treated as suspicious.
Unknown API keys
Audit API keys and remove credentials that cannot be attributed to a legitimate user, service or automation workflow.
Unexpected API keys created around the same period as suspicious password-reset activity are particularly important.
Database connection changes
Review Metabase configuration for newly created or modified database connections.
An attacker with administrative access may attempt to use Metabase as a gateway into additional databases or alter existing connection configurations.
Unusual query and export activity
Look for database queries or exports that differ sharply from normal analyst behavior.
Large-scale extraction, broad table reads or access to datasets that a particular account has never previously queried may indicate post-compromise activity.
Host-level anomalies
If the attacker progressed beyond the Metabase application, the host itself may contain evidence.
Security teams should investigate unexpected child processes, shell execution, network utilities, file-transfer activity and outbound connections that do not fit the normal behavior of a Metabase server.
Immediate Mitigation and Patching
The primary recommendation is straightforward:
Upgrade Metabase immediately to the fixed release for your branch.
Metabase’s official advisory explicitly recommends upgrading as soon as possible.
If immediate patching is impossible, Metabase recommends blocking the vulnerable /api/session/reset_password endpoint as a temporary workaround. This should be treated as a short-term containment measure, not a substitute for upgrading.
A WAF, reverse proxy, load balancer or equivalent access-control layer can be used to restrict access to the endpoint while the upgrade is being prepared.
Organizations should also consider whether Metabase itself needs to be publicly accessible. Where possible, the service should sit behind appropriate network controls, VPN access, an identity-aware proxy or another authentication boundary rather than being directly exposed to the internet.
What to Do If Your Metabase Instance Was Internet-Exposed
This is where the response should go beyond “install the patch.”
If a vulnerable Metabase installation was publicly reachable, organizations should investigate whether exploitation occurred before or after the patch was deployed.
Metabase recommends reviewing active sessions, API keys, administrator accounts, connected database credentials, data warehouse logs and Metabase activity/query history following exposure.
A sensible incident-response sequence is:
1. Identify the deployed version.
Confirm the actual running Metabase version rather than relying solely on container tags, infrastructure-as-code files or deployment documentation.
2. Determine internet exposure.
Establish whether the password-reset endpoint was reachable from outside the organization’s trusted network.
3. Preserve logs.
Before rotating or deleting evidence, retain relevant reverse-proxy, WAF, Metabase, database, authentication and host logs.
4. Search for exploitation indicators.
Correlate requests to /api/session/reset_password with subsequent account, session, API-key, configuration and database activity.
5. Review privileged accounts.
Identify newly created administrators, unexpected privilege changes and suspicious sessions.
6. Revoke suspicious sessions and credentials.
Metabase specifically recommends revoking active sessions and reviewing API keys following exposure.
7. Rotate connected database credentials.
This is particularly important because compromise of Metabase may expose credentials used to access other systems.
8. Investigate downstream databases.
Review database and warehouse logs for unauthorized queries, exports or access from Metabase.
9. Investigate the host.
If there are indicators of operating-system-level activity, treat the incident as a potential server compromise rather than simply an application vulnerability.
10. Patch and harden the deployment.
Install the appropriate fixed release and reduce unnecessary network and database privileges.
Why Rotating Database Credentials Is Critical
One of the most easily overlooked consequences of this vulnerability is the possibility of credential exposure.
Metabase is designed to connect to external databases. Those connections necessarily involve credentials or other authentication mechanisms.
If an attacker obtains administrative control of the Metabase instance, the connected data sources become part of the potential attack surface.
Patching the application does not invalidate credentials that may already have been exposed.
For this reason, organizations investigating possible exploitation should consider rotating credentials associated with connected databases and reviewing those systems for suspicious activity. Metabase explicitly includes database credential rotation and data-warehouse log review in its post-exposure recommendations.
The same principle applies to API keys and other long-lived credentials.
The Bigger Security Lesson
CVE-2026-72898 highlights a recurring problem in modern application security: an internal database can be just as sensitive as the databases the application connects to.
Developers sometimes treat application databases as implementation details. But these databases frequently contain authentication state, configuration, account information, session data and references to external services.
A vulnerability that allows unauthenticated manipulation of that database can therefore bypass multiple layers of application security simultaneously.
The vulnerability also demonstrates why input validation must occur at trust boundaries.
An API should not rely on downstream components to correctly interpret fields that the API itself was never designed to accept. Unexpected fields should be rejected or safely discarded before they reach authentication state, business logic or database query construction.
Finally, the incident demonstrates the importance of least privilege.
Even if an attacker compromises a web application, restrictive database permissions, network segmentation, isolated service accounts and hardened operating-system privileges can significantly reduce the attacker’s ability to move from one layer to another.
Bottom Line
CVE-2026-72898 is an emergency-level vulnerability for organizations running affected Metabase versions.
It combines three particularly dangerous characteristics: remote exploitation, no authentication requirement and active exploitation in the wild.
The vulnerable password-reset endpoint can provide an attacker with a path from an unauthenticated HTTP request to SQL injection and ultimately administrator access to the Metabase instance. From there, the consequences depend on the permissions and data sources available to the compromised deployment.
CISA’s inclusion of CVE-2026-72898 in the Known Exploited Vulnerabilities catalog, combined with Metabase’s confirmation of active exploitation and the availability of public technical research, means defenders should assume that exposed vulnerable instances are being actively scanned and targeted.
Organizations should upgrade immediately to the appropriate fixed Metabase release, restrict access to the reset-password endpoint if emergency mitigation is required, and investigate potentially exposed systems for signs of compromise.
