WordPressに不正な管理者が17件追加されていた｜原因調査と再発防止策

運営している「さわファミ（sawafami.com）」のWordPressで、身に覚えのない管理者アカウントが17件見つかりました。

サイトの表示には目立った異常がなく、不正アカウントによる投稿も確認されていませんでした。それでも、第三者に管理者権限のアカウントを追加されている以上、不正アクセスを受けた状態として対応する必要があります。

今回、調査時点でWordPress本体が7.0のまま更新されていなかったことに加え、後から確認した管理画面には「自動更新は無効化されています」という表示がありました。

この記事では、確認できた被害、2026年10月22日に対応したPHPの脆弱性との違い、Xserver・ConoHa WINGの自動更新、そして再発を防ぐための確認方法をまとめます。

2026年10月29日時点の調査記録・公式情報をもとにしています。調査範囲には限りがあり、被害範囲や復旧完了を保証するものではありません。

今回わかったこと：不正な管理者17件と、WordPressの更新漏れ

最初に、今回の調査記録で確認された内容を整理します。以下はこのサイトの記録であり、すべてのWordPressサイトに同じ被害が起きるという意味ではありません。

不正ユーザーの登録日時を日本時間でまとめると、次のようになります。

ユーザー登録日時の記録では、約2か月にわたって追加が続いていました。ただし、データベースの登録日時だけで初回侵入の日時や攻撃者の操作を確定することはできません。

調査のきっかけは、ファイルの変更時刻だった

きっかけは、テーマ「THE THOR」が生成するserviceWorker.jsとmanifest.jsonの差分でした。調査記録では、差分はキャッシュ番号とURLの変更で、差分そのものに悪意のある内容は確認されていません。

一方で、serviceWorker.jsの更新時刻と、最後の不正ユーザーの登録日時が一致していました。それを手がかりにデータベースまで確認した結果、管理者アカウントの追加が見つかりました。

時刻の一致だけで、このファイルが侵入口だったとは判断していません。ファイルだけでなく、ユーザーや設定などデータベース側も調べる必要がある、という発見でした。

原因として疑われるのはWordPress本体の「wp2shell」

今回の調査では、WordPress本体の脆弱性「wp2shell」の悪用が疑われています。調査時の7.0が影響対象であり、不正な管理者追加が確認されたためです。ただし、保存されているログだけでは侵入経路を特定できていないため、特定の脆弱性が原因と確定した段階ではありません。

wp2shellは、WordPressのREST APIに関する問題（CVE-2026-63030）と、データベースへの不正な問い合わせにつながるSQLインジェクション（CVE-2026-60137）を組み合わせる攻撃です。認証なしで任意のコード実行につながる危険性があります。ニュージーランドNCSCの注意喚起でも、実際の悪用が報告されています。

WordPress公式の脆弱性情報では、wp2shellの影響を受ける本体のバージョンは6.9.0〜6.9.4、7.0.0〜7.0.1で、修正版は6.9.5と7.0.2です。7.0.2は2026年7月17日に公開されています。

これは当時の修正ラインです。今から対策する場合は7.0.2で止めるのではなく、現在の公式案内を確認し、その後の修正も含む最新版へ更新してください。

なお、一般的な不正アクセスでは、本体・テーマ・プラグインの脆弱性以外に、パスワードの漏えいやサーバー管理アカウントの侵害も調査対象です。不正なユーザー名やメールアドレスの特徴だけで、攻撃手法を決めつけることはできません。

10月22日に対応したPHPの脆弱性とは別件として整理しています

今回の不正管理者追加は、「2026年10月22日に対応したPHPの脆弱性が原因」という整理にはしていません。調査で疑われているのは、未更新だったWordPress本体の問題です。

10月に公表されたPHPの「PHP2Shell」と、7月に公表されたWordPressの「wp2shell」は、名前が似ていますが別の脆弱性です。

PHP側の問題は、PHP公式のCVE-2026-109618情報とCVE-2026-109619情報で確認できます。

今回の調査記録では、PHP側はパッチ適用済みと報告されており、不正ユーザーの登録日時も8月から記録されています。10月のPHP対応と、以前から続いていたWordPressの侵害を混同しないことが大切です。

ただし、公表時期とユーザー登録日時の比較だけで、PHPを含む別経路の悪用が一切なかったと証明できるわけではありません。PHPを修正しても、すでに作られた不正ユーザーや不正コードが消えるわけではないため、侵害後の調査・復旧は別に行います。

Xserver・ConoHa WINGにWordPressの自動更新はある？

ConoHa WINGでも、WordPress本体の自動更新は利用できます。「XserverにはあるけれどConoHaにはない」という理解ではありません。WordPress標準の機能、サービス固有の管理機能、緊急時の事業者による更新対応を分けて確認します。

Xserverは、wp2shellへの緊急対応として本体を更新していた

Xserverの公式告知では、攻撃経路への通信遮断に加え、対象のWordPress環境に対して7月31日頃〜8月25日にかけて本体の更新を順次実施したことが案内されています。

