SpeeCAN RAIDEN Breach: A Disaster Alert SaaS Sent 1.42M Phishing Emails

On 11 October 2026 an attacker broke into SpeeCAN RAIDEN, a cloud disaster alert service run by Arcadia Inc. of Minoh, Osaka. A path traversal on a media server exposed a shared login secret. Arcadia estimates up to 3,136,000 email addresses may have leaked. A backdoor then sent 1,423,428 phishing emails. Customers should rotate integration secrets and enable two-step login.

SpeeCAN RAIDEN is the system many Japanese municipalities, fire departments and schools use to push evacuation notices, weather warnings and staff safety checks to registered phones and inboxes. Arcadia also runs NET119, the emergency call service for people with hearing or speech impairments, and the older 119RAIDEN fire service notification system. Traces of access were later found in both. Prefectural police forces that used the service for staff safety confirmation mail have since said their staff records may be among the exposed data.

This post works from Arcadia's own documents: the minute by minute timeline of 19 October, the formal report and deck of 23 October, and a notice page that carried 22 updates. Press reporting covers the police and municipal side and is attributed as such. The angle is vendor risk for public sector alerting.

What happened

Arcadia's formal report of 23 October summarises the cause in one sentence: a directory path traversal on the media server that publishes attachments let the attacker obtain a configuration file, the file held a secret key used for logins between services, and the attacker used that key to brute force account IDs, log in and read internal data. Everything else in this incident follows from that chain.

The attacker's activity did not stop when the entry point was closed. A WordPress plugin had been added and a backdoor had been planted. Roughly 21 hours after Arcadia blocked the original route, the backdoor began sending mail from Arcadia's own systems, starting with small batches and scaling up to 1,000 messages at a time. Arcadia says most of the 1,423,428 messages looked like balance confirmation notices from a credit card company, and it suspects phishing.

Timeline

All times are Japan Standard Time. Unless noted, entries come from Arcadia's 19 October timeline PDF and the table in its 23 October report.

The second wave: a closed door and an open back door

The most instructive part of the timeline is the gap between 03:00 on 12 October and 00:10 on 13 October. Arcadia had closed the traversal, stopped an internal login test, changed the database password at 09:30, found the added WordPress plugin at 17:05 and changed the owner and support passwords at 18:30. About 21 hours after the route was blocked, according to ITmedia's reading of the same timeline, the attacker came back through a backdoor and started testing outbound mail.

Arcadia's documents list the plugin and the mail backdoor as separate findings. They do not say whether the backdoor was installed through the plugin, where on the estate the backdoor sat, or when exactly it was planted. The lesson does not depend on those details: closing the entry point is the start of containment, not the end of it, and any foothold the attacker made in the hours before detection keeps working until someone finds it.

Two different "start" times in the notices

Arcadia's notices of 13 and 16 October say suspicious behaviour was confirmed at 16:30 on 11 October. The 19 October timeline and 23 October report instead put the first request at 06:26, the key file read at 16:39 and detection at 23:40. This post uses the later, more detailed documents. Arcadia has not explained the difference.

Who is affected

Arcadia's deck gives its customer base as of the end of September 2026: 875 government agency contracts, 715 municipal contracts, 312 fire department contracts, 22 police contracts, 242 corporate and other contracts, and 584 schools. The formal report says every service is in scope for a possible leak.

Services and data, from Arcadia's notices

Arcadia stresses that every count is an estimate and that the investigation continues. SpeeCAN RAIDEN does not process card or payment data, so none was exposed. On 14 October Arcadia also said two 119RAIDEN hosts, fs119.speecan.jp and 119r.speecan.jp, were out of scope after further checks.

Police forces, as reported by the press

Police forces are downstream customers here. They used the service to send safety confirmation mail to staff during disasters, so their staff lists sat in the vendor's database. The counts below are press figures, not Arcadia figures.

Nikkei reported on 21 October, citing the National Police Agency, that 22 prefectural police forces may have had officer and staff data exposed, and that in four of them the email addresses of residents registered for crime prevention alerts were also included. Each force quoted in the press said it had seen no misuse at the time of reporting. A national total for police records has circulated in some coverage; we could not confirm it from a source we were able to read, so it is not stated here.

