JPCERT warns of a wave of API attacks and Metabase exploits draining personal data from Japanese organisations

TOKYO: Japan’s national CERT, JPCERT/CC, issued alert JPCERT-AT-2026-0030 on 8 October 2026 after a run of intrusions around September 2026 leaked personal data from multiple Japanese organisations.

The agency says technical information sharing has been thin and what it knows is partial, but the pace of breaches justified a public warning.

JPCERT says this activity is separate from routine ransomware.

It is a fast-growing attack pattern behind large personal-data leaks.

Victims include consumer apps as well as systems never meant for the public internet, such as business intelligence (BI) dashboards and employee management portals.

Case A: opportunistic scanning for known flaws

The attacks do not rely on one shared vulnerability.

Operators scan each target for a range of known flaws and also look for weak configuration, such as exposed environment files and backup files that can be downloaded and mined for credentials.

Case B: abuse of internal APIs

JPCERT has several reports of attacks on app management APIs that let intruders rewrite data.

The reported methods are:

• Decompiling public smartphone apps to pull out API endpoints and keys.
• Calling internal APIs that the app’s interface never exposes, to raise user privileges or create rogue accounts.
• Probing authentication by adding or removing headers and sending malformed tokens to see how responses change.
• Blind NoSQL injection to work out account details.
• Reusing API keys stolen in breaches of other systems.

Indicators seen around September 2026 (these addresses may be in legitimate use now):

• 3.112.252[.]14
• 54.95.112[.]6
• 69.10.51[.]162
• 172.86.91[.]7
• 210.149.87[.]120

User agents seen include curl/7.88.1, python-requests/2.34.2 and a Chrome 126 on macOS string.

Case C: Metabase SQL injection (CVE-2026-72898)

The open-source BI platform Metabase is being exploited through crafted API requests that abuse a SQL injection flaw JPCERT first flagged on 14 August 2026.

Exploitation came from the addresses below between early August and early September 2026:

• 213.163.202[.]171
• 221.216.140[.]49
• 221.216.140[.]129

User agents seen were python-requests/2.33.1 and Metabase-GHSA-vwf4/2.0.

What defenders should do

For APIs, JPCERT recommends:

• Rate-limit every API, with tighter limits on login, password reset, SMS and search.
• Enforce access control on every endpoint, including undocumented ones, and allow only approved users and HTTP methods.
• Give tokens the least privilege they need and short lifetimes, and make sure leaked or unused tokens can be revoked quickly.

More broadly, organisations should:

• Patch known-vulnerable software, starting with Metabase.
• Geo-restrict access where the user base is local.
• Take unneeded admin features off the internet.
• Review controls that limit an attacker’s movement after a web server is breached.
• Test detection and first response.
• Delete data kept past its retention period.
• Prepare breach notices that tell customers to turn on multi-factor authentication.

JPCERT points defenders to the OWASP API Security Top 10 and says internal BI and staff systems deserve the same review as public apps.

Analyst note

The common thread is that a hidden API is not a secure API.

Mobile apps ship their endpoints and keys inside the installer file, so anything reachable from the app should be treated as public.

Teams should audit what their app binary exposes, inventory every BI instance facing the internet, and check API logs for scripted user agents such as python-requests hitting admin routes.