Japan's data leak surge points at mobile app APIs and unpatched Metabase

Key points

• Japan's national incident response team JPCERT/CC warned on October 8, 2026 that attackers are stealing personal data by abusing mobile app APIs and exploiting known software flaws in web systems.
• The alert, based on breach reports filed with the center, names no victim and no attacker group.
• Metabase, a widely used business dashboard tool, published a fresh advisory describing SQL injection weaknesses that let crafted input reach the database as raw commands.
• Patched Metabase builds cover every supported major version in both the free and paid editions.
• JPCERT/CC urges organisations to audit app back-end interfaces and apply vendor patches without waiting for a tailored proof of concept.

Japan's national cyber incident team has told organisations to look hard at their mobile apps and their web dashboards, after a run of personal data leaks tied to two very ordinary attack routes.

In an alert dated October 8, 2026, JPCERT/CC said the breaches it has logged this year share a pattern. Attackers are poking at the APIs, the hidden interfaces a phone app uses to talk to a company's servers, and they're exploiting software flaws that vendors have already patched. The center named no victim and no attacker. It did say the reports came through its own intake channel.

The mobile angle is the less glamorous of the two. A smartphone app is really a front end for a web service, and the service usually trusts the app more than it should. Change a user ID in a request, drop an authentication check or replay a token, and the server often hands back someone else's records. JPCERT/CC's framing is that developers keep forgetting the API is a public interface the moment the app ships.

Why is Metabase in the middle of this?

Metabase is a popular open-source tool companies use to build charts and dashboards on top of their own databases, and a new advisory describes bugs that let crafted input slip past validation and run as database commands. That's a textbook route to bulk data theft.

We've covered Metabase four times since August 7, 2026, and this advisory fits the same pattern: a reporting tool wired directly to a company's warehouse, with insufficient controls on what a user can make the database do. The write-up says fixes tighten how Metabase checks the pieces of a query a user can influence. In several places, a value a user supplied could reach the database as raw SQL, the language used to query databases, instead of being treated as plain data. That's SQL injection, and in a reporting tool wired to a company's warehouse it's close to a master key.

The advisory lists fixes across query parameters, filters, stored metric and segment definitions, custom column types, and the code that creates schemas on BigQuery and SQL Server.

Which Metabase versions are safe?

Upgrade to the patch for your major version. Fixes cover every supported line in both the free Open Source edition and the paid Enterprise edition; check the advisory for the specific build numbers.

The advisory doesn't confirm in-the-wild exploitation. Given JPCERT/CC's warning that attackers in Japan are already working through known flaws in web systems, treating this as urgent is the honest reading.

What should affected users do?

If you're a customer whose data sits inside a Japanese service that has disclosed a leak this year, the practical steps are familiar: change the password on that service, change it anywhere you reused it, and turn on two-factor authentication where it's offered. Watch for phishing that quotes real details from your account, because leaked data makes those messages far more convincing.

For anyone running Metabase: patch this week, not this quarter. Then check which database accounts Metabase connects with. If those accounts can read every table in the warehouse, a single injection bug becomes a full breach. Narrowing those permissions is the fix the advisory doesn't spell out.

The broader lesson here isn't really about Japan or Metabase specifically. It's that known, patched vulnerabilities keep driving real breaches because organisations treat patch schedules as administrative formalities rather than active risk decisions. JPCERT/CC's alert is worth reading for exactly that reason.