The disclosure of active attacks exploiting a previously unknown SQL injection vulnerability in Metabase demonstrates why analytics platforms must be treated as high-value security infrastructure rather than passive reporting tools. Metabase confirmed that an attacker exploited a zero-day vulnerability affecting versions 1.58 and above to compromise customer environments before a fix was available. The flaw allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, potentially obtain administrator-level access to the Metabase instance, retrieve credentials stored for connected databases, query information available through those connections and export data. The vulnerability has been rated Critical with a CVSS score of 10.0, and exploitation has already resulted in confirmed data theft affecting companies including Framework and Tally. 

The seriousness of the issue comes from the position Metabase occupies inside an organization’s data environment. Business intelligence and analytics platforms are deliberately connected to databases containing customer, financial, operational, sales and application data so that employees can analyse that information through dashboards and reports. To perform this role, the platform frequently stores connection details and credentials that provide access to multiple downstream databases. A compromise of the analytics application can therefore become a gateway into datasets that the attacker could never reach directly from the internet.

The vulnerability is particularly dangerous because no valid Metabase account is required to begin exploitation. According to Metabase, an attacker can send specially crafted requests to the application and manipulate SQL executed against the Metabase application database. This database stores configuration and metadata about the platform itself rather than merely holding dashboard results. Once an attacker gains sufficient control over this information, they may be able to change application configuration, obtain administrator privileges and retrieve secrets used to connect Metabase to external databases.

SQL injection remains one of the oldest and most thoroughly documented web application vulnerabilities, yet it continues to produce severe incidents because the consequences depend heavily on where the vulnerable query executes. SQL injection against a simple public website may expose one application database. SQL injection against an analytics platform can potentially expose credentials for several independent databases and transform one vulnerable service into an access broker for a much larger information environment.

Metabase identified the attack after its Cloud SaaS environment was targeted through the previously unknown vulnerability. The company responded by blocking the endpoints used in the campaign and deploying a correction across its managed cloud platform. Customers using Metabase Cloud have therefore already received the protection, while organizations operating self-hosted instances must update their installations manually. The distinction is important because cloud customers receive centralized remediation from the vendor, whereas self-hosted organizations remain responsible for detecting exposure, applying updates and investigating whether attackers reached the platform before patching.

The vulnerability has been corrected across supported branches, with minimum safe releases including 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5. Organizations should verify the exact version actually running rather than relying on the assumption that a recently updated instance is protected. Automated deployment systems, container images and orchestration environments can retain older versions even after administrators believe an application has been upgraded, particularly where multiple development, staging and production instances exist.

Organizations unable to upgrade immediately have been advised to block access to the `/api/session/reset_password` endpoint temporarily. This is useful as an emergency containment measure because the observed attack chain involves requests to that path, but it should not be treated as a permanent substitute for updating. Attackers can study patches, modify exploitation techniques and search for alternative paths once technical details become better understood. Removing the underlying vulnerability is more reliable than attempting to maintain a narrow request filter indefinitely.

Metabase has provided a particularly useful detection sequence for defenders. A POST request to `/api/session/reset_password` returning an HTTP 400 response followed by a successful GET request to `/api/user/current` can indicate that exploitation succeeded. Metabase warns that systems containing this sequence in their logs should be considered likely compromised. This gives organizations an opportunity to distinguish ordinary vulnerability exposure from evidence that an attacker actually interacted with the affected endpoint.

Any self-hosted organization finding these indicators should treat the event as an incident rather than simply applying the patch and returning the service to production. Once an attacker has obtained administrator access, they may be able to create additional users, issue API keys, alter configuration or retrieve database credentials. Updating Metabase removes the SQL injection path but does not automatically invalidate credentials or persistence established during the compromise.

Metabase recommends revoking all active user sessions, reviewing administrator accounts and API keys for unauthorized additions, rotating database credentials and inspecting query history and logs for suspicious activity. These measures are important because an attacker who obtained a valid database password before patching no longer needs to exploit Metabase again. They may connect directly to the underlying database from another system if network controls permit it.

