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

Summary

Japan's JPCERT/CC has reported a significant increase in web data leaks, with attackers exploiting mobile app APIs and known vulnerabilities in software like Metabase. These incidents, distinct from ransomware, have led to the exposure of large volumes of personal data across various sectors, including online retail, member services, and business systems. Analysis indicates a sharp rise in such breaches since July 2026.

Full text

Japan Sees Sharp Rise in Web Data Leaks Amid Mobile API Abuse and Metabase Attacks Swati KhandelwalOct 08, 2026Data Breach / Web Security Attackers behind a string of personal data leaks at Japanese organizations have abused APIs for mobile apps and targeted known software flaws, the JPCERT Coordination Center (JPCERT/CC) said. The Tokyo-based center, which takes incident reports, based its October 8, 2026 alert on those reports and other information. The alert names no attacker and no affected organization. JPCERT/CC called what it knows "limited and fragmentary" in the alert, translated here from Japanese. It said its account does not mean the same method was used in every incident. Besides consumer apps, the systems hit include business intelligence (BI) tools and employee-facing management systems that their operators did not expect the public to reach. Data stored in them leaked in some cases. For defenders, the alert includes eight source IP addresses, five User-Agent strings, and a list of API controls, including access controls on every endpoint, public or not. The only product it names as a target is Metabase, a BI tool with a known flaw that attackers have exploited. Metabase has urged users to upgrade to at least the minimum safe releases in a list last updated August 14. Those releases are newer than the first fix for that flaw. The leaks have come one after another around September 2026. The attacks behind them are separate from ransomware and other routine incidents, lead to leaks of large amounts of personal data, and may be increasing, JPCERT/CC said. JPCERT/CC gave no count. One comes from the Security Research Center of Japanese company Macnica, in an analysis published October 7 that the alert cites. Macnica counted 119 incidents made public this year through October 6 in which personal data was stolen or leaked through web systems run by organizations in Japan. It counted 84 in all of 2025 and 62 in 2024, and 81 of this year's 119 came in July or later. The count covers only incidents that Macnica judged similar to the current series. It leaves out ransomware and cases Macnica ties to other attack groups. Of the 81 made public since July, 65 gave too little detail to tell how the attackers got in. The targets have spread from online shops to member services, business systems and customer support. Recent cases include a library's catalog search and a tourist train's seat booking system. Two cases show the scale. Park24 said on September 28 that a third party obtained data on about 6.6 million accounts from the web system of its Times Car car-sharing service. A day later, it said that identity documents, such as driver's license images, had leaked from about 1.6 million accounts. Monogatari Corporation, which runs the Yakiniku King restaurant chain, said 10,788,963 records leaked from the member system of its Yakiniku King app, INTERNET Watch reported on October 5. Both companies said at the time that the cause was still under investigation. Macnica also found 99 similar cases in 13 other countries and regions, mostly from July to September, including 30 in South Korea, 11 in France and 8 in Poland. It does not know whether Japan is the only target, and said disclosure laws and practices differ by country. How the Attackers Get In JPCERT/CC's alert describes three patterns. The first is unauthorized requests to the management APIs behind an app. In some cases, those requests rewrote information. JPCERT/CC has received multiple reports of three ways attackers do this: They analyze a publicly released smartphone app to find its API endpoints and keys. They attack internal APIs that cannot be used through the app's screens. Reported actions include changing a user's privileges, creating unauthorized accounts, comparing how the server answers when a header is added or removed or a malformed authentication token is sent, and finding account details through blind NoSQL injection. They use API keys stolen when another system was compromised. Macnica's post reports the same method, in a part based on incident response and log analysis. In some cases, attackers took API keys from a smartphone app and called the API in a way that looked like normal use. The attackers search each site and its APIs for any flaw that allows them to obtain data. The flaws include APIs that return more data than necessary, APIs with excessive privileges, member functions accessible to anonymous users, logic errors, and session management faults. Attacks on weak admin-screen passwords and exploitation of known flaws were also confirmed in some cases. The second pattern is a possibility JPCERT/CC raises. Instead of relying on a single flaw shared by all targets, attackers may scan each target for a range of known flaws and attempt to exploit them. They may also be trying attacks that exploit poor system management, such as stealing configuration and backup files. The Metabase Flaw and Which Versions to Run The third pattern is exploitation of CVE-2026-72898, an SQL injection flaw in Metabase, an open-source BI tool that companies connect to their databases. The flaw was exploited as a zero-day against Metabase's own cloud service, the company said on August 6. It carries a CVSS score of 10.0. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog on August 11. An attacker needs no account to exploit it. The flaw allows SQL injection into Metabase's own application database, which can give administrator access. From there, the attacker could steal the stored credentials for connected databases and read or export their data. JPCERT/CC warned about the flaw on August 14. Its new alert adds three source IP addresses that were abused from early August to early September, as well as two User-Agent examples. The alert does not say which organizations the requests from those addresses hit. Attacks continued after the fix was out. AhaSlides said a third party exploited the flaw in its Metabase and had access from August 12 to September 7. Metabase's August 6 security update fixed CVE-2026-72898. The company published another critical advisory on August 11, covering issues it says it found itself. It then raised the lowest release it calls safe for each version. The table shows both for the open-source builds. Metabase numbers the enterprise builds of the August 6 fixes 1.x instead of 0.x. Version Release That Fixes CVE-2026-72898 Metabase's Minimum Safe Release 63 0.63.5 0.63.13 62 0.62.9 0.62.16 61 0.61.11 0.61.18 60 0.60.17 0.60.24 59 0.59.21 0.59.28 58 0.58.24 0.58.31 Versions below 58 are not affected by CVE-2026-72898, and Metabase has already patched its cloud service. Operators who cannot upgrade yet can block the /api/session/reset_password endpoint as a temporary measure. Metabase gives that workaround for CVE-2026-72898. The August 11 advisory tells users to upgrade. A server is likely compromised if its logs show a POST /api/session/reset_password request that returned 400, followed by a GET /api/user/current request that returned 200, Metabase said. Where the reset endpoint was reachable from the internet, Metabase lists six steps to take after upgrading: Revoke all active user sessions. Review API keys and delete any you do not recognize. Review administrator accounts for unexpected changes. Rotate the credentials for every connected database. Review data warehouse logs for signs of unauthorized access. Review Metabase activity and query history for unexpected activity. What Is Not Established Neither JPCERT/CC nor Macnica names the person or group behind the activity or says one group is responsible. In Macnica's assessment, the attackers try any public web system that holds personal data, regardless of who runs it. They may be reusing a method that worked on one target against others, and in some cases share source IP addresses. No use of AI-discovered zero-day flaws in common software has b

Indicators of Compromise

• ip — 103.105.192.18
• ip — 103.105.192.19
• ip — 103.105.192.20
• ip — 103.105.192.21
• ip — 103.105.192.22
• ip — 103.105.192.23
• ip — 103.105.192.24
• ip — 103.105.192.25

Entities