Residents are affected in a less direct way. Anyone who registered an email address for municipal disaster mail, school notices or police crime prevention alerts on these services may be in the 3,136,000 figure. Arcadia's deck notes that it has not emailed residents directly, because using their addresses for that purpose would fall outside the purpose for which they were collected under Japan's personal information law. Notification is running through municipalities and other customers instead, and Arcadia is preparing proxy reports to the PPC on behalf of customers who consent.

Technical details

There is no CVE in this incident. The flawed code is Arcadia's own, and Arcadia has not published source IP addresses, hashes, the plugin's name, the backdoor's file name or the phishing domains. What it has published is unusually detailed for a Japanese breach notice, and ITmedia noted that minute by minute disclosure of this kind is rare. This section collects the defender useful specifics from those documents. It describes the techniques at the level a defender needs to look for them, not at the level an attacker needs to repeat them.

Entry: a path traversal on the attachment media server

The report's footnotes define the flaw in plain terms: a weakness that lets someone access files on a web server that should never be visible. In this case the vulnerable component was the media server that publishes message attachments, and the traversal reached internal URLs and internal source files. From those, the attacker obtained config.ini.

The defender point is about placement. A file that holds credentials for other services sat somewhere the public facing media tier could reach. Whatever the exact bug, a traversal is a read primitive: it turns "can request a file" into "can read any file the web process can read". The damage it does is set less by the bug than by what is readable when the bug exists.

Reconnaissance, stage by stage

Arcadia's log based account shows roughly ten hours of probing before the key file was taken. The stages are worth listing because each one is something a web application firewall, rate limiter or log alert could have surfaced.

Detection came from database load at 23:40, about 17 hours after the first request and about 7 hours after the key file was read. Nikkei's headline on the press conference made the same point: 17 hours undetected. Arcadia's documents do not mention any other alert firing during the probing.

One shared secret, every service

The report names the leaked item as a "secret key for login between services", which its glossary defines as secret information that lets systems confirm each other as legitimate peers. With that key, the attacker could act as a trusted internal service and brute force account IDs rather than passwords. That is why one file read became authenticated access across the estate, and why traces later turned up in the NET119 database, the old 119RAIDEN database and an internal accounting subsystem.

Arcadia's own remediation tells you what it sees as the root weakness. Its 23 October report lists, as already done, reviewing how staff access the databases and setting a separate database password for each service. Two-step authentication for that access is planned.

Persistence: a WordPress plugin and a mail backdoor

Arcadia's documents do not say which WordPress installation was affected or what it was used for; they record only that a plugin had been added. At 17:05 on 12 October Arcadia found a plugin it had not added. At 04:10 on 13 October, prompted by the volume of outgoing mail, it found a backdoor. The report's glossary defines a rogue plugin as a program an attacker builds into a system to add unauthorised functions, and a backdoor as a hidden entrance planted so the attacker can come back and operate later.

Arcadia then checked, and reports as confirmed, that the traversal is fixed, that no unauthorised source code remains, that the databases are sound and that configuration files and cron jobs have no problems. Those four checks were its basis for restoring service on 15 October. A third party forensic firm has been engaged and its findings are pending.

The mail run

The 869,575 figure matters. It means most of the run was not aimed at Arcadia's own registrants. The attacker appears to have used the platform's sending reputation to reach outside lists. Arcadia's timeline records that the attacker tested DKIM and DMARC before sending. It does not say whether the messages passed alignment checks at receiving providers, so this post does not claim they did. If they did, recipients would have seen messages that authenticated as coming from a legitimate sender domain, which is exactly what makes a hijacked notification platform valuable to a phisher.

Durations computed from Arcadia's timeline

Side effects of the response

Changing the shared database password at 09:30 on 12 October was the right move after a key leak, and it also broke things that depended on it. Arcadia's timeline lists a town's fire information integration failing, outbound phone calls failing until 13:58, a registration page erroring and automated voice responses stopping until 19:50 on 14 October. For a service that carries fire and evacuation alerts, rotation needs a map of every consumer before it starts.

Integration secrets customers must reissue

Arcadia's notice 15 (21 October) asks customers who link RAIDEN to LINE to reissue the Messaging API channel secret, and for segment delivery also the LINE Login channel secret, then save the new values in RAIDEN's extended settings. X and Facebook links must be redone from the same settings. Any other provider sharing those values needs the new ones. Arcadia also temporarily restricted fax, broadcast chimes and attachments (lifted 19:30 on 21 October) and stopped inbound API integration from external systems on 22 October.