Connected database credentials should therefore be considered potentially exposed whenever successful exploitation cannot be ruled out. Organizations should inventory every data source configured within Metabase and determine the permissions associated with the account used for each connection. Credentials should be rotated from a trusted environment, and access logs from the corresponding database should be examined for unfamiliar source addresses, unusual queries or large data exports.

Database accounts used by analytics systems should follow strict least-privilege principles. A reporting platform generally requires read access to specific schemas and tables but rarely needs permission to modify production records, create users or administer the database server. If a Metabase connection uses a broadly privileged database account, compromise of the analytics platform can become a much more serious infrastructure breach.

Read-only access should itself be scoped carefully. Giving one analytics credential unrestricted read access to an entire enterprise data warehouse means that an attacker controlling Metabase may gain the same visibility. Separating credentials by business function or dataset can limit the amount of information exposed through one compromised connection and make suspicious queries easier to attribute.

Network controls should also prevent analytics database credentials from being useful from arbitrary locations. A data warehouse should accept Metabase connections only from the expected application servers or cloud network. Even if an attacker steals the username and password, direct access should fail when it originates outside the approved source addresses or private network.

Framework provides a clear example of the downstream consequences. The laptop manufacturer said Metabase notified it on August 6 that its instance had been vulnerable and that an attacker accessed the environment on August 3. Framework subsequently determined that customer information had been stolen, including full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers and company names. Business customers may additionally have had information such as VAT numbers, EIN details and billing email addresses exposed.

This information may not contain payment-card numbers or account passwords, but it remains highly useful for attackers. Names, addresses, phone numbers, company relationships and purchase information can support targeted phishing, impersonation and social-engineering campaigns. Criminals can create messages referencing real orders, companies or addresses, making subsequent fraud much more convincing than generic phishing.

Framework customers affected by the breach should therefore be cautious of messages claiming to concern orders, payments, delivery problems or account verification. Attackers may use stolen contextual information to create communications that appear legitimate even when the sender address or destination link is fraudulent. Organizations should remind customers that possession of accurate personal information is not proof that a message originated from the company.

Tally also confirmed that its Metabase analytics environment was compromised on August 3. According to Tally’s notification, attackers were able to access users’ email addresses and password hashes through the analytics environment, while form content and submitted responses were stored separately and were not reached. This illustrates the value of separating sensitive application datasets rather than allowing every analytics tool to connect to everything an organization stores.

The separation of Tally’s form responses appears to have limited the breach substantially. Form platforms can contain highly sensitive information submitted by users, potentially including health, employment, financial or personal data depending on how customers use the service. Keeping that dataset outside the compromised analytics path prevented an already serious incident from becoming significantly larger.

However, exposure of password hashes still requires careful treatment. A password hash is not equivalent to a plaintext password, but its resistance to cracking depends on the algorithm, salting and cost parameters used. BleepingComputer reported that Tally had not yet specified which hashing algorithm protected the exposed values or whether the hashes were salted. Without that information, customers cannot accurately judge how difficult offline cracking might be.

Organizations storing password credentials should use modern, deliberately slow password-hashing algorithms such as Argon2id, bcrypt, scrypt or appropriately configured alternatives and should apply unique random salts. Fast cryptographic hashes such as SHA-256 are unsuitable for password storage by themselves because attackers can test enormous numbers of password guesses offline after obtaining the database.

Users affected by a password-hash exposure should change reused passwords on other services even when the original hashes are considered strong. Credential reuse turns one successful offline crack into access across unrelated applications. Multi-factor authentication also reduces the impact if an attacker recovers a password, although users should still replace exposed credentials rather than relying entirely on a second factor.

The Tally incident demonstrates another important principle: analytics platforms should not receive more data than they actually require. Organizations frequently replicate large portions of production databases into business intelligence tools because broad access simplifies reporting. This creates an additional high-value copy or access path containing information that may never have been necessary for the dashboards being produced.

Data minimization can reduce this risk. Metabase and similar applications should connect to curated reporting schemas or views that expose only fields needed for analysis. Highly sensitive attributes such as password hashes, authentication tokens and secret keys should not be accessible through an analytics account unless there is an exceptional business requirement. There is little legitimate reporting value in placing password hashes within reach of a business intelligence platform.

