Image: jpcert.or.jp · rights & removal
Executive Summary
Facts Only
* Damage is occurring across multiple products and services without information sharing.
* The advisory addresses attack types increasing related to personal information leakage, such as sporadic ransomware attacks.
* Systems like BI tools or employee management systems are damaged, leading to internal information leakage.
* Case A involves exploration of known software vulnerabilities or exploiting mismanagement of equipment (e.g., stealing configuration files).
* Case B involves unauthorized operations via API, including analyzing applications for endpoints/keys and attacking internal APIs through methods like changing permissions or NoSQL injection.
* Suspicious source IP addresses observed around September include 3.112.252[.]14, 54.95.112[.]6, 69.10.51[.]162, 172.86.91[.]7, and 210.149.87[.]120.
* Case C involves a SQL Injection vulnerability in Metabase (CVE-2026-72898), exploitable via unauthorized API requests.
* Suspicious source IP addresses observed for Case C include 213.163.202[.]171, 221.216.140[.]49, and 221.216.140[.]129.
* Case D involves the installation of web shells (.jsp files) on application servers accessible from public web servers, allowing execution of shell commands via query parameters.
Full Take
The pattern observed is a shift in attacker focus from exploiting known software flaws to leveraging complex application logic and API interfaces for data exfiltration and system control. The segmentation into Case A (vulnerability scanning/mismanagement), Case B (API abuse), Case C (specific injection), and Case D (web shell deployment) suggests a multi-vector approach aimed at systemic compromise rather than single point exploitation. This points to an awareness among threat actors that application interfaces, especially APIs, are primary control surfaces. The focus on API security countermeasures—rate limiting, granular access control, and token management—is directly addressing the mechanics described in Case B. However, the fact that a specific vulnerability (SQL Injection in Metabase) is tied to the API context indicates that known flaws become entry points when paired with unauthorized access methods. The information provided regarding specific IP addresses linked to different attack phases suggests an evolving campaign where reconnaissance and initial access are separate steps feeding into deeper exploitation. This necessitates questioning how security teams prioritize patching known vulnerabilities versus hardening abstract API interaction flows, and whether the mitigation strategies effectively address both the superficial vulnerability fixes and the underlying architectural control failures.
BRIDGE QUESTIONS:
If an attacker successfully maps out API endpoints and credentials through legitimate application interactions, how can systems differentiate between authorized business logic requests and malicious unauthorized operations? What metrics should be implemented to measure the risk exposure associated with API token usage versus traditional access controls? How can organizations institutionalize a response that addresses both immediate technical patching and the broader systemic failure of information flow management suggested by this advisory?
From the original · JPCERT/CC Alerts
JPCERT-AT-2026-0030 JPCERT/CC October 8, 2026 (Published) October 9, 2026 (Updated) As damage is occurring across multiple products and services, there is a lack of technical information sharing. Although the information we possess is limited and fragmented, in light of the situation regarding the expansion of attack damage, we hereby issue the following warning.Read the full story at jpcert.or.jp
Sentinel — Human
This text reads like an official security advisory released by a coordinating body, characterized by structured technical detail and formal language, though it is highly likely this information is synthesized based on real events.
