Metabase Zero-Day Exposes Your Databases: NC SMB 2026

TL;DR: On August 7, 2026, the analytics vendor Metabase disclosed that attackers had been exploiting a maximum-severity flaw (CVSS 10.0) in its business intelligence software, with intrusions against its cloud instances beginning around August 3, injecting SQL through an unauthenticated password-reset endpoint to reach administrator control [1][2]. The lesson for a North Carolina manufacturer or distributor is not about one product: a reporting dashboard is wired into every database it charts and stores the credentials to reach them, so a single dashboard breach is a breach of your whole data estate at once. Framework, Tally, and LexisNexis have confirmed they were hit [2].

Key takeaway: The tool you use to look at your data is also a tool that can copy all of it. A dashboard is not a low-risk internal app. It is a credential vault with a login page, and this month it had no password on the door.

You may be running Metabase without knowing it: a controller or analyst often stands one up to watch cash flow or production, and IT never sees it. Do you know what your reporting tools can reach, and whether one is exposed to the internet? Contact Preferred Data Corporation at (336) 886-3282 for a data-access and attack-surface review. BBB A+ rated, serving High Point and the Piedmont Triad since 1987.

What happened with the Metabase zero-day in August 2026?

Attackers found an unauthenticated way to inject SQL into Metabase and used it to seize admin access and steal the database credentials the tool had stored, then read and exported connected data [1][2][3]. Metabase rates the flaw CVSS 10.0, the top of the scale, and it affects the 1.58 through 1.63 (Enterprise) and 0.58 through 0.63 (Community) lines up to the patched builds below, the Community line being what most self-hosted installs run [1][3].

Here is the sequence, which moved faster than most patch cycles:

• Around August 3, 2026: intrusions began against Metabase Cloud instances, per the company's timeline via BleepingComputer [2].
• August 6: Metabase notified affected customers [2].
• August 7: the vulnerability and the attacks were disclosed publicly [1][2].

The mechanism is a single request most reporting tools never think to defend. An attacker sends a POST to /api/session/reset_password that returns a 400 error, then a GET to /api/user/current that returns 200 instead of an unauthorized error, the signature of a request that slipped past authentication [1][2]. From there the flaw allows escalation to administrator. The attacker needed no stolen password and no employee to click anything. The endpoint that exists so a user can recover a forgotten login became the way in.

Metabase has not assigned a CVE identifier to the flaw, and that detail matters: a vulnerability can be maximum severity, under active attack, and still lack the tidy tracking number that patch tools key off [1]. If your only trigger for action is a CVE landing in a feed, you were late here.

Why is a business intelligence dashboard such a high-value target?

Because a dashboard is designed to see everything, and to do that it holds standing, credentialed connections to every database it reports on, making it a single point of collapse for your entire data layer. Compromise the reporting tool and you lose the data behind every application it touches, not one.

Consider what a mid-sized North Carolina firm points such a tool at:

• The ERP or accounting database with customers, invoices, and payroll.
• The inventory or MES database on the plant floor showing production and orders.
• A CRM or order database with contacts and pricing.

Each connection is stored with a working credential, and in this incident attackers pulled those credentials out of the compromised instances [1][2]. That is what turns a website bug into a company crisis: even after a patch, the database passwords it held are in someone else's hands.

Framework, the laptop maker, says attackers accessed customer names, emails, login IPs, phone numbers, and billing and shipping addresses, with business customers also exposing VAT and EIN numbers [2]. Tally reported email addresses and password hashes taken, though form submissions were not [2]. LexisNexis confirmed its Metabase API was affected [2].

Key takeaway: Rank your internal tools by what they can reach, not by how important they feel. A quiet dashboard that connects to six databases outranks the flashy app that connects to one.

Want a map of which internal tools touch which databases? Call Preferred Data at (336) 886-3282 or explore our Cybersecurity and Data Protection services.

How exposed are self-hosted tools like this, really?

