Key takeaways

  • On October 8, 2026, JPCERT/CC, Japan's national computer emergency response team, issued a warning about the run of large data breaches at Japanese organizations since around September. It says its information is still limited and fragmentary, but that the damage is spreading.
  • It describes three patterns: attackers scanning each target for a range of known vulnerabilities and poorly protected files; abuse of internal APIs, often found by analyzing public smartphone apps; and exploitation of a Metabase SQL injection flaw.
  • Victims include not only consumer apps but also BI tools and employee systems that were never meant to be reached by outsiders.
  • JPCERT/CC published attacker IP addresses and User-Agent strings and a list of defenses, centered on API rate limits, access control on every endpoint and short-lived tokens.
  • A separate analysis by the security research center of Macnica, a Japanese technology distributor, counts 119 similar web breaches disclosed in Japan this year, 81 of them since July. It found no sign of AI-discovered zero-days, and says about 80% of disclosures do not explain the cause.

Why this warning matters#

Over the past few weeks we have covered breaches at Times Car, Yakiniku King, Seicomart, Sagawa Express, infoQ and others. Most of the companies said little about how the attackers got in. A day earlier, the privacy regulator warned companies holding large volumes of personal data, without describing the attacks.

JPCERT/CC's warning is the first public, technical description of what is going on. It does not name any victims, and it says not every case uses the same method. We therefore do not link any of the breaches we have covered to a particular pattern below.

JPCERT/CC also makes clear that this is separate from ransomware, which continues at its usual pace. It is focusing on a type of attack that may be increasing and is leading to leaks of large volumes of personal data.

The three patterns#

Case A: Scanning each target for whatever works#

The attacks do not appear to rely on one shared vulnerability. Instead, attackers may be scanning each target for various known vulnerabilities, and also looking for management mistakes that are not vulnerabilities at all, such as configuration files or backup files left where they can be downloaded.

Case B: Abusing internal APIs#

JPCERT/CC has received several reports of attackers sending unauthorized requests to an app's administrative APIs, and in some cases altering data. The reported techniques:

  1. Analyzing publicly available smartphone apps to find API endpoints and keys
  2. Attacking internal APIs that cannot be reached through the normal user interface, to:
    • change a user's privileges
    • create rogue accounts
    • compare responses with and without headers, or with malformed authentication tokens
    • identify account information through blind NoSQL injection
  3. Using API keys stolen from other compromised systems

Case C: A Metabase SQL injection flaw#

The third pattern is the exploitation of CVE-2026-72898, a SQL injection flaw in Metabase, an open-source business intelligence tool. According to JPCERT/CC's earlier warning, an unauthenticated attacker can send a crafted request that runs SQL on Metabase's application database and gain administrator access. Metabase disclosed the flaw on August 6 and said it had already been exploited as a zero-day. JPCERT/CC warned about it on August 14.

Affected versions are the 58 to 63 release lines before x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 and x.63.5. Metabase Cloud has been fixed.

Indicators JPCERT/CC has published#

JPCERT/CC notes that these IP addresses were used by attackers in the periods shown, and may now be in legitimate use. Macnica adds that some may be VPN exit addresses shared with ordinary users. A single hit is not proof of an attack. Large volumes of requests or errors from them are a reason to investigate.

Case B (used around September)

IP address
3.112.252[.]14
54.95.112[.]6
69.10.51[.]162 Also flagged by Macnica as a priority
172.86.91[.]7
210.149.87[.]120 Also flagged by Macnica as a priority

User-Agent examples: curl/7.88.1, python-requests/2.34.2, and a desktop Chrome 126 on macOS string.

Case C, Metabase (used from early August to early September)

IP address
213.163.202[.]171
221.216.140[.]49
221.216.140[.]129

User-Agent examples: python-requests/2.33.1, Metabase-GHSA-vwf4/2.0.

What JPCERT/CC recommends#

For APIs

  • Rate-limit API requests per unit of time, and set separate limits for high-risk functions such as login, password reset, SMS sending and search
  • Enforce access control on every endpoint, including non-public ones, and accept only authorized users and HTTP methods
  • Give API users and tokens least privilege, set expiry dates, avoid long-lived tokens, and be able to revoke unneeded or suspect tokens quickly

In general

  • Restrict access by region if a service is only used in certain areas
  • Patch known vulnerabilities
  • Review controls against lateral movement after a web server is compromised
  • Review detection and first response
  • Advise customers in advance on how to protect themselves, such as with multi-factor authentication
  • Stop exposing unneeded services and admin functions to the internet
  • Delete data that is past its retention period or no longer needed

JPCERT/CC points to the OWASP API Security Top 10 and REST Security Cheat Sheet, and repeats that internal systems such as employee tools and BI tools should be checked too.

Macnica's count: 119 cases this year#

