Macnica counted 119 public incidents through October 6, 2026, in which personal data was stolen or leaked from web systems run by organizations in Japan — and 81 of those 119 were revealed from July onward, a startling concentration that coincides with a wave of API abuse and targeted exploitation of a Metabase flaw.
Scope and scale: the public tally and two large disclosures
Two of the largest publicly disclosed cases in late September illustrate the scale and variety of the breaches. 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; the company later said identity documents, including driver's license images, 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 the cause was under investigation at the time.
Macnica’s October 7 analysis — which the JPCERT Coordination Center (JPCERT/CC) cited in its October 8 alert — limited its count to incidents similar to the current series and excluded ransomware and incidents tied to other groups. 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.
Three attack patterns JPCERT/CC describes
JPCERT/CC summarized three recurring patterns behind the leaks. The first is unauthorized requests to management APIs behind smartphone apps: attackers analyze publicly released apps to discover endpoints and embedded keys, call internal admin APIs that are not exposed through the app’s screens, or reuse API keys stolen from other compromised systems. Reported actions include changing privileges, creating unauthorized accounts, blind NoSQL injection to find account details, and crafting header or token variations to probe server behavior.
The second pattern is broad scanning and exploitation of known flaws and poor system management: attackers may scan each target for a range of known vulnerabilities, or try to steal configuration and backup files. JPCERT/CC and Macnica observed attacks that exploited weak admin-screen passwords and known software flaws in some cases.
The third pattern is exploitation of CVE‑2026‑72898, an SQL injection vulnerability in Metabase that allows SQL injection into Metabase’s application database without an account. The flaw can lead to administrator access to Metabase itself and to stored credentials for connected databases, enabling data export from those databases.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleMetabase timeline, detection cues, and post‑remediation steps
Metabase released a security update for CVE‑2026‑72898 on August 6; the company published another critical advisory on August 11 and then raised the minimum release it calls safe in a list last updated August 14. Metabase notes that versions below 58 are not affected and that it has already patched its cloud service.
Operators who cannot upgrade immediately can block the /api/session/reset_password endpoint as a temporary mitigation. Metabase says a likely sign of compromise is a POST /api/session/reset_password request that returned 400 followed by a GET /api/user/current request that returned 200. After upgrading, Metabase lists six recommended steps: revoke all active user sessions; review and delete unrecognized API keys; review administrator accounts for unexpected changes; rotate credentials for every connected database; review data warehouse logs for unauthorized access; and review Metabase activity and query history for unexpected activity.
Indicators, log checks, and API controls defenders should apply
JPCERT/CC published IP addresses and User‑Agent examples its alert ties to the incidents. For API abuse around September 2026, it listed these IP addresses and User‑Agents:
- 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 (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, JPCERT/CC listed:
- 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 cautioned that addresses such as 210.149.87[.]120 and 69.10.51[.]162 may be shared VPN exit nodes and are not proof of attack by themselves; heavy traffic or many errors from them merits detailed log review. Suggested log checks include looking back about a month for heavy API traffic from a single IP, sudden rises in error responses (403/404/503), requests for nonexistent files or endpoints, unusually high database load concurrent with traffic spikes, and use of admin functions by anonymous or unusual IP addresses.
JPCERT/CC also pointed defenders to API controls aligned with OWASP guidance: rate limits on requests; separate usage limits for costly or abuse‑prone functions (login, password reset, SMS, search); enforce access control on every endpoint including non‑public ones; grant tokens only the privileges needed and set expirations; and be able to rapidly revoke leaked tokens. Macnica added that secret API keys and database credentials should not be built into shipped apps or browser code and that vulnerability tests must include admin functions.
What this means for security teams, regulators, and users
Security teams should prioritize log reviews for the listed indicators, apply Metabase mitigations if relevant, and enforce per‑endpoint access controls and token hygiene. The Personal Information Protection Commission issued an alert on October 7 reminding businesses that handle personal data to check whether held data is still needed and pointing to API‑abuse case studies in its revised guidance. End users should expect breach notices where large volumes of personal data were exposed and organizations should follow Metabase’s recommended remediation steps if they used affected versions.
JPCERT/CC said its knowledge is “limited and fragmentary” and that it will update the alert as it learns more; neither JPCERT/CC nor Macnica attributes the activity to a named actor. The immediate record is of widespread probing for and exploitation of APIs and known software flaws, large public disclosures of personal data, and concrete technical indicators that defenders can and should act on now.
