SpeeCAN RAIDENの調査報告が更新！ファイル参照から秘密情報とメール送信へ広がった影響

10月19日の報告で侵入後の経過が具体化

防災・防犯情報配信サービスSpeeCAN RAIDENなどを提供するアルカディアは、2026年10月19日10時更新の第12報で、不正アクセスの詳細な経過をまとめた資料を公開しました。初回の公表は10月13日で、今回の記事は19日に新たに示された侵入経路と対応の説明を扱います。

資料は、添付ファイルを公開するメディアサーバーのディレクトリパストラバーサルから内部ソースが取得され、設定内のサービス間ログイン用シークレットキーが取得されたと説明しています。その後、ログインされたセッションから内部情報が取得され、不正なプログラムによる外部メール送信も判明しました。

本記事の情報確認日は10月19日です。運営元の説明と、Web運営者が自社で点検するための本サイトの提案を分けます。特定のCVEや攻撃者、AIによる攻撃と断定する情報は確認していません。

出典：アルカディア｜不正アクセスの経過と当社の対処について（2026年10月19日・PDF）

不正送信の件数と漏えい対象の件数を混同しない

運営元は、不正なプログラムから外部へ配信されたメールの総数を1,423,428件と説明しています。内容の多くはクレジットカード会社の残高確認のようなもので、フィッシング詐欺が疑われるとしています。この数は、個人情報の漏えい件数や被害者数を確定する数字ではありません。

公式ブログは、サービスごとの影響や復旧経過を更新してきましたが、個人情報の漏えい可能性と具体的な範囲の調査は継続中です。復旧したことと、過去の情報取得の調査が終わったことは分けて受け取る必要があります。初期の推定値と後の確認結果も、足し合わせて全体の被害人数を作らないでください。

利用者や導入団体は、契約するサービスと対象のサーバーを公式案内で照合してください。同じブランド名のサービスでも、告知上の対象が同じとは限りません。本記事は個別の契約やデータの被害有無を判定するものではありません。

出典：SpeeCAN RAIDEN公式ブログ｜不正アクセスに伴う一連の対応（第12報）

ファイルを見せる機能が認証の境界へつながる

OWASPは、パストラバーサルを、想定する公開範囲の外にあるファイルやディレクトリーへアクセスしようとする攻撃として説明しています。一般に、ファイル名やパスを受け取る実装では、意図した保存領域の内側だけを参照する制約が必要です。単にURL上の表示がファイル配信に見えることは、安全性の根拠にはなりません。

本サイトの提案として、画像、添付ファイル、帳票のダウンロードなど、ファイル参照を行う入口を棚卸しします。認証画面や管理画面だけを点検していては、読み出し処理にある別の入口を見逃す可能性があります。公開が必要なデータと、アプリケーションの設定を分けて考えてください。

説明用の仮想例として、利用者が指定したファイル名をそのままサーバーのパスへ連結する実装を考えます。安全な対応の方向は、利用者にはファイルの識別子を渡させ、サーバー側で許可された対象へ対応付けることです。取得する相手にそのファイルへの権限があるかも別に確認します。

これは今回の実装を再現したものではありません。実際の修正は、採用する言語、フレームワーク、保存先の仕様に合わせて行い、文字列の一部を削るだけで十分と判断しないでください。

出典：OWASP｜Path Traversal

設定ファイルの機密性とサービス間の権限を同時に見る

今回のニュースでWeb運営者が着目したいのは、ファイルの読み出しだけで影響が終わらず、認証に使う情報の取得へつながったという点です。以下は内部構成を推測する説明ではなく、本サイトが提案する点検の考え方です。

公開側のプロセスが読む必要のない秘密情報まで参照できないか、サービス間の接続に広すぎる権限がないかを調べます。設定をWeb公開ディレクトリーの外へ置くことは重要ですが、アプリケーションの実行権限で外側も読める構成なら、それだけで全体の防御が完了するわけではありません。

接続するサービスごとに、認証情報の所有者、利用目的、参照できるデータ、実行できる操作、失効する方法を記録します。一つの資格情報を複数の用途で共有すると、漏れたときに切り分けて止めにくくなります。秘密情報を保存する場所の対策と、その情報で何ができるかという権限の対策を組み合わせます。

ログや設定一覧を調査担当へ渡す際も、秘密情報そのものを無制限に配布しないでください。必要な記録を保全しつつ、共有用の資料には値を伏せ、閲覧権限と受け渡し先を管理します。調査のための出力が新しい漏えい経路になることを避けます。

