Metabase is a popular, open-source data visualization and business intelligence tool, often used by organizations to create dashboards and share insights from databases and other data sources. In late 2022, a critical security flaw was identified in Metabase which potentially allowed attackers to bypass Single Sign-On (SSO) and reset user passwords directly—giving them a simple path to compromise accounts, even in environments that enforced SSO.

In this post, I’ll explain CVE-2022-39360 in easy-to-understand terms: what happened, how it could be exploited, and how to protect your Metabase install. I'll also reference the original advisories and demonstrate the exploit logic with code snippets.

Risk: Account takeover & unauthorized access

- Patched: Yes—see affected/secure versions below

In short:  
SSO users were able to perform password reset requests inside Metabase, potentially setting a new password and logging in with username/email+password—bypassing the requirement to authenticate with the SSO Identity Provider (IdP).

Unauthorized access to sensitive dashboards and business data

- Compromise even in companies expecting all logins to route through Google, Okta, Azure AD, SAML, etc.

1.41.9

Patch now:  
> Download the latest Metabase here:  
> https://www.metabase.com/start/download/

Background

Normally, when SSO is enabled, users should not be able to set or reset their own passwords inside Metabase. All authentication should rely on the external IdP (like Okta, Google Workspace, or Active Directory).

The problem:  
Metabase versions before this fix improperly allow SSO users to access the password reset function—even when SSO is enforced. That means you could request a password reset, receive a reset link (usually to your corporate email), and set a password for Metabase.

After this, you can log in directly with email+password, sidestepping SSO checks entirely.

A simplified process

def reset_password_request(email):
    user = find_user_by_email(email)
    if user:
        # Vulnerability: No check if user is SSO-enforced
        send_reset_email(email)

def login(email, password):
    user = find_user_by_email(email)
    if user and check_password(password):
        # Problem: Allows password login for SSO users
        return user
    # No SSO requirement enforced here
    return None

After you reset your own password (even if you're supposed to use only SSO), you can log in just like a normal password-based user.

Logs in to Metabase using email+password, not SSO.

6. Accesses dashboards/data they're now authorized for.

Important limits:  
- Attacker needs access to the victim's email. This is serious if employees leave, and their mailbox is compromised or not properly off-boarded.
- SSO settings are essentially nullified for password-reset users—this is a major violation of security expectations.

Example: Exploit Self-Registration (Hypothetical)

A similar issue can occur if registration or user invites are possible: an attacker sets up or invites themselves, sets their own password, and doesn't need SSO at all.

The Fix

After the patch: Metabase blocks password reset links for any account that only authenticates via SSO—so you can't set a local password for SSO-only users.

Sample fix logic

def reset_password_request(email):
    user = find_user_by_email(email)
    if user and not user.is_sso_only():
        send_reset_email(email)
    else:
        # Block password reset for SSO-only users
        return 'Reset not allowed for SSO-managed accounts'

References & Official Notices

- GitHub Metabase Security Advisory
- MITRE CVE Entry
- Release Notes (Metabase .44.5)

Conclusion

CVE-2022-39360 is a classic SSO-bypass error that could have cost organizations their data. If you're running Metabase and use SSO, make sure password-based logins are disabled for SSO-managed accounts, and always keep up with the latest security releases.


Was your Metabase vulnerable?  
Act now—patch, review user access, and recommend this post to other admins.

For more details or testing scripts, check the official advisory.

Timeline

Published on: 10/26/2022 19:15:00 UTC
Last modified on: 10/28/2022 16:29:00 UTC