JPCERT/CC cites an analysis by the Security Research Center of Macnica, a Japanese distributor of semiconductors and of IT and security products, written with information from ITOCHU Cyber & Intelligence and Secure Sky Technology. Using only public disclosures, it counts web system breaches in Japan with similar characteristics:

Year Disclosed cases
2024 62
2025 84
2026 (to October 6) 119, of which 81 since July

Macnica excludes ransomware, credential stuffing and phishing aimed at hotel booking systems, and counts a vendor breach affecting several clients as one case. It notes that the targets have spread well beyond online shops: member services, business systems and customer support tools, down to a library catalog search, a sightseeing train's seat booking and a ticket refund system. It believes the attacks are largely indiscriminate, and that a method that works on one site is then tried on others built the same way.

Its findings on the causes are stark. Of the 81 cases since July, the companies' own disclosures attributed:

  • 9 to vulnerabilities in products, CMSs, plugins or analytics tools
  • 4 to stolen credentials or password attacks
  • 3 to configuration or access control mistakes
  • 65 (80%) gave too little detail to say

From its own incident response work, Macnica describes attackers probing each site broadly, using screens and APIs as normal while looking for a gap: APIs that return more data than needed, APIs with excessive privileges, member functions open to anonymous users, flaws in business logic and session handling. It also saw weak admin passwords and known CVEs, and API keys extracted from smartphone apps.

On AI, Macnica is careful. It has seen no evidence that AI found and exploited zero-day flaws in common software. What it sees is broad probing for basic gaps and known vulnerabilities. In a section it labels as largely its own speculation, it adds that no logs prove AI was used, but that repeating this kind of per-site investigation at this scale by hand seems unrealistic.

Not only Japan#

Macnica also looked abroad, and found 99 similar cases in 13 countries and regions, mostly from July to September. South Korea had 30, with a pattern similar to Japan's, followed by France (11) and Poland (8). Japan stands out in its count, but Macnica says disclosure rules and culture differ by country, and it does not know whether Japan alone is being targeted.

Our analysis#

One explanation for many breaches#

In our infoQ article, we speculated that some recent breaches may have exploited how each company built its own application, rather than a known flaw in a popular product. JPCERT/CC and Macnica now describe something close to that: attackers looking for whatever works on each site, especially in APIs, alongside known vulnerabilities. Neither says this explains every case, and we still do not know which pattern applies to any breach we have covered.

The API techniques also match the new API abuse pattern the privacy regulator added to its list a day earlier: unmanaged APIs, guessable IDs and no rate limits.

The app is the map#

Case B starts with public smartphone apps. Any API key or endpoint built into an app can be extracted by anyone who downloads it, however the code is obfuscated. Many of the services hit this autumn are app-first: membership apps, booking apps, point programs. In our view, an API that is "internal" only because it is not shown in the app's screens is not protected at all. The defense JPCERT/CC stresses, checking access on the server for every request, is basic. That it needs to be said suggests how often it is missing.

Disclosures that do not help the next victim#

Macnica's figure that 80% of disclosures do not explain the cause matches our experience this month. Many notices say only "unauthorized access" and give a number. That protects the company, but leaves every other organization unable to check whether it has the same weakness. JPCERT/CC itself says it is issuing this warning because technical information sharing is lacking. Japanese government guidance has encouraged companies to share attack details since at least 2023. This wave shows what is lost when they do not.

Old systems, forgotten tools#

Two of JPCERT/CC's recommendations stand out against the breaches we have covered: stop exposing admin functions to the internet, and delete data that is no longer needed. Leaks of data on former members, unfinished sign-ups and retired systems have been a recurring theme this autumn. A BI tool connected to a customer database, or an admin screen left online, turns a single flaw into a large breach.

What this means for readers#

  • If you run web services or apps that serve users in Japan, check your logs for the IP addresses above, especially for large numbers of API requests, spikes in 403, 404 or 503 errors, and requests for files or API functions that do not exist.
  • Review every API, including those used only by your own app or admin screens. Each one should check authorization on the server, return only the data needed, and be rate-limited.
  • Assume any key in your app is public. Do not embed secrets that grant broad access in mobile apps or browser code.
  • If you run Metabase, make sure you are on a fixed version, and investigate if a vulnerable version was reachable from the internet.
  • If you are a customer of a breached Japanese service, expect more phishing and fraud attempts that use your real details. Macnica suggests that collecting data for scams may be one purpose of these attacks.
  • If your organization has been hit, consider sharing technical details with JPCERT/CC. It is asking for them.

Japanese terms at a glance#

Japanese Reading Meaning
注意喚起 chūi kanki Warning, advisory
不正アクセス fusei akusesu Unauthorized access
情報漏えい jōhō rōei Data leak
脆弱性 zeijakusei Vulnerability
管理用API kanri-yō API Administrative API
不審な送信元IPアドレス fushin na sōshinmoto IP adoresu Suspicious source IP address
レート制限 rēto seigen Rate limiting