Two-step login

From 22 October Arcadia asks all users of raiden.ktaiwork.jp, raiden2.ktaiwork.jp and raiden3.ktaiwork.jp, and from 23 October users of s.ktaiwork.jp and s2.ktaiwork.jp, to turn on login two-step authentication. The second factor is a code sent to a registered email address, valid for 15 minutes. The setup guide walks through registering the address from the account menu, confirming it with a code, then ticking the option to use it at login.

What was not published

• No CVE, because the flaw was in Arcadia's own code.
• No source IP addresses, although Arcadia blocked them at 17:00 on 13 October.
• No plugin name, backdoor file name, file hashes or phishing domains.
• No list of the brands imitated beyond "credit card company" style notices.
• No attribution. No group has claimed the attack.

The PHP2Shell timing

On 22 October Arcadia posted that its first response to the PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 was complete as of 01:30 that day, with permanent fixes to follow. Those flaws were disclosed on 21 October, ten days after this intrusion began. Arcadia does not link them, and nothing in its documents suggests the 11 October attack used them. The overlap is timing only. Our PHP2Shell explainer covers that separate issue.

Why a disaster alert platform is such a useful target

A mass notification service holds exactly the data a phisher wants: names, work and private email addresses and mobile numbers for public servants, police officers, firefighters, teachers and residents, with context such as which force or council a person belongs to. It is also built to send a lot of mail quickly and have it land, with sending history and SPF, DKIM and DMARC records already in place. And its recipients have learned to open its messages at once. An attacker who controls the sending path inherits all three.

For customers, a vendor breach becomes their breach. The police forces and councils in this story used a common SaaS for staff safety checks and resident alerts. Our post on third party risk after the IDCF Cloud ransomware incident covers the contract and inventory side of that problem.

What to do now

If you received mail from a municipal disaster or school notice service

1. Treat any message about card balances, account checks or payments with suspicion, even if it appears to come from a familiar alert sender. Arcadia's notice 3 asked administrators to warn registrants never to enter names, addresses, passwords or account details in response to unexpected messages.
2. Do not open links or attachments in messages you did not expect. Go to your card issuer's site or app directly.
3. If you entered card details into a page reached from such a message, call your card issuer to block the card.
4. Expect your council, school or employer to contact you through its own channels about whether your address was in scope.

If your organisation is an Arcadia customer

1. Change every RAIDEN login password, as Arcadia asked on 15 October, and turn on two-step login for every account on the hosts listed above.
2. Reissue LINE channel secrets and relink X and Facebook as described in notice 15. Update any third party that shares those integration details.
3. Check whether your external systems use RAIDEN's inbound API. Arcadia stopped external API integration on 22 October, which means alerts may need to be sent by hand from RAIDEN until it is restored. Confirm with the vendor of any connected system how it reports errors.
4. Test your full alert path end to end: email, phone, fax, broadcast integration and any carrier area mail link. The password change on 12 October broke some of these without an obvious error.
5. Decide whether to consent to Arcadia's proxy report to the PPC, and record your own notification decisions and their basis.
6. Tell your registrants plainly what happened and what to watch for. Do not wait for the final count.
7. Add the incident to your vendor register with the data held, the sending domains used and the integrations connected.

If you run a multi tenant notification or messaging platform

The checks below are generic. Adapt paths and service names to your stack.

1. Find credentials that live inside a web root. Any secret readable by the web process is one file read away from an attacker.

# Config-style files under web roots
sudo find /var/www /srv/www -type f \( -name '*.ini' -o -name '.env' -o -name '*.conf' -o -name 'config.*' \) -print

# Of those, which mention keys, secrets or passwords (review by hand)
sudo grep -rIl -i -E 'secret|api[_-]?key|passw' /var/www /srv/www --include='*.ini' --include='.env' --include='*.conf'

Move anything you find into a secret store or an environment the web tier cannot read, and rotate it.

2. Make sure static and media servers cannot serve files outside their directory. For nginx, review every alias and root that serves uploads, and deny configuration and backup extensions outright.

location /media/ {
    alias /srv/media/;            # trailing slash on both sides
    disable_symlinks on;
    autoindex off;
}

location ~* \.(ini|env|conf|bak|sql|log)$ {
    deny all;
}