これは今回の脆弱性に対する緊急対応です。「Xserverなら、どの契約でも今後すべての更新を事業者が代行してくれる」という意味ではありません。

また、別サービスのXServer for WordPressには、自動アップデートの専用設定があります。ON・OFFと、「マイナーバージョンのみ」「すべて」の対象範囲を選べます。契約サービスを確認してから設定してください。

ConoHa WINGも、自動更新の利用を公式に案内している

ConoHa WINGのwp2shellに関する公式告知には、WordPress本体の自動更新を有効にしている場合と、無効にしている場合の案内があります。無効にしている場合は、利用者による手動更新が必要です。

その後の別のWordPress脆弱性への公式告知でも、自動更新が有効な利用者に対して、実際に修正版への更新が完了したかを管理画面で確認するよう案内しています。

サーバー契約やドメインの「自動更新」は支払い・契約継続の設定で、WordPress本体の更新とは別です。また、新規インストール用のWordPressが最新版になっても、既存サイトがすべて更新されたとは限りません。

LeveLivingで同じ兆候がなかった理由は、履歴の確認が必要

Xserverで運用するLeveLivingでは、修正版が適用されており、確認した範囲で同様の不正管理者追加は見つかりませんでした。

ただし、それがWordPress標準の自動更新、Xserverの緊急対応、手動更新のどれによるものかは、更新通知や操作履歴を確認しないと分かりません。サーバー会社の違いだけで、今回の結果を説明することはできません。

キャプチャーにあった「自動更新は無効化されています」の表示

2026年10月29日16時頃の画面では、WordPress本体は7.1.4と表示されていました。一方で、その下には「サイトはバージョン管理されているようです。自動更新は無効化されています。」という案内がありました。

WordPress公式の画面表示処理では、この案内はGitなどのバージョン管理を検知した場合に表示されます。公式の更新ガイドも、バージョン管理の検知や設定によって自動更新が無効になることを説明しています。

この表示は、撮影時点で自動更新が停止していることを調べる手がかりです。8月以前にも同じ状態だったか、何が検知の原因だったかまでは、この画面だけでは分かりません。

自動更新されていない場合は、次の項目を確認します。

• 「更新」画面に、自動更新が無効であるという表示が出ていないか。
• 「サイトヘルス」に、バックグラウンド更新やスケジュール実行の問題が出ていないか。
• Gitなどによる管理や、設定ファイル・プラグインで自動更新を止めていないか。
• ファイルの書き込み権限、更新サーバーへの接続、空き容量などに問題がないか。

技術担当者は、wp-config.phpのWP_AUTO_UPDATE_COREやAUTOMATIC_UPDATER_DISABLED、更新を制御するプラグインやフィルターも確認します。Gitで管理する運用なら、手動・自動デプロイを含めて、セキュリティ修正を反映する担当者と期限を決めておきます。

表示を消すためだけに管理用フォルダを削除するのではなく、更新を誰が実行する仕組みなのかを先に確認してください。「現在は最新版」と表示されていても、次の修正版が自動で入るとは限りません。

「投稿なし・ログイン記録なし」でも、被害なしとは言い切れない

今回の調査記録では、不正アカウントによる投稿・コメントは0件で、調査時点で残っているログインセッションも確認されませんでした。確認対象にした最近のPHPファイルやuploads内にも、明確なWebシェルは見つかっていません。

ただし、次の制約があります。

• 参照できたアクセスログは10月22日以降で、8月〜10月21日の操作は追えていない。
• 特定の日付以降に変更されたファイルだけを調べても、それ以前の改ざんは分からない。更新日時が保持・変更されている可能性もある。
• 残っているセッションがないことは、過去にログインしていない証拠にはならない。
• データベースの閲覧、投稿本文や設定への埋め込み、パスワードのハッシュなどの持ち出しは、別に調査する必要がある。

このため、現時点の表現は「確認した範囲では追加の改ざんを発見していない。情報流出や過去の操作は否定できない」となります。不正管理者が追加されたこと自体が、すでに不正な変更です。

また、導入した人を確認できていないプラグインも調査対象です。wordpress-importerやcode-block-proなど、名前だけで不正と判断せず、運用者の記憶、履歴、配布元の正規ファイルとの比較で確認します。ファイル日時だけでは実際の導入日や実行者は確定できません。

不正な管理者を見つけたときの対応順序

ここからは、同様の被害を見つけた場合の対応手順です。今回のサイトで、すべて実施済みという意味ではありません。WordPress公式の侵害時の案内でも、状況の記録と、復旧前の環境保存が重視されています。

1．公開・管理アクセスを必要に応じて制限し、記録を残す

不審な転送や不正なファイル配布がある場合は、まず閲覧者への被害拡大を止めます。サーバー会社に連絡し、必要に応じてサーバー側でアクセスを制限します。侵害されたWordPress内のメンテナンス表示だけに頼らないようにします。

