株式会社アルカディアは2026年10月19日、同社のサービスへの不正アクセスについて、経過と対処を説明する資料「不正アクセスの経過と当社の対処について」(PDF)を公式ブログで公開しました。資料によると、設定ファイルにあったサービス間ログイン用のシークレットキーが取得され、そのキーを使ったログインで内部情報が取得されています。
WordPressや自社サービスのサーバーを運営していて「うちのサイトは大丈夫か」と気になった人は、設定ファイルに置いた秘密の鍵が抜かれると何が起きるのかを知っておくと、自分のサイトで今日どこを確かめればよいかがわかります。
10月11日〜16日に起きたこと(大まかな流れ)
- 10月11日:添付ファイルを公開しているメディアサーバーに、内部のURLにアクセスできてしまう欠陥(ディレクトリパストラバーサル)があり、内部のソースファイルが取得されました。その中の設定ファイルにあったサービス間ログイン用のシークレットキーが使われ、アカウントIDに対する総当たり攻撃が行われました。ログインされたセッションから内部情報が取得されています。同社は同日夜、社内のシステム監視でデータベースの異常な負荷に気づき、不正アクセスを検知しました。
- 10月12日:同社は不正アクセスの経路を遮断し、データベースのパスワードを変更しました。この変更の影響で、ある町の消防情報の外部連携が失敗していたことがわかり、変更以降は電話発信にも失敗していたことが判明しました(電話発信は同日中に修正)。同じ日に、個人情報保護委員会へ速報を報告しています。夕方には、WordPressにプラグインが追加されていたことも判明しました。
- 10月13日:大量にメールが配信されていたことからバックドアの設置がわかり、不正なメール配信を検知しました。不正な配信は同日朝に止めています。同社は侵入経路となっていたraiden3とs2を緊急停止し、所管の警察署とJPCERTコーディネーションセンターに相談したうえで、夕方にはアクセス元のIPアドレスを遮断しました。同じころ、NET119のデータベースでも不正アクセスの痕跡が見つかっています。
- 10月14日:旧119RAIDEN・NET119と社内会計サブシステムのデータベースでも痕跡が見つかりました。データベースのパスワード変更が原因で、自動応答が止まっていたことや、ある県の道路に関する空メール登録画面でエラーが出ていたこともわかりました(自動応答は同日夜に復旧)。夜にはraiden3のデータベースで書き換えられた箇所が複数見つかっています。
- 10月15日:raiden3のデータベースで改ざんされたデータを手作業で修正し、ソースコードに改ざんがないことを確認したうえで、raiden3とs2を復旧しました。これで全サービスが復旧しています。
- 10月16日:NET119と119RAIDENの漏えいの可能性のうち、NET119の件数が確定しました。9,020件のメールアドレスに紐づく個人情報です。
同社は不正なプログラムによって外部に配信されたメールの状況などの調査を続けており、10月19日の資料の時点で、その総数は1,423,428とわかったとしています。多くはクレジットカード会社からの残高確認のような内容で、フィッシング詐欺が疑われるとしています。
同社は、ディレクトリパストラバーサルの解消、不正なソースコードがないこと、データベースが健全であること、設定ファイルやcronなどの設定に問題がないことを確認しているとしています。そのうえで、より詳しい調査と対策をセキュリティ専門の第三者機関に依頼し、調査手続きを進めるとしています。
アルカディアが挙げた今後の対応
- すべてのサービスに対し、社内で立ち上げたLLMを活用した脆弱性診断とコードレビューを実施した。今後は外部の会社に委託して脆弱性診断を受ける
- 社内からデータベースへアクセスする方法を見直し、パスワードをサービスごとに個別に設定した。今後は2段階認証を必要とするなど対策を強化する
- 各サービス・各プロセスの自動監視を強化し、SOC(Security Operation Center)の導入も検討する
- X、Facebook、LINE、Yahoo防災アプリ、緊急速報メール(エリアメール)との連携は、順次、設定ファイルを見直す
設定ファイルの秘密の鍵が抜かれると何が起きるか
設定ファイルには、データベースのパスワードや、サービス同士がログインするための鍵(シークレットキー)など、システムを動かすための大事な値が書かれていることがよくあります。
鍵を手にした第三者が、内側の仕組みにログインできる
今回は、取得されたシークレットキーを使ってアカウントIDへの総当たり攻撃が行われ、ログインされたセッションから内部情報が取得されました。外から見えてしまったファイルが一つでも、その中に鍵があれば、内側の仕組みにまで入りこまれるおそれがあります。
入口を塞いだあとにも、別の不正が見つかることがある
同社は10月12日の未明に不正アクセスの経路を遮断しました。その日の夕方には、WordPressにプラグインが追加されていたことがわかっています。翌13日の未明には、大量のメール配信からバックドアが設置されていたことがわかりました。入口を塞いだあとも、中に見覚えのないものがないかを続けて確かめる必要があります。
鍵やパスワードを替えると、それを使っていた連携が止まる
10月12日にデータベースのパスワードを変えた影響で消防情報の外部連携が失敗し、変更以降は電話発信も失敗していました。14日には、同じパスワード変更が原因の自動応答の停止や空メール登録画面のエラーも見つかっています。どこでそのパスワードを使っているかを把握していないと、替えたあとに思わぬ機能が止まります。
一つのパスワードを広く使っていると、影響の範囲も広くなる
同社は今後の対応として、データベースのパスワードをサービスごとに個別に設定しました。一般に、一つのパスワードを多くの仕組みで共有していると、漏れたときに入りこまれる範囲も、替えたときに止まる範囲も広くなります。WordPressの公式ドキュメント「Hardening WordPress」も、同じサーバーで複数のブログを動かす場合は、それぞれ別のデータベースを別のユーザーで管理すると、一つが破られてもほかのブログを書き換えにくくなるとしています。
自分のサイトで今日確かめる6つのこと
コマンドはどれも、自分が管理しているサーバーやサイトの状態を読み取るだけで、設定は変えません。example.com やパスは、自分の環境のものに置き換えてください。自分が管理していないサイトには実行しないでください。
1. 公開フォルダに、置かなくてよいファイルがないか
今回の発端は、公開用のサーバーから内部のファイルが見えてしまったことでした。アップロード用フォルダの外が見えてしまうのはソフトの欠陥なので、WordPress本体・テーマ・プラグイン・サーバーのソフトを最新に保つのが基本です。そのうえで、万一見えてしまっても困らないように、公開フォルダ(ドキュメントルート)に設定ファイルやバックアップを置かないようにします。
# 公開フォルダの中にある、設定やバックアップらしいファイルを一覧にする
find /path/to/public_html -type f \( -name "*.ini" -o -name "*.env" -o -name "*.bak" -o -name "*.old" -o -name "*.sql" -o -name "*.zip" -o -name "*.tar.gz" \)
見つかったファイルが不要なら消し、必要なら公開フォルダの外へ移します。あわせて、ブラウザで自分のサイトのアップロード用フォルダ(例:https://example.com/wp-content/uploads/ )を開き、ファイルの一覧が表示されないかを見ます。一覧を表示するかどうかは、ApacheではOptions の Indexes、nginxではautoindex の設定で決まり、nginxの初期値は off(表示しない)です。
2. 設定ファイルが外から取れないか
公開フォルダに置いている設定ファイルがある場合は、外からアクセスしたときの応答を確かめます。
# 設定ファイルのURLにアクセスしたときの応答の見出し(ステータスコード)だけを見る
curl -I https://example.com/path/to/settings-file
# WordPress の wp-config.php の権限を確かめる
ls -l /path/to/wp-config.php
パスを正しく指定したうえで403や404が返れば、そのURLからは取れない状態です。200が返り、ブラウザで開くと中身がそのまま表示されるなら、公開フォルダの外へ移すか、Webサーバーの設定でアクセスを拒否します。WordPressの公式ドキュメントは、wp-config.phpを本人(とWebサーバー)だけが読める状態にすること、一般には400か440の権限にすることを挙げています。.htaccessでwp-config.phpへのアクセスを拒否する書き方も、同じドキュメントに載っています。
3. 見覚えのないプラグインがないか
アルカディアの件でも、WordPressにプラグインが追加されていたことが判明しています。管理画面のプラグイン一覧に加えて、WP-CLIが使えるならコマンドでも確かめられます。
# インストールされているプラグインを一覧にする
wp plugin list --fields=name,status,version,title
# 通常のプラグインとは別に読み込まれる must-use プラグインとドロップインも見る
wp plugin list --status=must-use
wp plugin list --status=dropin
# WordPress.org で配布されているプラグインが、配布時のファイルから書き換えられていないか照合する
wp plugin verify-checksums --all
# 管理者権限のユーザーに見覚えのない人がいないか確かめる
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
WordPress.orgで配布されていない有料プラグインなどは照合できないので、入れた覚えがあるかを一覧で確かめます。入れた覚えのないプラグインやユーザーが見つかったら、そのサイトは侵入されている前提で対応します。
4. メールの送信量が急に増えていないか
今回は不正なプログラムから大量のメールが送られ、10月19日の資料の時点で、その総数は1,423,428とされています。自分のサーバーからメールを送っている場合は、送信量がふだんより増えていないかを確かめます。Postfixを使っている場合の例です。
# 送信待ちのメールの一覧を見る(ふだんより多くたまっていないかを見る)
mailq
送信の記録はメールのログに残ります。ログの場所は環境によって違います(Postfix「DEBUG_README」)。外部のメール配信サービスを使っている場合は、そのサービスの管理画面で送信数の推移を見ます。心当たりのない急な増え方をしていたら、送信元になっているプログラムやアカウントを調べます。
5. パスワードを変えたら止まる連携がないか
今回は、データベースのパスワードを変えたあとに、外部連携、電話発信、自動応答、空メール登録画面で不具合が出ました。漏れた疑いがあるときに迷わず替えられるように、どこでそのパスワードや鍵を使っているかを先に書き出しておきます。
# データベースの接続情報を読み込んでいるファイルを探す(-l でファイル名だけを表示し、中身は出さない)
grep -rl "DB_PASSWORD" /var/www/
# 定期的に動いている処理を確かめる
crontab -l
sudo crontab -l
“DB_PASSWORD” はWordPressの設定名です。自社サービスなら、そのサービスが使っている設定名に置き換えます。メール配信、決済、SNS連携、バックアップ先など、外部サービスのAPIキーも一緒に一覧にしておくと、替えたあとにどこを動作確認すればよいかがすぐわかります。アルカディアも、X、Facebook、LINE、Yahoo防災アプリ、緊急速報メール(エリアメール)との連携について、設定ファイルを順次見直すとしています。
6. 鍵やパスワードをサービスごとに分けているか
複数のサイトやサービスが同じデータベースのユーザーとパスワードで接続していると、一つから漏れたときにほかにも影響が及びます。
# WordPress が使っているデータベースのユーザー名を見る(パスワードは表示しない)
wp config get DB_USER
# MySQL に登録されているユーザーの一覧を見る(データベースの管理者で実行)
mysql -u root -p -e "SELECT user, host FROM mysql.user;"
サイトごとにユーザー名が同じなら、サイトごとに別のユーザーとパスワードを用意することを検討します。外部サービスのAPIキーも、サイトやサービスごとに別のキーを発行できるなら分けておくと、漏れたときに止めるキーを一つに絞れます。
気になる点が見つかったら
パスワードや鍵を替える前に、5で書き出した連携先を確認し、替えたあとに一つずつ動作を確かめます。入口を塞いだあとも、見覚えのないプラグイン、ユーザー、メール送信が残っていないかを続けて確かめてください。レンタルサーバーを使っている場合は、サーバー会社にも相談します。
国内で相次ぐ不正アクセス全体の流れと、JPCERT/CCやIPAなどの注意喚起をもとにした確認ポイントは、不正アクセスが相次ぐ今、小さな会社・個人サイトが確認すべきことで確かめられます。
出典
- 株式会社アルカディア「不正アクセスの経過と当社の対処について」(2026年10月19日、PDF)(2026年10月20日確認)
- SpeeCAN RAIDEN公式ブログ「弊社サービスへの不正アクセスに伴う一連の対応について」(2026年10月20日確認)
- 株式会社アルカディア お知らせ「不正アクセスに伴う一連の対応について」(2026年10月20日確認)
- WordPress Developer Resources「Hardening WordPress」(2026年10月20日確認)
- WP-CLI公式ドキュメント「wp plugin list」「wp plugin verify-checksums」「wp user list」「wp config get」(2026年10月20日確認)
- Postfix manual「sendmail(1)」(mailq)(2026年10月20日確認)
- Postfix「DEBUG_README」(2026年10月20日確認)
- MySQL 8.4 Reference Manual「8.2.1 Account User Names and Passwords」(2026年10月20日確認)
- MySQL 8.0 リファレンスマニュアル「6.2.1 アカウントのユーザー名とパスワード」(日本語版)(2026年10月20日確認)
- curl man page(2026年10月20日確認)
- Apache HTTP Server 2.4「core」(Options ディレクティブ)(2026年10月20日確認)
- nginx「Module ngx_http_autoindex_module」(2026年10月20日確認)

コメント