Run sudo nginx -t after the change, then reload.

3. Look back through access logs for traversal and probing.

# Requests containing parent directory sequences, plain or encoded
sudo zgrep -h -i -E '\.\./|%2e%2e' /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Successful responses for configuration-style files
sudo zgrep -h -E '\.(ini|env|conf|bak)[ ?]' /var/log/nginx/access.log* | awk '$9 == 200'

# 404 storms per client, a sign of path brute forcing
sudo zgrep -h ' 404 ' /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head

4. Alert on login API abuse. Count failures per source and per account ID, not just per source, because an attacker holding a service key may cycle IDs from few addresses.

# Failed logins per client against a login endpoint (adjust the path and status)
sudo zgrep -h 'POST /api' /var/log/nginx/access.log* | awk '$9 == 401 || $9 == 403 {print $1}' | sort | uniq -c | sort -rn | head

5. Give each service its own credentials. One database user per service, with only the grants it needs, means one leaked secret opens one door. In MySQL or MariaDB, start by listing what exists:

SELECT user, host FROM mysql.user;
SHOW GRANTS FOR 'app_raiden'@'10.0.%';

Before rotating, list every consumer of the credential: integrations, cron jobs, voice and fax gateways, registration pages. Arcadia's experience shows what is missed.

6. Lock down WordPress if it runs anywhere near production.

# Inventory plugins and compare with your approved list
wp plugin list --fields=name,status,version,update --path=/var/www/site

# Plugin folders changed in the last 14 days
find /var/www/site/wp-content/plugins -maxdepth 1 -mindepth 1 -type d -mtime -14 -print

In wp-config.php, define( 'DISALLOW_FILE_MODS', true ); blocks plugin and theme installs and updates from the admin screens, and on its own also disables the file editor, according to WordPress's own documentation. Deploy plugins through your release process instead.

7. Put volume alarms on outbound mail. A normal day for an alert platform has a shape. Six hours of steadily growing batches at 1 a.m. does not.

# Messages sent per hour from Postfix logs
sudo zgrep -h 'status=sent' /var/log/mail.log* | awk '{print $1, $2, substr($3,1,2)":00"}' | sort | uniq -c | tail -48

# Current queue size
postqueue -p | tail -1

Postfix supports per client limits such as smtpd_client_message_rate_limit together with anvil_rate_time_unit. Pair limits with an alert, so a breach does not simply slow down.

8. Watch your own DMARC reports. Add a rua address to your DMARC record if you have none, and review every source that sends as your domain.

9. Hunt for persistence after you close the door. List files and scheduled jobs changed since the earliest known attacker activity.

sudo find /var/www /etc/cron* -newermt '2026-10-11 06:00' -type f -print
crontab -l; sudo ls -la /etc/cron.d
systemctl list-timers --all

What changed since the first reports

The 13 October notices began with an emergency stop of two servers and, that evening, a possible leak of up to 3,136,000 email addresses. On 14 October NET119 and 119RAIDEN joined the scope, with a first NET119 estimate of about 13,000 later fixed at 9,020. The detailed timeline followed on 19 October as police forces began confirming exposure. On 21 October Arcadia said at least 869,575 of the fraudulent messages went to addresses it did not hold, and Nikkei reported 22 police forces in scope. On 22 and 23 October came two-step login, the formal report, the deck and a press conference. The cause statement has not changed since 19 October; the counts have never been final.

Open questions

• How many unique people are affected. The 3,136,000 figure is a maximum estimate of email addresses, not people, and it will contain duplicates.
• Whether data was copied in bulk or only viewed. Arcadia says leakage is possible and has commissioned a dark web check.
• How the WordPress plugin and the mail backdoor relate, and when each was placed.
• Whether the phishing messages passed DKIM and DMARC alignment at receiving providers.
• Which brands the phishing imitated beyond "credit card company" style notices, and where the 869,575 outside addresses came from.
• What the third party forensic review finds, and whether it changes the timeline.
• Compensation. Nikkei reports the policy is undecided and under discussion with lawyers.
• Who did it. No group has claimed the attack. Some coverage has speculated about automated tooling; Arcadia has not said so, and this post does not.

What would have helped

Nothing below is a claim about what Arcadia should have done. These are practices any team running a public facing, multi tenant service can apply, drawn from the chain Arcadia published.

