iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Japan’s JPCERT/CC warned on October 8, 2026, that personal-data leaks at Japanese organizations had occurred in succession around September, describing several attack patterns rather than one confirmed campaign. The reported methods include probing mobile-app APIs, scanning for different software flaws and exposed files, and exploiting a serious Metabase vulnerability. JPCERT/CC says the information it has is “limited and fragmentary” (translated from its Japanese alert); it does not identify a common attacker or say which method was used in each named breach. Read JPCERT/CC’s October 8 alert.
What is behind the reported rise in Japan data leaks?
JPCERT/CC’s alert describes multiple ways attackers may be reaching data, not a single shared software flaw. It says attackers scan targets for different known vulnerabilities and may take advantage of weak system management, including exposed environment-configuration or backup files. Business-intelligence tools and employee-facing management systems can also be exposed to the internet even when operators did not intend them to be public.
The center reports a pattern of incidents around September 2026, but says the techniques it describes do not necessarily apply to every incident. It names neither victims nor an attacker group. The available information therefore does not establish that the cases form one coordinated campaign or that a specific breach resulted from mobile API abuse or a Metabase exploit.
Recommended Free Tools
What the incident figures do—and do not—show
Macnica Security Research Center counted 119 similar publicly disclosed web-system leak incidents through October 6, 2026, according to The Hacker News’ October 8 report. Macnica’s comparison lists 84 cases in 2025 and 62 in 2024. Of the 119 counted in 2026, 81 were disclosed from July onward; 65 of those 81 reportedly lacked enough detail to determine the entry method. Macnica excluded ransomware and cases it attributed to other attack groups. This is a scoped tally of public disclosures, not a government census of all Japanese breaches, and it does not show that the cases shared a cause.
#1 Best Overall
Other counts use different populations and methods, so they should not be added to Macnica’s tally or treated as proof of a common attack technique:
| Figure | Scope and qualification |
|---|---|
| About 6.6 million Times Car accounts; about 1.6 million accounts with identity documents | Park24 statements dated September 28 and 29, 2026, respectively, concerning data obtained from the service’s web system, as reported by The Hacker News on October 8. The report does not establish that either incident used a specific technique. |
| 10,788,963 Yakiniku King membership records | Monogatari Corporation figure reported by INTERNET Watch on October 5, 2026, as relayed by The Hacker News. The companies were still investigating causes at the time of that report; no particular entry method is established here. |
| 84% of Japan survey respondents experienced an API security incident in the prior 12 months; average estimated cost of US$1,594,385 among respondents whose organizations faced API incidents; 11% said they had a full API inventory and knew which APIs return sensitive data | Akamai’s 2026 APAC API Security Impact Study survey results, not a count of the JPCERT/CC leak series. Read the study. |
| 165 publicly announced corporate security incidents in Japan in calendar 2025; 21,909,319 personal-information records | Cyber Security Cloud’s 2026 report on 2025 incidents. Its collection and classification scope differs from Macnica’s web-system series. Read the report. |
How are attackers abusing mobile app APIs?
A public smartphone app does not make its API keys or administrative endpoints safe. JPCERT/CC says it received reports of attackers analyzing published apps to identify API endpoints or keys, then probing APIs that ordinary app screens do not expose. In some cases, attackers reportedly used API keys stolen when another system had been compromised.
Rank #2
The alert describes attempts to change user privileges or create unauthorized accounts through management APIs, as well as requests that vary headers or malformed authentication tokens to compare server responses. It also reports blind NoSQL injection used to identify account information, and says unauthorized management-API requests have in some cases rewritten information. These are reported techniques; the alert does not attribute them to every incident.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhich Metabase versions are affected by CVE-2026-72898?
JPCERT/CC’s advisory, last updated August 14, 2026, says Metabase disclosed CVE-2026-72898 on August 6 (Japan time). The issue is a serious unauthenticated SQL injection vulnerability: a remote attacker could send a crafted request to run unauthorized SQL against Metabase’s application database and potentially gain administrator privileges. The advisory identifies these affected release ranges and minimum fixed versions:
Rank #3
| Metabase release series | Affected versions named in the August 14 advisory | Minimum fixed version named in that advisory |
|---|---|---|
| 63 | Before x.63.5 | x.63.5 |
| 62 | Before x.62.9 | x.62.9 |
| 61 | Before x.61.11 | x.61.11 |
| 60 | Before x.60.17 | x.60.17 |
| 59 | Before x.59.21 | x.59.21 |
| 58 | Before x.58.24 | x.58.24 |
The advisory says releases before 58 are not affected by this issue and that Metabase Cloud had applied mitigation at the time. Version guidance can change as new releases arrive, so operators should check Metabase’s current security update and patch to a currently supported fixed release rather than relying only on the minimum versions in the August advisory. See JPCERT/CC’s Metabase advisory.
How can an operator check for possible compromise?
If the password-reset endpoint was accessible from the internet, JPCERT/CC advises checking for compromise even after updating. Its advisory identifies a suspicious sequence to look for in logs: POST /api/session/reset_password returning HTTP 400, followed by GET /api/user/current returning HTTP 200.
Rank #4
- API Security in Action
- Manning Publications
- ABIS BOOK
If compromise is possible, review Metabase user sessions, API keys, administrator accounts, connected database credentials, and Metabase and database logs. Change connected database credentials when warranted. If immediate updating is not possible, the advisory relays Metabase’s temporary workaround: block access to /api/session/reset_password. Endpoint blocking is a stopgap, not a replacement for installing a fixed release.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →How can companies secure mobile app APIs and exposed web systems?
JPCERT/CC’s recommendations focus on controls that reduce the damage from stolen credentials, overlooked endpoints, and exposed services:
Best Value
- Inventory APIs and enforce authorization everywhere. Include internal and non-public APIs, not only endpoints visible in app screens. Check every endpoint’s authorization rules and allow only permitted users and HTTP methods.
- Limit abuse by function. Apply request-rate limits, with separate quotas for login, password reset, SMS sending, and costly or abuse-prone searches.
- Restrict and retire credentials. Give API users and tokens only the permissions they need, set token expiry, and promptly revoke credentials that are no longer needed or may have leaked. Do not treat a key embedded in a public app as secret.
- Patch and reduce exposure. Apply fixed software updates, remove services and administrative features that do not need to be public, and restrict access by geography when the service is intended for a limited region. Check for exposed configuration and backup files.
- Prepare for what happens after entry. Review how an intruder who compromises a web server could move laterally, improve detection and initial response, and prepare customer guidance to reduce secondary harm, including guidance on enabling MFA.
- Delete data when it is no longer needed. Remove information when its legal or contractual retention period ends or its original purpose has been fulfilled.
JPCERT/CC points readers to OWASP’s API Security Top 10 and REST Security Cheat Sheet for further detail in its October alert.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
