Your internal dashboards were never meant to be public — JPCERT says attackers are finding them anyway

The dashboards and admin panels your staff use every day were never meant for the public. Japan’s national CERT says that’s exactly where a wave of recent data leaks came from. On October 8, JPCERT/CC warned that BI tools and employee-only admin systems, built on the assumption that “nobody outside will ever hit this,” are being found and drained.

The advice isn’t specific to Japan. If you run Metabase, an internal API behind a mobile app, or an admin page someone exposed “temporarily,” it applies to you.

“Internal only” is a promise to yourself. It isn’t a firewall rule.

The 5-Minute Cyber Brief

Don’t Miss the Policy Changes That Affect Security Decisions

Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.

Email addressSend me tomorrow’s brief

By subscribing you agree to our Privacy Policy.

Free. Weekday mornings. 5 minutes or less.

What happened

JPCERT/CC alert JPCERT-AT-2026-0030 says personal data leaks from unauthorized access at Japanese organizations have been piling up around September 2026. It describes three patterns:

• Scanning for known bugs and sloppy setups: many different known vulnerabilities depending on the target, plus grabbing exposed environment and backup files.
• Abusing APIs directly: pulling endpoints and keys out of public mobile apps, calling internal APIs the UI never exposes to change user roles or create accounts, blind NoSQL injection to enumerate account data, and API keys stolen from other breaches.
• Metabase SQL injection (CVE-2026-72898), the bug Metabase disclosed on August 6 after attackers used it as a zero-day against versions 58 and later. JPCERT says it saw exploitation from early August to early September.

Why it matters

These systems sit close to the data. A BI tool usually holds stored credentials for your warehouse. An admin API can change who is allowed to see what. And because they’re “internal,” they often get the weakest authentication and the slowest patching.

What to do first

• List every BI tool, admin panel and internal API reachable from the internet. Anything that doesn’t need to be public goes behind VPN or SSO, or gets switched off. That’s JPCERT’s own recommendation.
• If you self-host Metabase on version 58 or later, upgrade to the minimum safe point release for your line: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 or 0.63.5. If you can’t, block /api/session/reset_password.
• If that Metabase endpoint was publicly reachable, also clear the core_session table, review API keys and admin accounts, and rotate the credentials of every connected database.
• Add rate limits to login, password-reset, SMS and search endpoints. Enforce access control on every API route, not just the ones the UI calls. Use least-privilege, short-lived API tokens.
• Delete data you no longer need to keep. It can’t leak if it’s gone.

Details

• Alert: JPCERT-AT-2026-0030, published October 8, 2026 (Japanese).
• Suspicious sources, API abuse (seen around September; may now be reassigned): 3.112.252[.]14, 54.95.112[.]6, 69.10.51[.]162, 172.86.91[.]7, 210.149.87[.]120. User agents included curl/7.88.1 and python-requests/2.34.2.
• Suspicious sources, Metabase (early August to early September): 213.163.202[.]171, 221.216.140[.]49, 221.216.140[.]129. User agents included python-requests/2.33.1 and Metabase-GHSA-vwf4/2.0.
• Metabase: CVE-2026-72898; vulnerable on versions 58 and above below the listed point releases; versions below 58 are not affected. Metabase Cloud was patched by the vendor.

Hunt / verify

• In Metabase or ingress logs, look for POST /api/session/reset_password returning 400 followed by GET /api/user/current returning 200. Metabase says that pattern likely means compromise.
• Search web and API logs for the JPCERT IP addresses and the Metabase-GHSA-vwf4 user agent.
• Review recent role changes and newly created accounts in internal apps, and API calls to endpoints the front end never uses.
• Check your web roots for exposed .env, backup and archive files.

Slack paste: JPCERT (Oct 8): wave of data leaks via internet-exposed BI tools/admin systems: scanning for known bugs, internal-API abuse (role changes, rogue accounts, NoSQLi, stolen keys), Metabase CVE-2026-72898. Action: inventory exposed dashboards/APIs, put them behind VPN/SSO, Metabase to 0.58.24/0.59.21/0.60.17/0.61.11/0.62.9/0.63.5, rate-limit + per-route access control.

Sources

• JPCERT/CC: JPCERT-AT-2026-0030 alert on recent unauthorized access at Japanese organizations (Japanese)
• JPCERT/CC: Metabase SQL injection vulnerability alert (Japanese)
• Metabase: Security update available, please upgrade now (August 6, 2026)
• The Hacker News: Japan sees sharp rise in web data leaks

George Bailey

George Bailey is the byline of the CyberExperts editorial desk, the team behind the CyberExperts Daily Brief. The desk covers vulnerabilities, breaches and security news from vendor advisories, CISA alerts and other primary sources, and links those sources in every story. Questions or corrections: [email protected].