Practices any team can use

1. Keep secrets out of anything the web tier can read. Keys for other services belong in a secret store or a runtime environment, never under a document root or a path a media server can reach.
2. Do not share one login secret across services. Per service credentials and scoped grants turn one leak into one problem. Arcadia has now moved to per service database passwords.
3. Treat file serving code as security code. Canonicalise paths, allow list directories, and test that requests cannot leave them.
4. Remove what production does not need. Old backup paths, legacy mobile trees and test endpoints were all part of the reconnaissance here.
5. Alert on behaviour, not only on load. Login failures per source and per account ID, 404 storms and successful reads of configuration files are cheap signals. Database load was the alarm that worked here, seven hours after the key was read.
6. Rate limit and alert on outbound mail, per sender and per tenant, with a human paged when a ceiling is hit.
7. Control CMS changes. Disable plugin installs from admin screens and deploy plugins through code review.
8. Map every consumer of a credential before you need to rotate it, so a rotation does not stop fire alerts or phone calls.
9. After closing the entry, assume persistence. Compare deployed files with source, review scheduled jobs and keep watching outbound traffic for days.
10. For customers: know what your vendors hold. Record staff and resident data, sending domains and integration secrets per vendor.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. The flaw in this incident was in a company's own application code, not in a published package, and nothing here suggests Zero-Day Discovery found it or that an SGZ advisory existed for it.

Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is the paid catalogue of hardened, drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages. There is no CVE here for Gold to track, and we are not claiming Gold had anything for this incident. Their relevance is to the open source parts of a stack like this one, such as the web server, PHP runtime images and CMS dependencies, where knowing the safe version and rebuilding from patched, signed components is the habit that keeps known flaws from piling up next to custom ones.

Where Safeguard fits

Safeguard helps with the parts of a platform a team builds and ships itself:

• Know what is in each service. safeguard scan --dir . scans a repository, safeguard scan --image <name> a container image and safeguard scan --sbom <file> an SBOM, writing JSON under ./output. The platform shows which projects contain a given component and version, so "which of our services still ship this CMS plugin version or this PHP base image" has an answer. Our post on using SBOMs to find affected products fast shows the pattern.
• Prioritise known vulnerabilities. Findings are matched against vulnerability databases, and reachability analysis ranks the code paths your application actually calls.
• Stop regressions. Policies and gates evaluated in the platform can block a build that brings back a version you have already removed.
• Fix with approval. Autonomous remediation can open fix pull requests and ships switched off. The Safeguard CLI's assistant can edit code, such as moving a secret out of a config file into an environment variable or adding a path check to a file handler, and run your tests, asking before each command unless you pick another /permissions mode (Ask, Accept edits, Plan, Auto, the default, or Strict). safeguard exec runs the same in CI.

Where Safeguard does not help: it does not monitor web traffic, database load or outbound mail, it does not detect intrusions or backdoors, it does not scan for secrets, and it does not detect malicious plugins or packages. It does not run a SaaS vendor's servers, so a council or police force cannot use it to fix a platform it rents. It would not have stopped this attack, and nothing in this post claims it would. For a customer of a SaaS vendor, its value is indirect: knowing your own estate well enough to ask your vendors sharp questions.

Common mistakes and troubleshooting

• Treating the fix of the entry point as the end. In this incident the worst damage, 1.42 million phishing emails, started about 21 hours after the route was closed.
• Rotating a shared credential without a consumer map. Arcadia's own timeline shows fire integrations, outbound calls, a registration page and voice responses failing after one password change.
• Counting rows, not people. Email address counts include duplicates and shared addresses. Plan notifications on the estimate, but do not publish it as a number of people.
• Relabelling the incident. This is a vendor breach. The police forces and municipalities are its customers, not its cause.
• Forgetting integration secrets. Changing a password does not revoke a LINE channel secret or an X or Facebook link stored in the vendor. Reissue them.
• Waiting for a CVE. Custom application flaws never get one. If your process only reacts to CVE feeds, this class of problem is invisible to it.

FAQ

What is SpeeCAN RAIDEN?

A cloud service from Arcadia Inc. of Minoh, Osaka, that government bodies, municipalities, fire departments, police and schools in Japan use to send disaster information, evacuation notices and staff safety checks by email, phone, fax and social channels. Arcadia's deck lists 715 municipal contracts and 584 schools as of the end of September 2026.

