Arcadia: Unauthorized Access Hits Municipal Disaster Alert Platform SpeeCAN RAIDEN

Arcadia Inc. is an IT firm based in Minoo, Osaka Prefecture. It runs a mass notification service that Japanese local governments use to send disaster warnings to residents. The company says an outside party gained unauthorized access to the service, called SpeeCAN RAIDEN, and that contact records for millions of people may have leaked. Estimates of the email addresses at risk range from "more than 3 million" (NHK) to about 3.14 million (Kyodo News), and the company's own blog gives a maximum of about 3,136,000, as cited by NEXSIGHT CYBER WIRE. Reports of how many organizations use the service also differ. NHK says "nearly 800 entities," while Kyodo says 875 local governments used it as of late September. By 5 p.m. on October 14, the Ministry of Internal Affairs and Communications (MIC) had received reports of service suspension or possible data leakage from 110 local governments. Arcadia has not said how the attacker got in, and it says it does not yet know when the service will be restored.

What Happened

The reports agree on the timeline. The details below come mainly from NEXSIGHT, which summarizes Arcadia's own disclosures.

• October 11 (Sunday), 16:30 JST: Arcadia notices suspicious behavior on RAIDEN that suggests unauthorized access.
• October 12 (Monday), around 03:00 JST: As a stopgap, the company closes off the intrusion path and starts investigating. NHK describes this as access being "blocked on Monday."
• October 13, 11:00 JST: The investigation identifies the external intrusion path. Arcadia shuts down the affected environments as an emergency measure. These are RAIDEN customers on raiden3.ktaiwork.jp and customers of its school product "Raiden School" on s2.ktaiwork.jp. It also blocks the attacking IP address. For the services it kept running, Arcadia says it checked the servers and found no malicious programs installed.
• October 13, evening: Arcadia publishes its disclosure and record estimates, with a blog update at 18:47.
• October 14: MIC asks Arcadia to report on the damage. Kyodo reports that Arcadia also found signs of unauthorized access on its fire department services, NET 119 and 119 RAIDEN. Fire departments use these to send alerts to personnel, volunteer firefighters and media outlets.

Several prefectures, including Oita, Shizuoka, Shiga and Kagawa, have paused use of the service. So have municipalities including Yokote (Akita), Minoo, Hatsukaichi and Toyono. Police are affected too. Shimane prefectural police say up to about 16,000 email addresses registered for their crime prevention alerts, which run on an Arcadia system, may have leaked. Kyodo, citing investigative sources, reports that Hiroshima prefectural police have found a possible leak as well.

What Was Taken

Arcadia describes the data as possibly leaked. It has not confirmed that any data was taken. All of its figures are estimated maximums, and the investigation is still going.

The exposed fields include registered contacts' names, email addresses, and phone and fax numbers. Information on the staff who manage accounts and on contract holders is also exposed. So is the body text of past messages stored in the delivery history. Six service environments are in scope: raiden.ktaiwork.jp, raiden2.ktaiwork.jp, raiden3.ktaiwork.jp, raiden2.speecan.jp, s.ktaiwork.jp and s2.ktaiwork.jp. Arcadia says the service does not handle credit card or other payment data.

The data is sensitive mainly because of what it reveals. It shows which residents signed up for which municipality's alerts, and the message history includes the official wording those authorities use. Kyodo also notes that local governments use the service to check on their own employees' safety during emergencies, so staff contact lists are likely among the records.

Why It Matters

• It breaks a trusted channel. Residents expect emergency messages from these sender identities and have been trained to act on them quickly. An attacker who knows who is subscribed and how official alerts are worded has what they need to send convincing fake disaster warnings. Oita, Shizuoka and Shiga are already warning residents to watch for suspicious emails.
• One vendor, hundreds of victims. A single SaaS provider has caused service suspensions or leak reports at 110 or more local governments, plus fire departments and police. Each customer outsourced the same key function to the same provider, so they all lost it at once.
• It is part of a wider wave. JPCERT/CC's alert from October 8 (updated October 9) describes a run of large personal data breaches at Japanese organizations since around September. Japan Cyber Watch cites Macnica research counting 119 similar web breaches disclosed in Japan in 2026, 81 of them since July. About 80% of those disclosures do not explain the cause. No source links the Arcadia intrusion to this campaign. The JPCERT alert is context, not attribution.
• A separate Osaka incident is unrelated. Two other sources cover a ransomware attack on Osaka Metropolitan University, which took down about 500 servers starting October 2 and may have exposed data on at least 130,000 people. The reports differ on how far details had been confirmed, and nothing connects that attack to Arcadia.