認証情報の変更は旧い値が使えない確認まで行う

OWASPの秘密情報管理資料は、作成、ローテーション、失効、有効期限というライフサイクルを扱い、漏えいの可能性がある秘密情報は失効させる必要があると説明しています。本サイトでは、新しい値を発行したことと、旧い値が使えなくなったことを別々の確認項目にする方法を勧めます。

例えば、接続先の認証情報を変えた後でも、旧セッションやキャッシュ済みの資格情報がどこまで有効かは仕組みによって異なります。これは今回すべての環境で起きたと確認されたことではありません。自社で変更する資格情報について、認証の寿命と失効の仕組みを調べるための観点です。

実施する場合は、誰が失効を判断し、誰が利用側へ反映するかを決めます。機密情報を含まない検証用アカウントなどを使い、承認された環境で旧い値の拒否と新しい値の成功を確認します。攻撃者が取得した可能性のある値をチャットや公開の作業票へ貼り付けて試す方法は避けてください。

資格情報の変更だけで原因となった読み出し経路が閉じるわけではありません。逆に、読み出し経路を修正しただけで、既に取得された値が無効になるとも限りません。入口の修正、秘密情報の扱い、利用先の権限を分けて完了判定します。

出典：OWASP Cheat Sheet Series｜Secrets Management

復旧試験は送信受付から実際の到達まで

ここからは本サイトが提案する業務検証です。メールや電話など、外部への通知を担う仕組みでは、Web画面が開くこと、処理が受け付けられること、宛先へ届くことは別の段階です。画面の成功表示だけで連携全体の復旧を判断しないでください。

検証では、許可された試験用の宛先と少量のデータを使い、受付、キュー、送信処理、配信結果の対応を追います。遅延した処理や再試行が残っている場合には、停止中に受け付けたものをどう扱うかも決めます。本番の利用者へ大量にテスト通知を送ることは勧めません。

不正送信の疑いがある場合は、通常の配信要求とそれ以外の実行経路を分けて調べます。管理画面からの操作だけを追っても、別のプログラムや定期処理からの送信が説明できないことがあります。誰が送信したか、どの処理がどの認証情報を使ったかを関連付ける記録が役立ちます。

送信量の制限や異常検知は、被害拡大を抑える補助策です。業務上の大量配信もあるため、単一の件数だけで攻撃を断定せず、時間帯、接続元、操作、承認された配信計画などと照合します。正規の配信を止めた場合に、責任者へ通知する手順も必要です。

侵入経路の修正と残存物の調査を分ける

本サイトが勧める調査の整理は、入口の修正、侵入後に変更されたもの、取得された可能性のある情報、業務への影響を別々に管理することです。入口を閉じたことだけでは、それ以前に作られた不正な処理まで消えたとは判断できません。

アプリケーションのファイル、拡張機能、定期処理、データベース、管理アカウントなど、採用する構成で変更可能な場所を確認します。証拠を残す前に闇雲に上書きするのではなく、時刻と対象を記録し、保守担当や専門の調査担当と手順を合わせます。

改ざんの調査では、何と比較するかも重要です。承認済みの配信成果物や構成管理の履歴があれば、変更の有無を追いやすくなります。一方、差分がないことだけで情報の読み出しまで否定できるわけではありません。完全性と機密性の調査は、それぞれ根拠を分けます。

今回の報告で確認できる運営元の説明と、自社に同じ兆候があるかという診断は別です。一般の記事だけで侵害の有無を結論付けず、不審な状況があれば利用するサービスの保守窓口や専門担当へ引き継いでください。

運営元の続報と自社の完了条件を対応付ける

今回の新しい事実は、運営元が侵入経路と不正メール送信の経過を具体的に公表したことです。初回公表日、今回の更新日、個々の事象の発生日を分けて読み、数字を別の意味へ置き換えないことが重要です。

Web運営者は、ファイル配信の参照範囲、秘密情報へ到達できる実行権限、サービスごとの認証、旧資格情報の失効、通知経路の試験を点検できます。これらは本サイトの対策提案であり、導入すればすべての攻撃を防げる保証ではありません。

情報漏えい範囲の確定や第三者による詳細調査については、今後の公式発表を確認してください。サービスが利用できることと、過去の影響の調査が完了したことを混同せず、確認済み・未確認を分けた対応を続けることが必要です。