How did the attacker get in?

According to Arcadia's 23 October report, through a directory path traversal on the media server that publishes attachments. It exposed a configuration file holding a secret key used for logins between services. The attacker used the key to brute force account IDs and read internal data.

How many people are affected?

Arcadia's maximum estimate is about 3,136,000 email addresses, 105,000 phone numbers and 15,000 fax numbers for SpeeCAN RAIDEN, plus 9,020 NET119 records and about 97,000 email addresses for the old 119RAIDEN. These are estimates of records, not unique people, and the investigation continues.

Were police officers' details exposed?

Several prefectural police forces have said staff records registered for safety confirmation mail may be affected, including Kanagawa (about 16,000), Aichi (about 15,000), Saitama (about 13,000) and Fukuoka (about 11,000), as reported by the press. Nikkei reported 22 forces in total, citing the National Police Agency.

What were the 1.42 million emails?

Arcadia says a backdoor sent 1,423,428 fraudulent messages between 01:17 and 07:16 on 13 October, mostly credit card company style balance confirmation notices. At least 869,575 went to addresses Arcadia does not hold.

Is this related to PHP2Shell?

Not as far as anyone has said. The intrusion began on 11 October; the PHP flaws were disclosed on 21 October. Arcadia patched its PHP services separately on 22 October. The overlap is timing only.

What should Arcadia customers do first?

Change passwords, turn on two-step login, reissue LINE channel secrets and relink X and Facebook, then test every alert channel end to end and warn registrants about phishing.

Would Safeguard have prevented this?

No. The flaw was in custom code on a vendor's servers, and the decisive signals were in web logs, database load and outbound mail, which Safeguard does not monitor. Safeguard helps teams know and fix the components in their own code and images, which is one part of the defences listed above.

Fix it without waiting for upstream

This incident had no CVE and no upstream maintainer; the flaw was in a company's own code. Most platforms like it still run on open source web servers, language runtimes and CMS components, and that is where the steps below apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Arcadia, SpeeCAN RAIDEN or their systems. Each is a real Safeguard session, and each intro says how the same flow would apply to a team that builds and runs its own notification or messaging platform.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a platform like the one in this story you would run /scan . in the repository behind your media or attachment service, then ask the assistant to move a key out of a config file into an environment variable and add a test that file requests cannot leave the media directory, approving each edit and test run.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list; you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. During an incident like this one, an engineer could point it at the WordPress deployment folder, ask it to run wp plugin list and compare the result with the approved list in the repository, and deny any command that would change production until the review is done.

Click through it at your own pace, or open it full screen.

This session connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. A security lead preparing a vendor risk review after this incident could then ask Claude which of the team's own projects contain a given CMS or runtime version, and get answers from Safeguard's data rather than a spreadsheet.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For the rest of the month, read October 2026 security incidents and what would have helped, and for the response side, our incident response playbook for a compromised dependency.

Quick check

Sources

• Arcadia: SpeeCAN RAIDEN official notice page, notices 1 to 22 (13 to 23 Oct 2026)
• Arcadia: course of the unauthorised access and our response, timeline PDF (19 Oct 2026)
• Arcadia: formal report on possible personal data leak (23 Oct 2026)
• Arcadia: explanatory deck on possible personal data leak (23 Oct 2026)
• Arcadia: login two-step authentication setup guide (23 Oct 2026)
• Arcadia: response to the PHP vulnerabilities (22 Oct 2026)
• Arcadia: company home page
• ITmedia NEWS: the 105 hour response, reported minute by minute (20 Oct 2026)
• ITmedia NEWS: Tochigi police staff data and other forces (20 Oct 2026)
• Nikkei: press conference, 17 hours undetected (23 Oct 2026)
• Nikkei: president apologises, compensation undecided (23 Oct 2026)
• Nikkei: 22 prefectural police forces may be affected (21 Oct 2026)
• Nikkei: disaster information service restored (15 Oct 2026)
• Jiji Press: Saitama police, about 13,000 records (19 Oct 2026)
• Mainichi via Yahoo News Japan: Kanagawa police, about 16,000 records (20 Oct 2026)
• WordPress Developer Resources: editing wp-config.php, DISALLOW_FILE_MODS
• OWASP: Path Traversal

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.