More than their owners think. These tools get stood up on a cloud server, wired to production data, and left on whatever version was current the day they were installed. Metabase Cloud customers in this incident were patched automatically by the vendor; self-hosted users have to update themselves, and until they do, they stay vulnerable [2].

Three realities make this worse for a small business than for a large enterprise:

1. The exposure is invisible on the balance sheet. A dashboard a controller set up to watch cash flow never shows up in a security review that only checks the firewall and email.
2. Exploitation now outpaces patching. Verizon's 2026 Data Breach Investigations Report found vulnerability exploitation overtook stolen credentials as the top way attackers gain initial access, the first time credential theft has lost that spot in the report's 19-year history [4]. Metabase fits the pattern.
3. The blast radius scales with your data, not your headcount. A 40-person distributor whose dashboard reaches the full customer and pricing history can lose as much data as a company ten times its size.

The uncomfortable question for any owner: if a tool your team spun up eighteen months ago is on a public IP right now, who is responsible for updating it? On too many small networks the honest answer is nobody, which is exactly what attackers scan for.

What should a North Carolina business do about it this week?

If an exposed instance may already be compromised, take it fully offline first, then review the logs and preserve evidence before you change anything, then patch and evict the attacker, then rotate every database credential it held, and only then restore access. A patch alone is not enough: it does not remove an intruder who already got in, and credentials stolen earlier keep working until you rotate them.

A concrete checklist for the next few days:

• Find out if you run Metabase anywhere. Ask your team and check your cloud accounts. Shadow deployments are common, and the person who set one up may have left.
• If an instance was internet-exposed on a vulnerable version, isolate it fully first. Take the host offline, or quarantine it so it can reach nothing in either direction, so an attacker already inside cannot watch you work or re-capture what you change.
• Investigate and preserve evidence before you change anything. Review the logs for the reset-password fingerprint above and capture what you need first, since upgrading can overwrite artifacts you need to scope the intrusion. Then remove any admin accounts or sessions the attacker created [1][2].
• Patch to a fixed release. Community (0.x) fixes are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5; the Enterprise (1.x) fixes are 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9, and 1.63.5. Apply the one for your version [1].
• Rotate the database credentials the tool used. Once the instance is isolated, cleaned, and patched, assume any stored password is compromised and change it on the database side [1][2].
• Restore access behind a private network, not a public address. Put the dashboard behind a VPN, a private network, or an upstream gateway that authenticates every request before it reaches the tool. The tool's own login does not help: the flaw is pre-authentication, so the endpoint answers anonymous scanners before any sign-on.
• Give it a read-only, least-privilege database account. A dashboard almost never needs to write. A read-only role scoped to the specific tables it charts caps the damage of the next compromise.

This is the difference between a bad week and a reportable data breach. No patching could stop a zero-day before its fix existed; what limited the damage was defense in depth: a dashboard already off the public internet, segmented, on a limited read-only account, and updated when the fix shipped. That is what network segmentation and least-privilege design produce when someone owns them.

An exposed dashboard versus a governed one

Ready to shrink what a single breach could reach? Call (336) 886-3282 or learn about our Managed IT Services.

How does this connect to your ERP and plant-floor data?

It connects directly: the databases most North Carolina manufacturers and distributors report on are the same ones that run the business, so a reporting-tool breach and an operations breach are the same event. A dashboard reading live production counts from a plant-floor system in Hickory, or margin data from an ERP in Statesville, is one exploited endpoint away from handing that data to an extortion group.

Preferred Data works with manufacturers and industrial firms across the Piedmont Triad whose analytics tools sit on ERP, inventory, and accounting databases. The recurring finding in a review is that these tools were connected with the same high-privilege account used to build them, exposed for remote convenience, and never revisited. Each of those is a decision you can reverse in an afternoon.