The Attack Technique

The way in has not been disclosed. Arcadia says only that the incident "was caused by unauthorized access by a third party." It has also said it found an "external intrusion path," traced it to specific hosts and blocked a source IP. It has not named any vulnerability, credential compromise or threat actor, and no group has claimed the attack.

For defenders, the most useful reference is the JPCERT/CC alert, though it is not tied to Arcadia. It describes four patterns seen in the current Japanese breach wave:

1. Case A: Scanning each target for many different known vulnerabilities and for poorly protected files such as configuration files and backups. One source IP flagged was 20.210.128[.]125, seen around October 7.
2. Case B: Abuse of internal and admin APIs, often found by analyzing public smartphone apps. Techniques include changing user privileges, creating accounts, sending malformed auth tokens to compare responses, blind NoSQL injection, and using API keys stolen from other breaches. JPCERT lists more than ten IPs, with User-Agents such as curl/7.88.1 and python-requests/2.34.2.
3. Case C: A Metabase SQL injection flaw, CVE-2026-72898.
4. Case D: Web shells hidden in WAR files on Java application servers that can be reached from public web servers.

A separate ITD analysis of incidents disclosed in August 2026 found that more of them started with valid credentials than with exploited vulnerabilities. Examples included a subcontractor's Microsoft 365, BI tools, mailboxes, GitHub tokens and a hosting provider's console. Without a disclosed cause, defenders should treat both credential misuse and exploitation as possible routes for the Arcadia intrusion.

What Organizations Should Do

1. RAIDEN, NET 119 and 119 RAIDEN customers: Assume your subscriber lists and message history are exposed. Tell residents and staff through an independent channel, such as your official website or broadcast partners, that you will never ask for personal data or payment in an alert. Prepare guidance in advance for fake alerts that may follow.
2. Rotate everything tied to the vendor. This includes admin and contract-holder passwords, API keys and any integration tokens used with Arcadia services. The staff and contract-holder details in scope can be used for targeted phishing.
3. Check your environment against JPCERT/CC indicators. Search web, API and WAF logs for the IPs and User-Agents in JPCERT-AT-2026-0030. Inspect Java application servers for WAR files you don't recognize (Case D), and confirm you have patched Metabase for CVE-2026-72898.
4. Lock down APIs and file exposure. Enforce authorization on every endpoint, including internal ones, and add rate limits. Use short-lived tokens. Make sure configuration and backup files cannot be reached from the internet.
5. Map your concentration risk. List the SaaS, hosting and subcontractor services you depend on for critical public-facing functions. Decide in advance what fallback channel you would use if one of them went offline, and test it.
6. Require MFA and limit credential lifetimes. Following ITD's credential-led findings, put MFA on vendor consoles, email and code hosting, and remove tokens with no expiry or overly broad scope.

Sources: Data breaches continue: latest at Osaka IT firm | Disaster info service halted in parts of Japan over data breach fears | アルカディアの一斉同報サービス「SpeeCAN RAIDEN」に不正アクセス — 自治体の防災配信にも影響、メール約313万件など流出... | 直近で相次いでいる国内組織における不正アクセスに関する注意喚起 | JPCERT/CC on Japan's Breach Wave: Attackers Are Probing Each Site's... | Osaka University Hit by Ransomware; 500 Servers A... - CyberNetSec.io | Osaka Metropolitan University: ransomware on the virtualisation pla... | 2026 Data Breach Causes in Japan: Credential-Led Intrusions and Wha...