Metabase 0-Day Attack Exposes Connected BI Data; Urgent Patch for Self-Hosted Users

Metabase has issued an urgent security update.

On August 6, 2026, Metabase disclosed that Metabase Cloud had been attacked through a previously unknown zero-day vulnerability. The vulnerability affected Metabase versions 1.58 and above. The company said it immediately blocked the endpoint used in the attack, quickly identified the vulnerability and released patches.

Metabase Cloud customer instances have already been upgraded and patched.

The more urgent issue is self-hosted Metabase users.

Organizations running Metabase on their own infrastructure may still be vulnerable. Metabase advised those users to upgrade immediately to the latest point release. As a temporary mitigation, it also recommended blocking the /api/session/reset_password endpoint.

This is not just another web application vulnerability.

Metabase is a business intelligence tool. Companies use it to connect multiple databases, build dashboards, run queries, create reports and visualize business metrics. Sales, finance, customer support, product, operations, marketing and executive teams use tools like Metabase to access data more easily.

That is precisely why it is dangerous.

A BI tool may not create the data itself, but it gathers access to data. It stores database connection information and credentials. It allows users to query information without directly logging in to each database. If the BI tool is breached, the damage may not be limited to a few dashboards. The attack surface can expand to the connected databases behind it.

Metabase’s own advisory made this risk clear.

An attacker who accessed a vulnerable Metabase instance could inject arbitrary SQL into the Metabase application database. From there, the attacker could gain instance administrator privileges, modify application settings, steal stored credentials for connected databases and read or exfiltrate data accessible through those connections.

That is the moment a BI tool changes from a window into data into a pathway to data.

Framework’s Customer Notice Showed the Real-World Impact

The real-world impact became clearer through a customer notice from Framework.

Framework told customers that a data breach had occurred at its business intelligence database provider, Metabase. As a result, an attacker accessed customer names, email addresses, phone numbers and addresses. Framework said the compromised database did not contain order information or payment information.

Framework also said it was reviewing and improving how it stores data with external database vendors. It was also notifying regulators in jurisdictions where such notification may be required. The company noted that, in many regions, a breach involving only name, email address, phone number and address may not necessarily trigger mandatory notification. Still, it decided to notify customers so they could understand the situation and take appropriate precautions.

This notice is important because it shows the nature of the Metabase incident.

The breached tool was Metabase.

But the people notified were Framework customers.

In other words, a security incident involving a data analytics tool became a customer-information exposure incident for a real company.

That raises important questions.

What customer information does a company place inside its BI tools?

Is the tool operated by an external vendor or self-hosted internally?

How are database credentials stored?

If the BI tool account is compromised, what data becomes visible?

Are customer data, payment data and order data separated?

If a breach occurs, which customers must be notified?

BI tools are convenient.

But convenience blurs data boundaries.

What Metabase Does

Metabase is an open-source business intelligence tool that allows companies and development teams to connect databases and create dashboards and reports.

Users can write SQL directly or use a visual interface to query data. They can build dashboards for product metrics, revenue, customer behavior, orders, marketing performance and operational status. Because it is relatively easy to adopt, Metabase is widely used by startups, technology companies and data teams.

Its strength is accessibility.

People who are not professional data analysts can still view data. Teams can share dashboards. Users can access the information they need without directly connecting to production databases or data warehouses.

From a security perspective, however, that same strength is also a risk.

Metabase sits between users and databases. Users log in to Metabase to view many types of data. Administrators store database connection information. If permissions are misconfigured or a vulnerability is exploited, an attacker may use Metabase as a bridge into connected data.

Metabase is a data hub.

If the hub is breached, the connected spokes are also at risk.

The Dangerous Part: Admin Access and Stored Credentials

The most important part of Metabase’s advisory is what an attacker could do after exploitation.

After reaching a vulnerable instance, an attacker could inject arbitrary SQL into the Metabase application database. That could allow the attacker to gain administrator privileges.

Administrator access is not merely a user-interface privilege.

A Metabase administrator may be able to view connected database settings, manage users, inspect dashboards, view saved questions and review query history. Depending on configuration, the attacker may access stored database credentials or use existing connections to query connected databases.

Metabase said an attacker could modify application configuration, steal stored credentials for connected databases and read or exfiltrate all data accessible through those connections.

That is why the vulnerability is serious.

A BI tool breach is not just an account takeover.

Administrator takeover threatens the entire data-connection layer.

Stored credential theft can put databases outside Metabase at risk.

Query history and activity logs can help attackers understand which data is valuable.

Even if an organization believes Metabase is an internal tool, the risk becomes real if the instance is internet-exposed or if a vulnerable endpoint is reachable.

The Attack Pattern Can Be Found in Logs

Metabase also disclosed a pattern that may indicate exploitation.

The attack often appears as a POST /api/session/reset_password request returning a 400 status code, followed by a GET /api/user/current request returning a 200 status code.

Metabase said that if this pattern appears in application logs or server ingress logs, the instance has likely been compromised.

This information is critical for self-hosted operators.