LexisNexis also informed customers about disruption involving Diligence, its Metabase API and Newsdesk after detecting unusual activity on servers managed by a third-party vendor. The company disconnected from the affected third-party systems as a containment measure, causing temporary application unavailability while the incident was investigated. At the time of reporting, it had not confirmed whether customer information was exposed or explicitly attributed the event to the same Metabase zero-day, so the connection should remain treated cautiously until additional evidence is released.

The possible involvement of multiple organizations demonstrates how vulnerabilities in widely deployed software can generate simultaneous incidents across unrelated industries. Attackers do not need to develop a separate intrusion method for each victim when they can identify a common internet-facing platform and scan for vulnerable installations. Once exploitation succeeds, the data available behind each Metabase deployment determines the value of the compromise.

External attack-surface management is therefore important for self-hosted analytics platforms. Organizations should know whether Metabase is accessible from the public internet and whether that exposure is genuinely necessary. Many analytics dashboards are intended only for employees and can be placed behind VPNs, identity-aware proxies or other authenticated access layers rather than exposing the application directly to arbitrary internet users.

Restricting internet exposure would not eliminate every risk because employees or compromised internal devices could still reach the application, but it substantially reduces opportunities for anonymous mass exploitation. A vulnerability that requires no authentication is most dangerous when millions of untrusted systems can send requests to the affected endpoint.

Web application firewalls may provide temporary protection against known SQL injection patterns, but defenders should not depend on them as the primary solution. Advanced injection techniques can exploit parser behaviour that generic signatures do not detect, and attackers can modify requests rapidly after filters become public. The correct response remains application patching combined with restricted reachability.

Organizations should also collect detailed reverse proxy and application logs for analytics platforms. Metabase’s published indicators are useful only if relevant request history has been retained. Short log-retention periods can make retrospective investigation impossible when a zero-day is disclosed several days after exploitation begins.

Database query logs should be retained independently from Metabase wherever operationally practical. If attackers gain administrator control of the analytics platform, they may be able to manipulate application-level history. Logs generated by the underlying database or cloud data warehouse provide a separate source for determining which tables were queried and whether large datasets were exported.

Security teams should establish baselines for analytics query behaviour. A dashboard user may normally retrieve summarized statistics covering a limited dataset, whereas an attacker may suddenly query entire customer tables or enumerate system metadata. Unusually broad queries, large result sets or unexpected access outside normal reporting hours should generate alerts even when the request originates from the legitimate Metabase application account.

Cloud data platforms can strengthen this model through workload identities and short-lived credentials rather than permanent database passwords. An analytics application that receives temporary tokens with narrowly defined permissions exposes less reusable credential material if the application is compromised. Secrets-management systems can also allow rapid automated rotation following an incident.

The Metabase incident underscores why application database credentials should be treated as Tier-0 secrets. Business intelligence platforms often accumulate connections over time as teams add dashboards, and old credentials may remain configured long after the associated report is abandoned. Organizations should periodically remove unused databases, dashboards, accounts and API integrations to reduce both complexity and attack surface.

API keys and administrator accounts deserve particular attention following this vulnerability because attackers with Metabase administrator access may create persistence through legitimate application mechanisms. An unfamiliar administrator or API credential can survive the software update and provide continued access without generating another exploit attempt.

All sessions should be revoked after suspected compromise so that browser cookies or tokens created during the intrusion no longer remain valid. Password resets alone may not terminate existing authenticated sessions, particularly where applications use long-lived session identifiers.

Incident responders should also examine configuration changes made during the affected period. Attackers may alter email settings, authentication providers, embedding configuration or database connection details to establish alternative access or capture information. Comparing the current configuration against a trusted historical baseline can reveal modifications that are difficult to identify through account lists alone.

If attackers gained operating-system access through some additional path, rebuilding the Metabase server or container from a trusted image may be warranted. Metabase has not stated that this particular SQL injection directly provides host code execution, so defenders should distinguish application-level administrator compromise from confirmed server compromise. However, investigators should escalate the response if logs or endpoint telemetry indicate shell execution, unfamiliar processes or filesystem changes.