削除・更新の前に、ユーザー一覧と権限、登録日時、現在のバージョン、アクセスログ・エラーログ・WAFログ、ファイルとデータベースのコピーを保存します。ログは保存期限を過ぎると消えるため、早めに確保してください。調査用のコピーは、復元に使う正常なバックアップと区別します。

2．不正ユーザーと、使われた可能性がある認証情報を無効化する

正規の管理者を確認してから、不正アカウントを削除または利用不能にします。投稿が関連付いている場合は内容を確認し、必要な投稿まで誤って消さないようにします。

WordPressだけでなく、サーバー管理パネル、SFTP・SSH、データベース、管理用メールなど、影響が考えられる認証情報を見直します。安全を確認した端末から、使い回しのないパスワードへ変更してください。

既存のログインセッション、アプリケーションパスワード、SSH鍵・APIトークンなども確認し、不正なものや漏えいが疑われるものを失効・再発行します。WordPressの認証用キー・ソルトの再生成も含めて再ログインを求め、復旧後に最終的な認証情報の変更・失効を確認します。設定ファイルに触れる作業は、必要に応じてサーバー会社や保守担当者と進めてください。

3．正規のファイルで復旧し、データベースも確認する

不正な管理者を削除してWordPressを更新するだけでは、すでに設置された不正コードや別の侵入口が残る可能性があります。

WordPress本体・テーマ・プラグインを公式の配布元から入れ直す、または侵害前と確認できる正常なバックアップを基に復旧します。最新のバックアップでも、侵害後に取得したものなら不正なデータを含む可能性があります。

本体のチェックサム比較に加え、wp-content、mu-plugins、uploads、wp-config.php、.htaccess、定期実行設定などを調べます。データベースでは、ユーザー権限、投稿・固定ページ、ウィジェット、サイトURLや管理者メールなどの設定、予約実行される処理も確認します。

本体のチェックサムが一致しても、独自ファイルやデータベースまで安全と証明されたことにはなりません。調べきれない場合は、公開再開前に専門の保守・復旧担当者へ相談してください。

4．更新と動作確認を行い、再発していないか監視する

復旧した環境で、本体・テーマ・プラグインに修正を適用し、不要なものを削除します。トップページだけでなく、投稿、画像、フォーム、ログイン、外部連携も確認します。

公開後は、管理者が再び増えていないか、同じファイルが書き換わっていないか、不審な通信が続いていないかを確認します。問い合わせ・会員などの情報を扱うサイトでは、保存データとアクセス可能範囲を整理し、影響を受ける利用者への案内が必要かも調査結果に基づいて判断します。

再発防止：自動更新と定期チェックを組み合わせる

再発防止では、更新だけでなく、ユーザー追加・権限変更などの不審な操作に早く気づける状態を作ります。次の頻度は、小規模サイト向けに本記事で提案する目安です。

ユーザー追加や権限変更の履歴は、WordPress標準だけでは十分に記録・通知されない場合があります。操作履歴を記録する仕組みを用意し、可能ならログをサイトとは別の場所にも保存します。今回のように約2か月前からの兆候があると、直近のログだけでは調査できないためです。

加えて、管理者権限を必要な人だけに絞り、日常の執筆には編集者など必要最小限の権限を使います。管理者・サーバー管理には二要素認証を利用し、使い回しのパスワードを避けます。更新・バックアップ・ログ監視の考え方は、WordPress公式のセキュリティ強化ガイドでも確認できます。

ConoHa WINGはwp2shellの公式告知で、SiteGuard WAFによる攻撃通信の遮断を案内しています。ただし、WordPressに入っている「SiteGuard WP Plugin」と、サーバー側のWAF設定は別です。プラグインが入っているだけでWAFが有効とは判断できません。サーバー側の設定と実際のログを確認し、WAFを使っていても本体の更新を続けてください。

自動更新は便利ですが、「ONにした」だけで完了にはしません。修正版が入ったか、不正な管理者が増えていないか、いざというときに復元できるかまで、運用の確認項目に入れることが今回の反省です。

よくある質問

不正な管理者を削除すれば解決しますか？

削除は必要ですが、それだけで復旧完了とは判断できません。侵入口の修正、認証情報とセッションの失効、ファイル・データベースの確認、再発監視まで行います。

二要素認証を入れれば、wp2shellも防げますか？

二要素認証はログイン情報の悪用への対策ですが、wp2shellは認証なしで成立し得る脆弱性です。本体の修正適用が必要です。

Xserverへ移行すれば、同じ被害を防げますか？

移行だけで安全になるとは言えません。移行元の不正なファイル・データを持ち込まないこと、更新設定、権限、監視体制まで含めて見直す必要があります。

管理画面が「最新版」なら、もう安全ですか？

最新版への更新は必要ですが、過去の侵害による不正ユーザーや不正コードが除去された証明にはなりません。現在のバージョン、今後の更新設定、侵害後の復旧確認をそれぞれ点検してください。