The flaw that earned a perfect score
CVE-2026-72898 is about as bad as vulnerabilities get. It is a SQL injection flaw in Metabase, the open source business intelligence tool thousands of companies use to put dashboards in front of a database without building one from scratch, and it carries a CVSS score of 10.0, the maximum possible. No account, no session, no prior access is needed. An attacker who can reach the Metabase instance can inject SQL directly, and depending on configuration, that path leads to administrator access and the credentials for every database Metabase was connected to.
What makes this one sting is the sequence. CISA added it to its Known Exploited Vulnerabilities catalog on August 11, which normally means a patch exists and organizations have a deadline to apply it. The problem is the flaw was first exploited as a zero-day against Metabase's own hosted cloud service, meaning attackers had a working exploit before defenders had a name for it. Patching on schedule still left a window where the tool everyone trusted with their data was the softest target in the stack.
Patching did not end the problem
A CVE and a fix are not the same as a closed door. AhaSlides, one of the companies that disclosed exposure tied to this flaw, reported unauthorized access running from August 12 through September 7, weeks after the vulnerability was public knowledge and a patch was available. Metabase has since gone further than the original fix, recommending newer minimum safe releases and telling customers to revoke sessions, review API keys and admin accounts, and rotate every credential for every connected database.
That last instruction is the real tell. Rotating database credentials is a direct admission that the blast radius of a BI tool compromise covers the entire data estate it touches, well beyond the dashboard layer most teams picture when they think about BI risk. Any team that connected Metabase to production databases for convenience, then treated the BI layer as a reporting nicety rather than a privileged client of that data, inherited a credential rotation project it did not budget for, on a timeline the attacker set rather than the one the team would have chosen for itself.
Japan's numbers put a scale on the trend
This is not one bad week for one tool. Macnica, a Japanese security research firm, counted 119 publicly disclosed incidents through October 6, 2026 where personal data was stolen or leaked through web systems in Japan. That compares with 84 such incidents in all of 2025 and 62 in 2024, and the acceleration is recent: 81 of the 119 incidents this year happened in July or later. Separately, JPCERT/CC issued an October 8 alert specifically naming attacks on business intelligence tools and internal management systems that operators never expected the public to reach.
The attackers are not relying on one clever trick. JPCERT/CC and Macnica describe three distinct paths into these systems: pulling API keys out of shipped mobile apps and calling internal APIs directly, hitting internal APIs that were never meant to face outward at all, and reusing API keys stolen from a separate, unrelated compromise. The targets range from consumer-facing shopping and membership apps to library catalog search and ticketing systems, which tells us the exposure is not concentrated in one industry or one kind of application.
This pattern is not confined to Japan
Macnica also found 99 broadly similar incidents across 13 other countries and regions in roughly the same window, concentrated from July through September. South Korea accounted for 30 of those, France 11, and Poland 8. Neither JPCERT/CC nor Macnica has tied the global cases to a single group or campaign, and both researchers were careful to say their picture is incomplete: 65 of the 81 recent Japanese incidents still lack enough public detail to say exactly how the attacker got in, which leaves plenty of room for the true count to be higher once more victims disclose.
That honesty cuts against the instinct to treat this as a contained regional story. A CVSS 10.0 flaw in a widely deployed open source BI tool, a documented zero-day exploitation window, weeks of continued access after patching, and a near-doubling of leak incidents year over year in one well-instrumented country is a pattern any enterprise running similar tooling should assume applies to them until proven otherwise. Japan simply has the research infrastructure to count these incidents in public, and there is no reason to believe the underlying tooling risk stops at its borders.
The access-control gaps attackers keep finding
Beyond the headline SQL injection, the researchers flagged a grab bag of everyday mistakes that turn a BI or internal tool into an open door: APIs that return more fields than the screen actually displays, excessive privileges granted by default, anonymous access left enabled on member-only functions, and plain logic errors in how authorization checks were written. None of these require a nation-state attacker. They require someone willing to read the API responses their own browser or app receives and ask what else that endpoint would hand over.
Weak admin passwords and unpatched known vulnerabilities also made the list, which is the least exciting and most preventable category of all. The lesson for data and platform teams is that the glamorous zero-day gets the CVE number and the press coverage, but the everyday misconfiguration sitting next to it is doing just as much damage, and closing it is entirely within a platform team's control, requiring a configuration review rather than a vendor patch or a budget line.
What this means for the data stack you already run
If your organization runs Metabase, or any self-hosted BI tool with a direct line into production databases, the real test is whether you rotated credentials and audited admin accounts after the fact, treating patching as the first step rather than the finish line. The AhaSlides disclosure makes clear that a patch date can sit weeks before the all-clear date, and assuming the two coincide leaves stolen credentials live in your environment indefinitely, available to anyone who grabbed them in that gap.
More broadly, this is the moment to pull BI and analytics tooling fully inside the same access governance that protects your core databases, rather than treating it as a lightweight layer that happens to sit on top. The tools your analysts use every day to query customer and financial data are, by definition, privileged clients of that data, and 2026's leak numbers suggest the market has not caught up to that fact yet. Budgeting for that governance now costs far less than the credential rotation project a breach forces on you later.
