Japan's Web Data Leaks Surge as APIs Abused

Attackers have been quietly draining personal data from Japanese websites and apps by abusing the same plumbing that powers everyday mobile services, according to the country's computer emergency response team. The JPCERT Coordination Center (JPCERT/CC) said the leaks have arrived in a cluster around September 2026 and that the methods are distinct from ransomware and other routine intrusions.

The Tokyo-based center based its October 8, 2026 alert on incident reports it has received along with other information. The alert names no attacker and no affected organization, and JPCERT/CC cautioned that its account is \"limited and fragmentary.\" It also noted that the same method may not have been used in every incident.

The scale of the leak wave

Independent analysis from Macnica, a Japanese security research firm, helps put the spike in context. In an analysis published October 7 that JPCERT/CC 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. That compares with 84 in all of 2025 and 62 in 2024.

The concentration is striking: 81 of this year's 119 incidents came in July or later. Macnica's count covers only incidents it judged similar to the current series, leaving out ransomware and cases it ties to other attack groups. Of the 81 made public since July, 65 gave too little detail to determine how the attackers got in.

The targets have spread well beyond online shops. Recent cases include a library's catalog search and a tourist train's seat booking system, alongside member services, business systems and customer support platforms.

Two breaches show the volume

Two disclosures illustrate the volume of records at stake. 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.

The reach is not confined to Japan. 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 behind the intrusions. 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; and they use API keys stolen when another system was compromised. 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.

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 what to run

The third pattern is exploitation of CVE-2026-72898, an SQL injection flaw in Metabase, an open-source business intelligence 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 below shows both the fix and the minimum safe release for the open-source builds; Metabase numbers the enterprise builds of the August 6 fixes 1.x instead of 0.x.

• Version 63: fix 0.63.5, minimum safe 0.63.13
• Version 62: fix 0.62.9, minimum safe 0.62.16
• Version 61: fix 0.61.11, minimum safe 0.61.18
• Version 60: fix 0.60.17, minimum safe 0.60.24
• Version 59: fix 0.59.21, minimum safe 0.59.28
• Version 58: fix 0.58.24, minimum safe 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, the workaround Metabase gives 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; and 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 been confirmed so far.

\"What is actually happening is activity that broadly probes for and exploits more basic flaws in areas such as access permissions, configuration and authentication, as well as known vulnerabilities.\"

— the Macnica post, in a translation from Japanese.

No logs or traces prove that AI was used. The post's author still thinks AI use is hard to rule out, because checking this many sites by hand is not realistic. Neither account says which public breach used which method, because neither names an affected organization.

Indicators and checks

JPCERT/CC published source addresses and User-Agent examples associated with the activity. The addresses were abused in the periods shown and may be in normal use now.

For API abuse around September 2026, the IPs are 3.112.252[.]14, 54.95.112[.]6, 69.10.51[.]162, 172.86.91[.]7 and 210.149.87[.]120. The User-Agents are curl/7.88.1, python-requests/2.34.2 and Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36.

For Metabase exploitation from early August to early September 2026, the IPs are 213.163.202[.]171, 221.216.140[.]49 and 221.216.140[.]129. The User-Agents are python-requests/2.33.1 and Metabase-GHSA-vwf4/2.0.

Macnica lists 210.149.87[.]120 and 69.10.51[.]162 as the first to check. They may include VPN exit addresses that normal users share, so a request from one of them is not proof of an attack. Heavy traffic or many errors from them calls for a detailed log review.

For logs, Macnica suggests going back about a month and looking for heavy API traffic from a single IP address; sudden rises in error responses such as 403, 404 and 503; requests for files or API functions that do not exist; far more requests than usual, even when the server answers 200; use of admin functions that ordinary users are not allowed, or suspicious command execution; access to admin functions from unusual IP addresses; high database load or heavy session use at the same time as a rise in traffic; more errors in database logs; and more login attempts.

For APIs, JPCERT/CC recommends six controls and points to OWASP guidance such as the OWASP API Security Top 10 for details: limit the number of requests per unit of time to stop repeated and bulk calls; set separate rate or usage limits on functions that are costly or easy to abuse, such as login, password reset, SMS sending and search; enforce access control on every API endpoint, including non-public ones, and accept only permitted users and HTTP methods; give API users and tokens only the privileges they need; set an expiry on API tokens and avoid long-lived ones; and be able to revoke quickly any token that is no longer needed or may have leaked.

Macnica adds two checks. Secret API keys and database credentials should not be built into a shipped app or browser code, because minifying or obfuscating the code does not hide them. Vulnerability tests should cover admin functions, which are often left out. JPCERT/CC's general advice includes limiting access by region, where a service is used in one region, disabling unnecessary admin functions on the internet, and deleting data past its retention period. The center said it will update the alert as it learns more about causes and methods.

The privacy regulator weighs in

Japan's Personal Information Protection Commission issued its own alert on October 7 to businesses that handle personal data. It pointed to cases in which widely used services were hit by unauthorized access, with large volumes of personal data leaked or possibly leaked. It reminded businesses to check whether the personal data they hold is still needed.

The commission's guidance on leaks from unauthorized access, revised the same day, includes a case study on API abuse. In it, an attacker logs in to a smartphone app or web service, rewrites request parameters, and gets other users' data.

Why this matters beyond Japan

The pattern JPCERT/CC and Macnica describe is not exotic. It leans on flaws that defenders have been told to fix for years — broken access control, over-permissive tokens, exposed admin interfaces — and it works because mobile apps and internal tools often sit on APIs that no one treats as public-facing. For operators, the practical takeaway is that every endpoint needs the same scrutiny whether or not a user interface points at it. The alert's IP and User-Agent lists give defenders a starting point, but the source addresses may already be in legitimate use, so a hit there is a prompt to look, not a verdict.

For businesses outside Japan, the Macnica count of 99 similar cases across 13 other countries and regions suggests the activity is not contained. The disclosure gap — 65 of the 81 recent Japanese cases lacked enough detail to determine the entry vector — also means the true shape of the campaign may remain unclear for some time. Organizations running Metabase in particular have a concrete action: confirm the version, apply the minimum safe release or later, and if the reset endpoint was ever reachable from the internet, work through the six post-upgrade steps Metabase lists.