As reported by The Hacker News, Japan's JPCERT Coordination Center (JPCERT/CC) issued an October 8, 2026 alert documenting a sharp escalation in personal data leaks from Japanese organizations. The findings, corroborated by Macnica's Security Research Center, reveal 119 publicly disclosed incidents through October 6 — already exceeding the 84 incidents logged in all of 2025 — with 81 of those occurring since July alone. Two incidents alone account for over 17 million compromised records: Park24's Times Car platform (6.6 million accounts, 1.6 million with identity documents) and Monogatari Corporation's Yakiniku King app (10.7 million records).
Why This Matters Beyond Japan
The JPCERT/CC alert highlights two attack vectors that are globally prevalent, not Japan-specific: mobile API abuse and exploitation of known vulnerabilities in business intelligence tools. The fact that these incidents are occurring in rapid succession and at scale suggests organized reconnaissance and tooling rather than opportunistic hits.
The Metabase Factor
JPCERT/CC specifically names Metabase — an open-source BI platform — as a targeted product. Metabase has a documented history of critical vulnerabilities, most notably CVE-2023-38646 (CVSS 9.8, Critical), a pre-authentication remote code execution flaw via crafted JDBC connection strings. The article notes that Metabase has urged upgrades to releases newer than the initial fix, suggesting the original patch was insufficient and that attackers are continuing to find bypass routes. This is a pattern we've seen across the industry: initial patches that don't fully address the root cause, leaving defenders with a false sense of closure.
| Vulnerability | CVSS | Severity | Type | Patch Status |
|---|---|---|---|---|
| CVE-2023-38646 | 9.8 | Critical | Pre-auth RCE via JDBC | Patched (verify version ≥ safe release) |
Key takeaway: If you patched Metabase once and moved on, you may still be exposed. Verify you are running a version from Metabase's latest safe release list, not just the version that first addressed the original CVE.
The API Attack Surface Problem
JPCERT/CC's inclusion of eight source IP addresses, five User-Agent strings, and specific API endpoint recommendations tells us the mobile API abuse is not sophisticated zero-day exploitation. It is likely authentication bypass, broken object-level authorization (BOLA/IDOR), and excessive data exposure — the exact failure modes OWASP has flagged in its API Security Top 10. Attackers are harvesting data at scale because endpoints designed for app backends are accessible from the public internet with inadequate access controls.
Who Is at Risk
Shield53 Recommendations
Immediate Actions
- Audit all Metabase deployments — confirm you are running a version on Metabase's current safe release list (last updated August 14, 2026), not merely the version that first patched CVE-2023-38646
- Inventory and test every mobile API endpoint for BOLA/IDOR — every endpoint that returns user data must enforce per-record authorization, not just session-level authentication
- Block or restrict internal BI tools behind VPN, zero-trust access, or IP allow-listing; remove them from public DNS where possible
- Correlate against JPCERT/CC IOCs — the eight source IPs and five User-Agent strings — in your WAF, SIEM, and CDN logs, with alerts configured for any matches in the last 90 days
- Rate-limit and throttle bulk data access patterns on all API endpoints; flag any single session or IP pulling abnormal record volumes
Strategic Hardening
- Adopt a default-deny posture for any system not explicitly intended for public access
- Implement API gateway controls that enforce schema validation, payload size limits, and response field filtering
- Conduct quarterly attack surface discovery to identify forgotten or shadow internet-facing systems
- Map all external assets against CISA KEV and vendor advisory lists on a continuous — not annual — basis
The Japanese data leak series is a warning shot, not an isolated event. The combination of exposed internal tools, under-secured mobile APIs, and incompletely patched vulnerabilities creates a breach surface that exists in nearly every modern enterprise. The difference between the organizations that appear in the next JPCERT alert and those that don't will come down to whether defenders treat API authorization and BI tool exposure as ongoing operational priorities rather than one-time patch exercises.
