TL;DR

On August 6, 2026, Metabase disclosed CVE-2026-72898, a critical unauthenticated SQL injection vulnerability with a CVSS score of 10.0.

The vulnerability allows a remote, unauthenticated attacker to inject arbitrary SQL into a Metabase application database and gain administrator access to the affected instance.

Scalingo subsequently confirmed successful exploitation of an internal Metabase instance and unauthorized exfiltration of personal data and customer-related metadata from an internal analytics data warehouse. Approximately 90,000 individuals are affected. We have identified no evidence of access to customer production applications, production databases, or data stored within those workloads. We took the affected Metabase service offline, deployed the security fix, initiated credential rotation and we have completed a forensic investigation. The internal Metabase service remains offline as a precaution.

We notified the CNIL (the French data protection authority) of the personal data breach and informed affected customers.

What Happened?

On Thursday, August 6, 2026, Metabase published a security advisory disclosing a critical vulnerability affecting Metabase. Metabase confirmed that the vulnerability had been actively exploited and that successful exploitation could allow an attacker to gain administrator access to affected Metabase instances.

On Monday, August 10, 2026, the Scalingo security team became aware of the vulnerability and immediately began investigating its impact on our infrastructure.

We immediately took the affected instance offline and began a thorough investigation of our logs and associated activity to determine whether the vulnerability had been exploited.

Our initial analysis confirmed that the vulnerability had been successfully exploited by three distinct malicious activity clusters. Two of these used the vulnerability to exfiltrate data from our data warehouse. The third did not attempt to exfiltrate data but instead initiated an action intended to establish persistence on the affected system.

Later that day, Scalingo sent a security notification to customers deploying Metabase on Scalingo, recommending that they patch their Metabase deployments as soon as possible.

On August 11, we notified the CNIL of the personal data breach affecting our customers, in accordance with our obligations under the GDPR.

On August 12, we notified affected customers of the incident and provided them with information about its impact and the precautions they should take.

We will continue to update this bulletin as our investigation progresses and additional information becomes available.

Incident Analysis

1. Identification of IP Addresses Potentially Involved in the Attack

We began our forensic investigation by reviewing HTTP logs and correlating observed requests with the exploitation techniques described in the Metabase security advisory.

The objective of this analysis was to distinguish potentially malicious activity from legitimate application traffic and to determine which requests were associated with exploitation attempts.

We then narrowed the investigation to source IP addresses for which we identified evidence consistent with successful exploitation and/or subsequent malicious activity following the publication of the Metabase security advisory. Not every exploitation attempt resulted in a successful compromise or data exfiltration.

Through this analysis, we identified 18 source IP addresses associated with attempts to exploit the vulnerability during the period between the publication of the security advisory on 6 August 2026 and the start of Scalingo’s forensic investigation.

Based on our analysis of the associated traffic and subsequent activity, we identified three potential malicious activity clusters associated with successful exploitation of the vulnerability. Two of these attempted to exfiltrate data, while the third did not attempt data exfiltration but instead took actions intended to establish persistence on the compromised system.

2. Analysis of Metabase Audit Logs

Metabase maintains audit logs within its internal database, containing records of actions performed through the application. These logs were useful for correlating HTTP-level activity with actions performed inside Metabase following successful exploitation.

We used these records to reconstruct the sequence of events following the initial exploitation and to distinguish exploitation attempts from attacks that resulted in access to the application or its data.

However, because the Metabase instance itself was compromised, data stored within its internal database cannot be considered inherently trustworthy after the breach. An attacker with sufficient access may have been able to alter or delete records, including audit data.

For this reason, we did not rely solely on Metabase’s internal audit logs. We correlated relevant audit records with HTTP requests and data warehouse audit logs recorded by infrastructure outside the attacker’s apparent perimeter of control. This cross-correlation allowed us to assess the consistency and reliability of the Metabase audit data used during the investigation.

3. Analysis of the First Malicious Activity Cluster

08-08-2026 01:03 UTC+2: The attacker exploited the password reset vulnerability (SQL injection) to create a new API key associated with the first administrator account on our Metabase instance.

08-08-2026 01:04 UTC+2: The attacker performed reconnaissance on the database metadata and then proceeded to perform a bulk extraction of data from the internal analytics data warehouse.

The activity associated with this cluster performed initial reconnaissance against database metadata, followed by a bulk extraction of data from Scalingo’s internal analytics data warehouse.

4. Analysis of the Second Malicious Activity Cluster

08-08-2026 03:57 UTC+2: The attacker began a reconnaissance phase within the Metabase instance, attempting to understand the environment, database structure, and data available through the compromised instance.

08-08-2026 04:03 UTC+2: The attacker began exfiltrating data from the database.

08-08-2026 04:18 UTC+2: We observed the last malicious query associated with this attacker. No further malicious queries from this attacker were identified after this point.

Our analysis indicates that the attacker had started attempting to exploit the instance approximately two hours before beginning the reconnaissance and data exfiltration phase.

Assessment: the sequence shows a progression from environment discovery to targeted data extraction and searches for potentially sensitive information. Some queries were executed in rapid succession, while longer pauses occurred between groups of queries. These timings may be consistent with the use of automated tooling, but they do not allow us to reliably determine the tools used or the degree of human interaction involved.

What Data Is Affected?

Our investigation has confirmed that the exfiltrated datasets contain information relating to approximately 90,000 individuals. The exact information affected varies depending on the individual and the customer’s use of Scalingo.

The confirmed categories of exfiltrated data include:

• Identity and contact information: full name, username, email address, company and location;
• Scalingo account information: internal technical identifiers (IDs), account creation and last login dates, account status, role, account confirmation information, and whether multi-factor authentication (MFA) is enabled. The exposed internal IDs are technical identifiers and cannot be used as authentication credentials;
• GitHub-related information associated with Scalingo profiles: GitHub username, email address, profile URL and avatar;
• Limited billing-related information: customer name, company and payment status;
• Technical metadata relating to Scalingo services and databases: depending on the customer, this may include application and database names and identifiers, database types and versions, and metadata relating to maintenance operations, backups, restorations, restarts, plan changes or upgrades;
• Names of certain environment variables, together with the identifiers of the applications to which they relate. The values of these environment variables were not included in the exfiltrated datasets.

The exposure of the MFA status indicates whether MFA was enabled on an account; MFA secrets, recovery codes and other authentication secrets were not included in the exfiltrated datasets.

The incident concerns information extracted from Scalingo’s internal analytics data warehouse. We have identified no evidence of unauthorized access to customer production applications or production databases, nor to the data stored within those workloads.

What Data Was Not Affected?

The following data was not included in the exfiltrated datasets:

• Passwords
• Banking data
• MFA-related secrets (recovery codes, secrets, etc.)
• Access tokens for third-party services (GitHub, GitLab, etc.)
• Source code of deployed applications
• Database contents and their backups
• Encryption keys, TLS certificates and other internal security mechanisms
• Although the names of environment variables were exfiltrated, the values of those environment variables were not part of the dataset
• Database logs, HTTP router logs and database-related logs

The attack vector used has now been contained.

The affected information could potentially be used for targeted phishing or social engineering attempts. In particular, information about a customer’s organization, contact details, account, or Scalingo services could be used to make fraudulent communications appear more credible.

We have identified no evidence that the compromise provided access to customer production workloads or to data stored within those workloads.

What We Did

As soon as we identified the incident, we took immediate action to contain it and assess its impact.

For our internal Scalingo Metabase instance, we:

• took the affected Metabase instance offline;
• deployed a patched version of Metabase;
• initiated the rotation of potentially exposed technical credentials;
• preserved evidence required for the investigation;
• analyzed the queries performed by the malicious activity clusters and the data they accessed;
• increased monitoring of the affected systems.

As an additional precaution, Scalingo’s internal Metabase service remains offline while the investigation and security review continue.

The attack vector used in this incident has been contained.

We also notified customers using the Scalingo Metabase buildpack of the vulnerability and provided instructions for upgrading their deployments to a patched Metabase version.

What You Should Do

Concerning the Breach of Scalingo’s Internal Metabase Instance

Based on the information currently available, no immediate technical action is required on your Scalingo applications as a result of this incident.

However, we recommend that you:

• enable multi-factor authentication (MFA) on your Scalingo account if you have not already done so;
• inform the relevant security or data protection contacts within your organization, where appropriate;
• remain vigilant for targeted phishing attempts;
• report to us any suspicious message or activity that you believe may be related to this incident.

Scalingo will never ask you to provide your password by email.

If you are unsure about the authenticity of a Scalingo communication, you can confirm it with us through the support chat available in the Scalingo dashboard.

If You Are Running Metabase on Scalingo

If you are running Metabase on Scalingo using the Metabase buildpack, action is required.

A patched Metabase version is available. You should upgrade your deployment as soon as possible by:

1. setting the METABASE_VERSION environment variable to v0.63.5.x;
2. resetting your deployment cache;
3. redeploying your application.

Once the upgrade has been successfully deployed, keep the METABASE_VERSION environment variable set to v0.63.5.x until Metabase issue #79605 has been resolved. Removing the variable before then will cause the buildpack to automatically install the latest Metabase release, which may leave your application vulnerable to the security issue addressed by this bulletin.

We also recommend that you:

• review Metabase administrator accounts and API keys for any unexpected changes;
• review Metabase activity and database access logs for suspicious activity;
• if your Metabase instance has been publicly accessible, rotate the credentials for all databases connected to Metabase.

We recommend following the Metabase security advisory: https://www.metabase.com/blog/security-update.

What Are the Risks?

Concerning the Breach of Scalingo’s Internal Metabase Instance

The affected data could potentially be used for targeted phishing or social engineering attempts, in particular by using information that could make a fraudulent message appear more credible, such as your company name, contact information, billing information, or details relating to your Scalingo services.

We therefore recommend being particularly vigilant about any unusual message claiming to come from Scalingo, especially if it asks you to provide credentials, change your password, make a payment, or follow an unexpected login link.

Scalingo will never ask you to provide your password by email.

If you are unsure about the authenticity of a Scalingo communication, please confirm it with us through the support chat available in the Scalingo dashboard.

If You Are Running Metabase on Scalingo

A full compromise of your Metabase data and related connected services is possible if you are running an unpatched Metabase instance.

Product Impacts

Scalingo Internal Analytics

Affected. Scalingo’s internal Metabase service was compromised and data from the connected internal analytics data warehouse was exfiltrated. The service remains offline as a precaution.

Scalingo PaaS

We have identified no unauthorized access to customer production applications or to data stored within those applications as a result of this incident.

Scalingo DBaaS

We have identified no unauthorized access to customer production databases or to their contents as a result of this incident.

Metabase Buildpack

Customers running an affected, unpatched Metabase version must upgrade their deployment as described above.

Contact

For any questions regarding this incident or the steps you should take, please contact our support team at support@scalingo.com or through the in-dashboard chat.

For any questions regarding the exercise of your rights concerning your personal data, please contact us at dpo@scalingo.com.

Timeline

Changelog

• 2026-08-12: Initial publication of SSB-2026-004.