Upgrading is not enough.

The attack may already have occurred. After patching, operators must check logs. If the pattern appears, they should review sessions, API keys, administrator accounts, connected database credentials, data warehouse logs, Metabase activity and query history.

A common mistake in incident response is assuming that patching ends the incident.

But if the vulnerability was already exploited, an attacker may have obtained sessions, created API keys, changed administrator accounts or stolen database credentials.

Patching closes the door.

Incident response checks whether someone already entered.

Those are different tasks.

What Operators Should Do Immediately

Metabase recommended several follow-up actions if the /api/session/reset_password endpoint was publicly accessible.

First, all active user sessions should be invalidated. This can be done by accessing the Metabase application database and deleting all rows from the core_session table. The goal is to cut off any sessions an attacker may have obtained.

Second, API keys should be reviewed and unknown keys deleted. An attacker may have created API keys to maintain access.

Third, administrator accounts should be checked for unexpected additions or permission changes.

Fourth, credentials for connected databases should be rotated. If stored database credentials were exposed, those credentials may still allow access outside Metabase.

Fifth, data warehouse logs should be reviewed for unauthorized access or abnormal queries.

Finally, Metabase activity and query history should be reviewed for unexpected or unauthorized activity.

All of these actions follow one principle:

do not look only at Metabase.

Look at the full data path that Metabase connects.

Cloud Customers and Self-Hosted Customers Face Different Responsibilities

Metabase said Metabase Cloud customer instances have already been upgraded and patched.

Self-hosted customers, however, must take action themselves. This difference is a recurring issue in open-source and SaaS software.

In a cloud service, the provider can apply patches centrally. Customers are protected more quickly. In a self-hosted environment, the customer must identify the version, upgrade the software, review logs and rotate credentials.

Self-hosting gives more control.

It also brings more responsibility.

Security response speed depends on the customer’s operating capability. A small startup or development team may install Metabase easily, but when a critical vulnerability appears, it may not have the security resources to upgrade immediately and investigate logs.

This incident shows the reality of self-hosted tools.

Easy installation does not mean easy operation.

Safe Versions and the Importance of Version Management

Metabase listed minimum safe releases for each major version line.

The safe versions are 0.63.5 for the 63 series, 0.62.9 for the 62 series, 0.61.11 for the 61 series, 0.60.17 for the 60 series, 0.59.21 for the 59 series and 0.58.24 for the 58 series. For example, an organization running 0.58.6 should upgrade to 0.58.24 or later. Versions below 58 were described as not affected.

This guidance shows why version management matters.

Many organizations know that they use Metabase, but may not know exactly which version they are running, where every instance is located or who owns each installation. A BI tool installed temporarily by a development team can later become an operational system.

The first step in security response is asset identification.

Which version is running?

Is it exposed to the internet?

Which databases are connected?

What account permissions are used for those connections?

Who has administrator privileges?

Where are logs stored?

If an organization cannot answer these questions, it cannot patch properly.

Read-Only BI Access Is Still Dangerous

Many organizations assume that BI tools are safe if they are configured as read-only.

Read-only permissions are important. They are less dangerous than accounts that can modify databases. But read-only access is still enough for data exposure. If an attacker can read and export customer information, revenue data, internal metrics, personal information or logs, the harm can be significant.

BI tools often receive broad read access.

Dashboards are useful across departments, so many tables are made accessible. For analytics convenience, organizations may grant wide access to a production replica or data warehouse. Administrators may think this is safe because the tool can only read.

For an attacker, read access can be enough.

Customer lists.

Email addresses.

Phone numbers.

Physical addresses.

Order histories.

User behavior logs.

Revenue data.

Contract information.

Internal operational metrics.

All of this can be sensitive business data.

Framework’s notice said order and payment information were not included, which limited the scope of harm. But names, emails, phone numbers and addresses can still support phishing, smishing and social engineering.

Read-only does not mean harmless.

Reconsidering How Data Is Stored With External Vendors

Framework said it was reviewing and improving how it stores data with external database vendors.

That sentence captures a key post-incident lesson.

Companies use external SaaS and open-source tools for analytics and BI. Some data may be stored in external services. External tools may also receive credentials to access internal databases. This is efficient, but it complicates data boundaries.

If an external vendor is compromised, what data is exposed?

Is the vendor receiving only the minimum necessary data?

Is personal information minimized, masked or pseudonymized?

Are connection credentials rotated?

Do vendor accounts have least-privilege access?

Are logs and audit records available?

Are breach-notification obligations clearly defined in contracts?

These questions are necessary.

Analytics creates pressure to gather more data in one place. Security requires gathering only what is necessary. BI tools are where that tension becomes concentrated.

More data improves analysis.

It also increases breach impact.

The Gray Area of Breach Notification

Framework’s notice also included an interesting point about regulatory notification.

The company said it was notifying regulators in jurisdictions where applicable rules exist. It also said that in most regions, exposure of only name, email address, phone number and address may not require notification. Still, it notified customers to provide visibility and allow them to take appropriate steps.

