From July to September 2026, Japanese organizations faced a sharp increase in personal data breaches via web systems: according to Macnica, 119 incidents were recorded in just three quarters, whereas the whole of 2025 saw 84, and individual cases (Park24, Monogatari) have led to the compromise of tens of millions of records; JPCERT/CC links the wave to widespread abuse of mobile and internal APIs, as well as exploitation of the critical vulnerability CVE-2026-72898 in Metabase, so operators of web services, mobile applications and BI systems must urgently inventory APIs accessible from the internet and update Metabase to at least minimally safe versions.
Technical details of the incidents
Scale and timeline
Analysis by Macnica Center shows that as of 6 October 2026, 119 publicly disclosed incidents in Japan involved data leaking through web systems, with:
- 62 incidents in 2024;
- 84 in 2025;
- 119 already in 2026, of which 81 occurred since July, indicating a sharp spike.
The series does not include ransomware and other “classic” attacks — it is specifically about compromise of the web and API layers. In its notification of 8 October 2026 (official JPCERT/CC alert), JPCERT/CC notes a stream of incidents “one after another” around September.
Characteristic major cases:
- Park24 (Times Car): unauthorized access to data from about 6.6 million accounts of the car sharing service, and separately, a leak of ID document images of roughly 1.6 million users.
- Monogatari (Yakiniku King app): leak of 10,788,963 records from the member system.
The cause of these incidents is still officially under investigation, but in terms of scale and profile they fit into the series described by Macnica.
Main API attack vectors
JPCERT/CC highlights several recurring patterns of abuse of mobile and web application APIs:
- Analysis of the mobile application and extraction from it of:
- the list of backend API endpoints;
- API keys and tokens hardcoded in the application.
The attacker then crafts direct HTTP requests to these endpoints, sometimes in a way that makes the traffic resemble normal usage, which complicates detection.
- Access to “internal” API functions not exposed in the application interface:
- changing user privilege levels;
- creating unauthorized accounts;
- testing server behavior when modifying headers, removing a token, or sending a corrupted authentication token;
- searching for account details via “blind” NoSQL injection.
- Reuse of stolen API keys compromised in other systems.
Typical mistakes on the defender’s side:
- endpoints return more data than needed for a specific operation;
- the API performs operations with excessive privileges;
- functionality intended for members is available to anonymous users;
- flaws in authorization logic and session management.
Macnica additionally emphasizes that API secret keys and database passwords embedded in a client application or browser code are easily extracted even from minified or obfuscated code, and therefore such practices are unacceptable (Macnica analysis).
Exploitation of CVE-2026-72898 in Metabase
A separate vector is attacks on Metabase, a popular BI tool, via the critical SQL injection CVE-2026-72898 with a CVSS score of 10.0 (NVD entry for CVE-2026-72898). The vulnerability:
- is exploitable without an account;
- allows SQL injection into Metabase’s own database;
- enables the attacker to obtain Metabase administrator privileges;
- from there, the attacker can dump stored credentials of connected databases and gain access to their contents.
Metabase reported an incident in its cloud service on 6 August 2026 and released a security update (update of 6 August). Later the company published an extended list of minimally safe versions for different product branches (security release of 12 August) and an additional warning on several critical issues (GitHub security advisory).
The key sign of CVE-2026-72898 exploitation according to Metabase:
- the server logs contain
POST /api/session/reset_passwordwith a 400 response code; - followed by
GET /api/user/currentwith a 200 response code.
A temporary measure for those who cannot update immediately is to block the /api/session/reset_password endpoint at the web server or web application firewall level. Metabase explicitly describes this as a temporary workaround, not a complete solution.
IOC from JPCERT/CC and Macnica
JPCERT/CC has published a set of indicators of compromise (relevant as a reference, not as a “blacklist,” since the addresses may have been reused by legitimate traffic).
Suspicious API activity (around September 2026)
- IP: 3.112.252[.]14
- IP: 54.95.112[.]6
- IP: 69.10.51[.]162
- IP: 172.86.91[.]7
- IP: 210.149.87[.]120
- User-Agent:
curl/7.88.1 - User-Agent:
python-requests/2.34.2 - User-Agent:
Mozilla/5.0 ... Chrome/126.0 Safari/537.36
Metabase exploitation (early August — early September 2026)
- IP: 213.163.202[.]171
- IP: 221.216.140[.]49
- IP: 221.216.140[.]129
- User-Agent:
python-requests/2.33.1 - User-Agent:
Metabase-GHSA-vwf4/2.0
Macnica separately highlights IPs 210.149.87[.]120 and 69.10.51[.]162 as priorities for review, stressing that the presence of requests from these addresses is only a reason for in-depth log analysis, not direct proof of an attack.
Threat context and geography
Although JPCERT/CC and Macnica do not attribute the series of breaches to a specific threat actor, a unified style is evident: attackers massively “probe” any publicly accessible web systems that may contain personal data and exploit any discovered weakness in authentication, authorization, configuration, or known vulnerabilities.
The list of affected systems goes far beyond online stores: membership services, business systems, customer support, library catalogs, and tourist train reservation systems. Macnica has also found 99 similar incidents in 13 countries and regions outside Japan (including 30 in South Korea, 11 in France, and 8 in Poland), which indicates the global nature of the attackers’ approach.
The use of automation (up to and including AI-based vulnerability discovery) has not yet been confirmed: there are no direct signs of such tools in the logs, but the breadth and intensity of the scanning make a completely manual approach unlikely — an important signal to revise the range of tested scenarios during security audits.
Impact assessment for organizations
At highest risk are:
- organizations with mass consumer mobile applications (banking, retail, transportation, entertainment);
- services using an “account + bonuses/subscription” model that store contact details, order history, and loyalty card numbers;
- companies using Metabase, especially where the dashboard and API are directly exposed to the internet;
- organizations where BI platforms have access to production databases containing personal information.
Potential consequences of inaction:
- mass personal data breaches (names, contact details, identity documents, behavioral data);
- regulatory sanctions from data protection authorities (in Japan, the Personal Information Protection Commission, which has already issued its own alert and methodological guidance: alert PPC, guidance PPC);
- compromise of business analytics and production databases via Metabase as a single entry point;
- reputational damage and rising costs for notifying affected individuals and handling subsequent lawsuits.
Practical protection recommendations
1. Immediate measures for Metabase owners
- Identify all Metabase instances (on-premise and in the cloud) that are accessible from the internet.
- Compare current versions with the minimally safe ones published by Metabase (list of safe releases) and update immediately at least to the recommended release.
- Until the update — block
/api/session/reset_passwordfrom external access as a temporary risk mitigation. - Check logs for the presence of the following sequence:
POST /api/session/reset_password→ HTTP 400;GET /api/user/current→ HTTP 200.
If such a chain is detected, the server should be considered compromised.
- For instances where the endpoint was accessible from the internet, after updating perform the full recovery cycle recommended by Metabase:
- invalidate all active user sessions;
- review and delete suspicious API keys;
- audit administrator accounts;
- change passwords and keys for all connected databases;
- analyze data store logs for anomalous queries;
- review Metabase query history for unexpected data extractions.
2. Hardening APIs and mobile backends
Recommendations from JPCERT/CC and OWASP API Security (OWASP API Security Top 10) define the basic minimum of controls:
- rate limiting, especially for:
- authentication and login;
- password reset;
- sending SMS and email notifications;
- search and other resource-intensive functions.
- strict authorization on every endpoint, including “non-public” ones:
- checking permissions not only for user operations but also for administrative actions;
- separate validation of allowed HTTP methods.
- principle of least privilege:
- restricting data scopes for each key and token;
- avoiding “universal” keys with all permissions.
- a strict lifetime for API tokens and the ability to revoke them quickly in case of a leak.
- prohibition on storing secrets (API keys, DB passwords) in mobile applications and frontend code.
- including administrative functions within the scope of regular vulnerability testing.
3. Monitoring and retrospective log analysis
In the coming month it makes sense to conduct an in-depth review of web server, API gateway and database logs for a period of at least 30 days, paying attention to:
- an abnormally large volume of API requests from a single IP address;
- spikes in 403, 404, 503 and other error responses;
- requests to non-existent endpoints and files;
- a significant increase in the total number of requests with status 200 (abuse of “legitimate” calls);
- use of administrative functions from atypical IP addresses;
- increased database load and session pool usage coinciding with traffic anomalies;
- an increased number of login attempts.
The key takeaway for affected and potentially vulnerable organizations: an urgent review of Metabase versions and isolation of Metabase from direct internet access is required, together with the simultaneous implementation of strict access controls and rate limits for all API endpoints, as well as retrospective log analysis for at least one month based on the specified indicators, followed by reissuing compromised keys and passwords.