Get a data-access and attack-surface review. Contact Preferred Data Corporation at (336) 886-3282. We deliver Cybersecurity, Managed IT, and Data Protection for small businesses and manufacturers across High Point, Greensboro, Charlotte, and Raleigh. Serving the region for 39 years, BBB A+ rated.

Frequently Asked Questions

What is the Metabase vulnerability disclosed in August 2026?

It is a maximum-severity (CVSS 10.0) unauthenticated SQL injection flaw in Metabase's business intelligence software, disclosed publicly on August 7, 2026, after attacks began around August 3 [1][2]. An attacker can reach the /api/session/reset_password endpoint without logging in, escalate to administrator, and steal the credentials Metabase stored for every connected database [1]. Metabase has not assigned a CVE identifier as of disclosure [1].

Which Metabase versions are affected and what are the fixes?

Every release in the 1.58 through 1.63 (Enterprise) and 0.58 through 0.63 (Community) lines up to the patched builds is affected; the Community 0.x line is what most self-hosted installs run [1]. Those fixed builds are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 (Community) and 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9, and 1.63.5 (Enterprise); install the fix for your version [1]. Metabase Cloud instances were patched automatically by the vendor, while self-hosted installations are the exposure to close [2].

We patched Metabase already. Are we safe now?

Patching closes the vulnerable entry path, but it does not evict an attacker who already got in or reverse what was already taken. If your instance was exposed on a vulnerable version, isolate it, review the access logs for the attack pattern, and remove any attacker-created admin accounts or sessions before you rotate the stored database credentials, which you should treat as compromised [1][2].

Who was affected by the Metabase attacks?

Framework, Tally, and LexisNexis have publicly confirmed impact [2]. Framework reported customer names, emails, login IP addresses, phone numbers, and billing and shipping addresses accessed, with business customers also exposing VAT and EIN numbers [2]. Tally reported emails and password hashes taken but not form submissions; LexisNexis confirmed its Metabase API was affected [2].

Why is a reporting dashboard a bigger risk than it looks?

Because it holds live, credentialed connections to every database it charts, so its blast radius is your entire data layer rather than one app. A dashboard is built to read everything, and it keeps the passwords to do so, which is exactly what attackers extracted in this incident [1][2]. Rank internal tools by what they can reach, and a quiet dashboard often outranks your customer-facing apps.

How do we keep our internal tools from becoming the next entry point?

Keep them off the public internet, patch them on a schedule, and connect them with least-privilege, read-only database accounts scoped to the tables they need. Verizon's 2026 report found vulnerability exploitation is now the top way attackers break in, ahead of stolen credentials for the first time [4], so unpatched internet-facing tools are the highest-yield target. A managed IT partner maintains that inventory, patching, and access discipline continuously, not as a one-time cleanup.

Related Resources

• Metabase Zero-Day Exploited in Wild Allows Admin Access Without Authentication - The Hacker News
• Framework, Tally disclose Metabase data-theft attacks - BleepingComputer
• Verizon 2026 DBIR findings - Help Net Security
• CISA Known Exploited Vulnerabilities Catalog
• Preferred Data Cybersecurity Services
• Preferred Data Managed IT Services

References

1. The Hacker News. (2026). Metabase Zero-Day Exploited in Wild Allows Admin Access Without Authentication. https://thehackernews.com/2026/08/metabase-zero-day-exploited-in-wild.html
2. BleepingComputer. (2026). Framework, Tally disclose Metabase data-theft attacks. https://www.bleepingcomputer.com/news/security/framework-tally-disclose-metabase-data-theft-attacks/
3. Security Affairs. (2026). Metabase Zero-Day Exploited in the Wild, Exposing Admin Access and Sensitive Data. https://securityaffairs.com/196874/hacking/metabase-zero-day-exploited-in-the-wild-exposing-admin-access-and-sensitive-data.html
4. Help Net Security. (2026). Verizon 2026 DBIR: Vulnerability exploitation is the dominant initial access vector. https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/