Metabase Patches Critical Zero-Day SQL Injection Vulnerability

Unauthenticated attackers have actively exploited a critical Metabase zero-day vulnerability targeting the business intelligence platform’s password reset flow. The flaw, which manifests as an unauthenticated SQL injection vulnerability, allows remote attackers to execute arbitrary SQL queries against the underlying Metabase application database. By manipulating backend database state, unauthenticated threat actors can bypass authentication controls entirely to gain full administrative rights over vulnerable Metabase instances.

Metabase discovered the vulnerability after detecting attack activity aimed at its Metabase Cloud service. While Metabase Cloud instances were patched automatically and endpoints utilized in the attack were blocked, self-hosted deployments remain exposed until administrators apply the newly released updates. No CVE identifier has been assigned to the security defect at this time.

Mechanics of the Attack and Enterprise Blast Radius

The root cause of this flaw lies in improper input handling within the /api/session/reset_password API endpoint. When a user submits a password reset request, user-supplied data is passed into SQL queries executed against Metabase’s internal application database without sufficient parameterization or sanitization. By injecting malformed parameters into this endpoint, an attacker can directly query or alter tables in the application’s underlying storage engine.

In enterprise environments, data analytics platforms like Metabase occupy a uniquely sensitive position in the network topology. Business intelligence tools rely on high-privilege read (and occasionally write) credentials to aggregate data across enterprise storage systems—including PostgreSQL, MySQL, Snowflake, Google BigQuery, Amazon Redshift, and proprietary data warehouses. Once an attacker leverages this SQL injection vulnerability to achieve administrative access within Metabase, the blast radius extends well beyond the analytics server itself:

• Credential Harvesting: Attackers can extract stored database connection strings, service account passwords, and API keys maintained in the Metabase application database, allowing them to authenticate directly against backend data infrastructure.
• Mass Data Exfiltration: With administrative access, attackers can execute arbitrary queries against connected enterprise databases, bypass row- or column-level access controls configured within Metabase, and export broad datasets directly through application interfaces.
• System Persistence: Attackers can modify application configurations, create rogue administrative accounts, generate persistent API keys, or alter system settings to maintain access even after partial remediations.

Hunting for Indicators of Compromise

Because the exploit chain relies on a predictable sequence of API calls, security teams can audit web server ingress logs and application logs for a specific request signature.

Security analysts should search access logs for a POST request sent to /api/session/reset_password returning an HTTP 400 Bad Request status code, immediately followed by a GET request sent to /api/user/current returning an HTTP 200 OK status code:

POST /api/session/reset_password HTTP/1.1 -> 400 Bad Request
GET  /api/user/current          HTTP/1.1 -> 200 OK

The initial POST request represents the SQL injection payload triggering an execution error or handled exception while manipulating the application database, while the subsequent GET request indicates the attacker successfully validated their newly elevated administrative session. Finding this request pattern in server ingress or application logs strongly indicates that the instance has been compromised.

Immediate Mitigation and Patching Guidance

Organizations operating self-hosted Metabase instances exposed to the internet must take immediate action to secure their environments.

Upgrade to Patched Versions

Metabase has issued security updates across all supported release branches. Administrators should immediately upgrade self-hosted environments to one of the following fixed versions:

• 63.5
• 62.9
• 61.11
• 60.17
• 59.21
• 58.24

Temporary Workaround

If an immediate software upgrade is not feasible, organizations should configure a web application firewall (WAF) rule or reverse proxy restriction to block all incoming traffic to the following endpoint:

/api/session/reset_password

Blocking this route prevents attackers from reaching the vulnerable password reset logic while allowing standard, authenticated analytics activity to continue.

Incident Response Steps for Exposed Instances

If an unpatched Metabase instance was accessible from the internet prior to applying the update—or if log analysis reveals suspicious traffic—security teams should execute the following containment measures:

1. Apply Updates: Deploy the appropriate patched version or block the vulnerable password reset endpoint.
2. Revoke Active Sessions: Forcefully terminate all current user sessions across the platform to invalidate potential administrative session tokens created by attackers.
3. Audit User Accounts and Keys: Inspect all registered user accounts for unrecognized administrative users, review generated API keys, and delete any unauthorized credentials.
4. Rotate Connected Database Credentials: Immediately change passwords, tokens, and certificates for all backend databases and data warehouses linked to the Metabase deployment.
5. Review Audit Logs: Perform a detailed review of query history and data export logs to assess whether connected data sources were queried or exfiltrated during the window of exposure.