This shows the gray area of breach notification.

Not all data breaches trigger the same legal obligations. Requirements differ by region and depend on the type of information, sensitivity, risk level, encryption and likelihood of harm. Payment information, national identifiers, health information or passwords often create stronger notification duties. Names and contact details alone may be treated differently depending on jurisdiction.

But legal obligation and customer trust are not the same.

There are cases where a company may not be legally required to notify every customer, but still should. Framework’s communication can be understood as a trust-based response.

The important question in breach response is not only whether the company did the legal minimum.

It is whether customers were given enough information to understand their risk and respond.

What Risks Remain for Customers

Framework said order information and payment information were not included.

That is an important reassurance. But exposure of names, email addresses, phone numbers and addresses is not risk-free.

Attackers can use that information for phishing and smishing. They can send messages pretending to be Framework, Metabase or a delivery provider. They may reference warranties, recalls, payment confirmation, shipping updates, account security or discount coupons. If the attacker has a name, address and phone number together, the message becomes more convincing.

Customers should therefore be cautious.

They should be suspicious of emails or text messages claiming to come from Framework or Metabase.

They should not click links requesting passwords or payment information.

They should verify order or delivery messages through the official website.

They should confirm suspicious calls or texts through official support channels.

They should check security alerts for accounts using the same email address.

A data breach does not end with the initial exposure.

The follow-on social engineering risk can create additional harm.

Lessons for Korean Companies

Korean companies also use BI tools such as Metabase widely.

Startups, SaaS companies, e-commerce firms, financial institutions, public agencies, research organizations and manufacturers all connect BI tools to dashboards and reporting systems. Some are self-hosted, some are cloud-based and some are deployed inside internal networks.

This incident offers several lessons.

First, companies must check whether BI tools are exposed to the internet. Administrator pages and API endpoints should not be reachable publicly unless there is a strong reason and strong control.

Second, version and patch management must be formalized. Open-source tools are often installed and then forgotten. Ownership and update procedures must be clear.

Third, connected database credentials must follow least privilege. BI accounts should receive only the access needed for reporting and should not have administrative or write permissions.

Fourth, credentials must be rotated regularly and immediately after suspected compromise.

Fifth, query logs and activity records must be retained and monitored. Incident response requires knowing who accessed which data.

Sixth, tables containing personal information should have stricter BI access controls. Not every dashboard user needs to see customer contact information.

Seventh, data shared with external SaaS and BI tools should be minimized. Raw personal information should not be copied into analytics tools unless necessary.

Eighth, breach-notification criteria should be prepared in advance. Companies should know which data exposure requires notice, to whom, when and through what channel.

Korean privacy and sector-specific security rules already require companies to respond to data incidents. If customer contact details and addresses are exposed, the risk of social engineering should also be considered.

BI tools have too much data access to be treated as mere internal convenience tools.

Data Analytics Permission Is Security Permission

The most important lesson from this incident is simple.

Data analytics permission is security permission.

Companies often treat analytics access as an operational convenience. The more employees can see dashboards, the easier it becomes to make data-driven decisions. But as data access expands, breach impact also grows.

BI tools are especially attractive to attackers because they connect multiple datasets, make information easy to query and store dashboards and query history. An attacker does not need to understand the entire database architecture. The BI tool shows what matters.

BI tools therefore need the same seriousness as other core security assets.

Least privilege.

Network restrictions.

Strong authentication and MFA.

Limited administrator accounts.

Audit logs.

Regular patching.

Credential rotation.

Sensitive data masking.

Query-history monitoring.

External sharing restrictions.

The easier a tool makes data access, the harder security becomes.

Convenient access is convenient for attackers too.

A Dashboard Is Not the End of Data. It Is the Doorway to Data.

The Metabase incident confirms the importance of BI tool security.

Metabase disclosed exploitation of a zero-day vulnerability affecting versions 1.58 and above. Metabase Cloud customers have already been patched, but self-hosted users must upgrade immediately. If a vulnerable instance was compromised, an attacker could use arbitrary SQL to gain administrator privileges, change application settings, steal stored database credentials and read or exfiltrate accessible data.

Framework’s customer notice showed that this risk can become real customer-data exposure. Attackers accessed customer names, email addresses, phone numbers and addresses. Order and payment information were not included, but contact details and addresses still create phishing and social-engineering risk.

The essence of this incident is not only a vulnerability in one product.

It is that a convenient pathway created for data analysis can become a shortcut for attackers.

BI tools gather credentials and access rights across databases. Therefore, BI security is not dashboard security. It is enterprise data security.

Data analytics is a competitive advantage.

But if the analytics tool is breached, that advantage becomes an attack path.

Companies should no longer treat BI platforms as simple internal tools. They must reduce internet exposure, manage versions, enforce least-privilege database credentials, monitor logs and separate sensitive data. External vendors and self-hosted tools should be governed by the same security standard.

A dashboard is a screen that shows data.

From a security perspective, it is also a door into data.

The most important question after the Metabase incident is how well that door is locked.