Self-hosted installations should avoid storing the application and database on one broadly trusted host where compromise of either automatically exposes the other. Network segmentation between the Metabase application, its own metadata database and connected business databases limits lateral movement and makes access policies more explicit.

The incident also raises questions about SaaS concentration risk. Metabase Cloud allows organizations to avoid maintaining the application themselves and ensured that the vendor could deploy the fix centrally as soon as the attack was identified. At the same time, a vulnerability affecting a managed analytics provider can expose several customers through a common service architecture. Cloud services therefore transfer some security responsibilities rather than eliminating them.

Metabase says its hosted architecture isolates customers in separate containers rather than shared clusters, which can reduce cross-customer impact. Even with infrastructure isolation, however, a product-level vulnerability reachable inside individual customer instances can still allow attackers to target those environments independently. Tenant isolation and application security must work together.

The vendor’s disclosure and immediate release of fixed versions are important because organizations need specific remediation guidance during an active zero-day event. Metabase also previously introduced a Security Center capability in newer self-hosted versions to identify security advisories relevant to the installed configuration. Administrators should ensure these alerting capabilities are enabled rather than relying solely on external news to discover critical vulnerabilities.

The fact that Metabase had already disclosed another serious credential-access vulnerability earlier in 2026 also reinforces the value of maintaining current software. In February, the company fixed a notification API flaw that could allow authenticated users to retrieve sensitive database connection information. Metabase said it found no evidence that the earlier flaw was exploited, but both incidents show how database credentials inside analytics platforms represent a particularly sensitive attack target.

Organizations should therefore evaluate whether analytics platforms need direct knowledge of reusable database credentials at all. Where supported, federated authentication, cloud IAM roles, certificate-based access or short-lived tokens provide stronger security than storing static usernames and passwords inside application configuration.

The broader lesson from the Framework and Tally incidents is that compromising a business intelligence platform is effectively compromising the trust relationships surrounding that platform. Metabase may not store all of the business information itself, but it knows how to reach the systems that do. An attacker who gains control of the analytics layer can inherit that connectivity.

This changes how such systems should be classified in security architecture. Analytics applications should receive protections comparable to database administration tools, including restricted network exposure, strong authentication, privileged access controls, centralized logging, aggressive patching and tightly scoped database permissions.

Organizations should also reconsider whether sensitive fields need to be queryable through general analytics tooling. Tally’s separation of form submissions limited the damage, while exposure of password hashes demonstrates that other information was available through the analytics environment that attackers could monetize. Data architecture can therefore determine the severity of a breach long before the vulnerability itself is discovered.

The active exploitation of the Metabase zero-day should prompt every self-hosted customer to update immediately, review logs for the published request sequence, revoke sessions, inspect administrator accounts and API keys, and rotate connected database credentials where compromise is suspected. Database access logs should then be reviewed to determine whether information was retrieved beyond the normal behaviour of the analytics application.

There is little value in treating the incident as resolved merely because a vulnerability scanner reports the updated version. If exploitation occurred before patching, the attacker may already possess administrator access, database credentials or exported information. The remediation question is therefore not only whether the SQL injection has been fixed, but whether the trust relationships exposed through that injection have been restored.

The Metabase attacks show how one unauthenticated request against a reporting platform can ultimately become a customer-data breach at companies that otherwise have entirely separate applications and security architectures. The vulnerable software acts as the common denominator because all of those organizations trusted it with access to valuable data.

For defenders, the practical lesson is straightforward: analytics software should have enough access to answer business questions, but not enough authority to turn one application vulnerability into unrestricted access to the organization’s databases. When a reporting tool holds the keys to everything it reports on, attackers do not need to compromise every database individually. They only need to compromise the tool that already has permission to ask.

A critical Metabase SQL injection vulnerability was exploited in zero-day attacks to breach customer instances in data theft attacks, known to impact Framework and Tally. [...]

Source: Metabase SQLi zero-day exploited in customer data-theft attacks via Bleeping Computer — published 07 Aug 2026.