Web data leaks in Japan linked to API abuse and Metabase

Web data leaks affecting Japanese organizations have been tied to abused mobile application APIs, weak web system controls and exploitation of a critical Metabase vulnerability, according to an October 8, 2026 alert from JPCERT Coordination Center, or JPCERT/CC. The center said its information is still limited and fragmentary, and it did not name any attacker or affected organization.

The cases described by JPCERT/CC involve more than ordinary public websites. Reported targets include consumer app back ends, business intelligence tools, which are systems used to analyze company data, and employee-facing management systems that operators did not expect to be reachable from the public internet. In some cases, data stored in those systems was leaked. JPCERT/CC also cautioned that the same technique may not have been used in every incident.

The trend has become visible around September 2026, separate from ransomware and other routine incidents, and JPCERT/CC said the activity may be increasing. The alert itself gives no total count, but it cites an October 7 analysis by Macnica Security Research Center. Macnica counted 119 incidents disclosed in 2026 through October 6 in which personal data was stolen or leaked through web systems run by organizations in Japan. It counted 84 such incidents in all of 2025 and 62 in 2024. Of the 119 cases in 2026, 81 were made public in July or later.

Macnica said its count covers only cases it judged similar to the current series. It excludes ransomware and cases the company associates with other attack groups. Of the 81 incidents disclosed since July, 65 did not provide enough information to determine the intrusion method. Targets have widened from online shops to member services, business systems and customer support platforms. Recent examples cited include a library catalog search system and a tourist train seat reservation system.

Two disclosed incidents show the possible scale. Park24 said on September 28 that a third party obtained data for about 6.6 million accounts from the web system used by its Times Car car-sharing service. The next day it said identity documents, including driver’s license images, had leaked from about 1.6 million accounts. Monogatari Corporation, operator of the Yakiniku King restaurant chain, said 10,788,963 records leaked from the member system of its Yakiniku King app, according to INTERNET Watch on October 5. Both companies said at the time that the cause remained under investigation.

Macnica also found 99 similar cases in 13 other countries and regions, mostly from July to September. Its figures include 30 in South Korea, 11 in France and 8 in Poland. Macnica said it does not know whether Japan is the only target, and noted that disclosure laws and practices differ by country.

JPCERT/CC describes three broad attack patterns. The first is unauthorized use of management APIs, meaning the hidden interfaces that apps and websites use to request or change data. In some cases, attackers sent requests that rewrote information. JPCERT/CC said reports include attackers analyzing publicly released smartphone apps to find API endpoints and keys, attacking internal APIs not reachable through normal app screens, and using API keys stolen when another system had already been compromised.

Reported actions against internal APIs include changing user privileges, creating unauthorized accounts, comparing how servers respond when headers are added or removed or malformed authentication tokens are sent, and finding account details through blind NoSQL injection. NoSQL injection is a way of tricking a database query into revealing or changing data. Macnica, based on incident response and log analysis, reported the same broad method. In some cases, attackers extracted API keys from a smartphone app and called the API in a way that resembled normal use.

The weaknesses described are familiar to website and app operators: APIs returning more data than needed, excessive privileges, member functions accessible without signing in, logic errors and session management faults. JPCERT/CC also said attacks on weak admin-screen passwords and exploitation of known flaws were confirmed in some cases. Its second pattern is that attackers may be scanning each target for a range of known flaws, rather than relying on one shared weakness, and may also try to steal configuration and backup files where system management is poor.

The third pattern is exploitation of CVE-2026-72898 in Metabase, an open-source business intelligence tool that organizations connect to databases. Metabase said the flaw was exploited as a zero-day against its own cloud service and assigned it a CVSS severity score of 10.0. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on August 11. JPCERT/CC warned about it on August 14.

CVE-2026-72898 is an SQL injection flaw, meaning an attacker can interfere with database commands. Metabase said no account is needed to exploit it. The flaw affects Metabase’s own application database and can give administrator access. From there, an attacker could obtain stored credentials for connected databases and read or export their data. Metabase issued a security update on August 6 and another critical advisory on August 11 for issues it said it found itself. It later raised the minimum release it considers safe for each supported version.

For open-source Metabase builds, the versions that first fixed CVE-2026-72898 are 0.63.5, 0.62.9, 0.61.11, 0.60.17, 0.59.21 and 0.58.24. Metabase’s minimum safe releases are newer: 0.63.13, 0.62.16, 0.61.18, 0.60.24, 0.59.28 and 0.58.31. Enterprise builds of the August 6 fixes use 1.x numbering instead of 0.x. Versions below 58 are not affected by CVE-2026-72898, and Metabase has patched its cloud service.

Metabase says operators who cannot upgrade immediately can temporarily block the /api/session/reset_password endpoint for CVE-2026-72898, although its August 11 advisory tells users to upgrade. It also says a server is likely compromised if logs show a POST request to /api/session/reset_password returning 400, followed by a GET request to /api/user/current returning 200. If the reset endpoint was reachable from the internet, Metabase recommends revoking active sessions, reviewing API keys and administrator accounts, rotating connected database credentials, checking data warehouse logs, and reviewing Metabase activity and query history after upgrading.

JPCERT/CC published source IP addresses and User-Agent strings connected to the activity, but warned the addresses were abused during the stated periods and may now be used normally. For API abuse around September 2026, the listed IP addresses are 3.112.252[.]14, 54.95.112[.]6, 69.10.51[.]162, 172.86.91[.]7 and 210.149.87[.]120. For Metabase exploitation from early August to early September 2026, the listed IP addresses are 213.163.202[.]171, 221.216.140[.]49 and 221.216.140[.]129. Macnica said 210.149.87[.]120 and 69.