Japan Sees Sharp Rise in Web Data Leaks Amid Mobile API Abuse and Metabase Attacks

What kinds of web systems and APIs did attackers abuse to obtain personal data in Japan?

The attacks targeted web systems that organizations use for customer accounts, member services, shopping, support, business operations, and employee management. Attackers also reached business intelligence tools and APIs behind smartphone apps. Some employee-facing and internal systems were exposed to the public even though operators did not expect that access.

The attackers tested APIs for excessive data exposure, excessive privileges, logic errors, weak session handling, and anonymous access. They also targeted management APIs that app screens did not use. Reported actions included changing privileges, creating accounts, probing authentication behavior, and using blind NoSQL injection to find account details.

The targets ranged from online shops to libraries, tourist trains, restaurants, and car-sharing services. JPCERT/CC stressed that its information is limited and fragmentary, so the same method was not necessarily used everywhere. The variety of targets shows why every endpoint, including internal ones, needs protection.

How large is the apparent increase in similar data-leak incidents in Japan?

The available count points to a substantial increase in similar personal-data leaks in Japan. Macnica counted 62 incidents in 2024, 84 in 2025, and 119 through October 6, 2026. That means this year’s count had already exceeded the full totals for both previous years, despite covering only part of the year.

The rise also became concentrated recently. Of the 119 incidents counted this year, 81 were made public in July or later. Macnica judged these cases similar to the current series and excluded ransomware and incidents linked to other attack groups.

The figures are not a complete national total. Sixty-five of the 81 cases disclosed since July provided too little detail to identify the entry method. JPCERT/CC gave no incident count and warned that its information was limited and fragmentary, but it said the leaks may be increasing.

What happened to the personal data held by organizations such as Park24 and Monogatari Corporation?

The incidents exposed large volumes of personal information held in customer systems. Park24 said a third party obtained data on about 6.6 million accounts from the web system for its Times Car car-sharing service. The company later said identity documents, including driver’s license images, had leaked from about 1.6 million accounts.

Monogatari Corporation reported a separate large exposure involving the member system for its Yakiniku King restaurant app. INTERNET Watch reported that 10,788,963 records leaked. Both companies said when they disclosed the incidents that the cause was still under investigation.

These cases illustrate the potential consequences of weaknesses in APIs and connected web systems. The leaked material was not limited to ordinary account details in Park24’s case. JPCERT/CC said the broader series involved large amounts of personal data and was separate from routine ransomware incidents.

How did attackers use mobile-app APIs, internal management APIs, stolen API keys, and weak administrative systems to get access?

One route began with analyzing a publicly released smartphone app. Attackers identified its API endpoints and keys, then sent unauthorized requests directly to those interfaces. Because APIs can perform actions beyond what an app screen displays, attackers sometimes rewrote information or reached functions that users were not supposed to control.

They also tested internal APIs that app screens did not expose. Reported techniques included changing privileges, creating unauthorized accounts, comparing server responses to altered headers or malformed tokens, and using blind NoSQL injection to find account details. In other cases, attackers used API keys stolen during a separate compromise and called APIs in ways resembling ordinary app use.

Weak administrator passwords and known software flaws provided additional routes. Attackers searched each target for excessive privileges, excessive data returns, anonymous member functions, logic errors, and session-management faults. JPCERT/CC also raised attacks involving stolen configuration or backup files.

What is Metabase, and why did the vulnerability CVE-2026-72898 make it a valuable target?

Metabase is an open-source business intelligence, or BI, tool that companies connect to their data systems. BI tools can sit close to information used for reporting and analysis. That makes weaknesses in them important, especially when the tool or its APIs can be reached from outside the intended user group.

The article identifies CVE-2026-72898 as an SQL injection flaw in Metabase. SQL injection lets an attacker manipulate database queries through an application weakness. In this series, JPCERT/CC identified Metabase as the only named product target, and it said attackers have exploited the flaw.

Metabase has urged users to upgrade to at least the minimum safe releases listed in its guidance, last updated August 14. Those releases are newer than the first fix for the flaw. The specific safe versions are not provided in the article, so organizations must consult Metabase’s current guidance.

What can organizations do to reduce the risk of unauthorized API requests and exploitation of known software flaws?

The strongest starting point is to treat every API endpoint as a security boundary. JPCERT/CC specifically recommends access controls on all endpoints, including those operators consider private. Organizations should also check whether employee-facing systems, management APIs, and BI tools are accidentally reachable from the public internet.

Software updates are equally important. Metabase users should move to at least the minimum safe releases named in Metabase’s guidance. Organizations should replace weak administrator passwords, limit privileges, prevent anonymous access to member functions, and ensure each endpoint returns only necessary data. API keys should be protected and replaced if another system may have exposed them.

Defenders should also review configuration and backup files, because JPCERT/CC raised theft of those files as a possible attack path. The alert provides eight source IP addresses and five User-Agent strings that can support investigation. These measures reduce exposure, but the alert does not claim one method explains every incident.

Why do APIs need authentication, authorization, least-privilege access, and checks that limit the data returned by each endpoint?

Authentication answers whether a requester is recognized. Authorization answers whether that requester may use a particular endpoint or action. Least privilege ensures the account or API key receives only the permissions required for its job. Together, these controls prevent a discovered endpoint from becoming an open door.

The article describes failures that show why each layer matters. Attackers reached internal APIs, changed user privileges, created accounts, and found account details through blind NoSQL injection. Other weaknesses included anonymous member functions, excessive privileges, and APIs that returned more data than necessary. A valid-looking request can still be dangerous if the endpoint permits too much.

Limiting each response reduces the damage from both stolen credentials and software flaws. It also makes accidental exposure less severe. JPCERT/CC’s guidance calls for access controls on every endpoint, public or not. The incidents show that hiding an API behind an app screen is not a substitute for these controls.

Key Facts:

📌 Targets included mobile apps, BI tools, member services, and employee-facing management systems.

📌 Some internal APIs were publicly reachable despite operators not expecting public access.

📌 Recent targets included a library catalog and a tourist train booking system.

📌 Macnica counted 119 similar Japanese incidents through October 6, 2026.

📌 Japan recorded 84 such incidents in 2025 and 62 in 2024.

📌 Eighty-one of 2026’s 119 cases became public in July or later.

📌 Park24 reported data obtained from about 6.6 million Times Car accounts.