WordPressサイト全体にアクセスできなくなった時の原因と復旧手順
サイトにも管理画面にもまったくアクセスできなくなった場合、最初に確認すべきはサーバーのファイル構造とWordPressのインストールパスだ。外部からの不正アクセスを受けた後にページが表示されなくなる症状では、改ざんされたプラグインの残骸や、不完全に変更された設定ファイルが読み込みを妨げている可能性が高い。
なぜサイト全体にアクセスできなくなったのか
管理画面も含めてあらゆるページが表示されない状態は、WordPressの根幹となるファイルが破損しているか、サーバーがPHPを正しく処理できなくなっていることを意味する。特に不正アクセスを受けた後であれば、攻撃者が設置した不正なコードがセキュリティプラグインや手動の復旧作業によって一部だけ削除され、不完全な状態で残っている可能性が高い。
最も厄介なのは、WordPress本体のコアファイルや設定ファイルそのものが破損しているケースだ。テーマやプラグインの不具合であれば、それらを無効化することで少なくとも管理画面にはアクセスできるようになるが、コア破損ではそれすらも不可能になる。
不正アクセスからの復旧作業で起こりやすい副次的な破損
外部から侵入を受けた後、多くのユーザーはパスワード変更やソルトキーの更新、不審なプラグインの削除といった応急処置を行う。しかしこれらの作業中に誤って重要なファイルを削除してしまったり、修正が中途半端な状態で終わってしまったりすることがある。特にソルトキーを手動で更新した場合、wp-config.php内で閉じ引用符が欠落していたり、PHPの定数定義が壊れていたりすると、WordPress全体が読み込めなくなる。
最初に試すべき緊急アクセス手順
サイトが完全に応答しなくなった場合、まずはブラウザの問題ではなくサーバー側の問題であることを確認する。シークレットウィンドウで自分のサイトURLを開く、別の端末やネットワークからアクセスしてみる、example.com/readme.htmlのような静的なHTMLファイルが表示されるか試すといった切り分けが有効だ。静的なHTMLすら表示されないなら、DNS設定やサーバー自体の停止を疑う必要がある。
wp-config.phpを開き、文法ミスがないか確認する上記の手順で管理画面に到達できるようになれば、あとは管理画面からプラグインを1つずつ有効化して原因を特定し、テーマを正式に切り替えればよい。
wp-config.php の破損を確認する
ソルトキーを変更した直後にアクセス不能になったなら、wp-config.phpが最も疑わしい。このファイルはWordPressのルートディレクトリにあり、データベース接続情報や認証用のユニークキーを定義している。編集時にシングルクォートが1つ抜けている、余分な文字が混入している、PHPの開始タグ<?phpが欠落しているといった単純なミスで、サイト全体が真っ白になる。
サーバーのファイルマネージャーやFTPクライアントでwp-config.phpをダウンロードし、バックアップを取った上で内容を確認する。特にソルトキーを定義しているセクション（AUTH_KEYやLOGGED_IN_KEYなどが並ぶ部分）に注目し、各行がdefine('キー名', '値');の形式を正しく守っているか、閉じ括弧とセミコロンが揃っているかを1行ずつ検証する。不安があれば、WordPressの公式ソルトキー生成ページから新しいキーセットをコピーし、該当セクションを丸ごと置き換えるのが安全だ。
プラグインを強制的に全無効化する
管理画面にさえアクセスできない状態では、データベースを直接操作するか、FTPでプラグインフォルダの名前を変更することでプラグインを無効化する。手順はシンプルで、/wp-content/plugins/ディレクトリに移動し、その中にある全プラグインのフォルダ名の先頭に「_」や「disabled_」を付け加えるだけだ。例えばwordfenceを_wordfenceにリネームすれば、WordPressはそのプラグインを認識しなくなる。
この方法の利点は、プラグイン本体のファイルを削除せずに済むため、原因特定後にすぐ元の名前に戻して復元できることだ。大量のプラグインを1つずつリネームするのが面倒な場合は、pluginsフォルダ自体をplugins_backupにリネームし、空のpluginsフォルダを新規作成すると一括で無効化できる。
WordPress コアファイルを手動で上書きする
wp-config.phpに問題がなく、プラグインをすべて無効化しても症状が改善しない場合、WordPress本体のプログラムファイルが改ざんまたは破損している。攻撃者がwp-adminやwp-includesディレクトリに仕込んだバックドアが、不完全に削除されたまま残っているケースも多い。
対処法は、WordPress公式サイトから最新版の ZIP ファイルをダウンロードし、展開した中身をFTP経由でサーバーにアップロードすることだ。このとき絶対に上書きしてはいけないファイルが2つある。wp-config.php（サイト固有の設定）と/wp-content/ディレクトリ（テーマ・プラグイン・アップロードメディア）だ。これらを除くすべてのファイルとフォルダを上書きアップロードすることで、コアファイルだけがクリーンな状態にリセットされる。
サーバー側のエラーログを確認する方法
ここまでの手順で復旧しない場合は、具体的なエラー内容を把握する必要がある。ブラウザには「重大なエラーが発生しました」としか表示されないが、サーバーには詳細なエラーログが記録されている。レンタルサーバーの管理パネル（cPanelやカスタムコントロールパネル）で「エラーログ」や「error_log」という項目を探し、直近のエントリを確認する。
error_logファイル/wp-content/debug.log（WP_DEBUG有効時）エラーログには「PHP Fatal error」や「Allowed memory size exhausted」といった具体的な原因が記録されている。特に不正アクセス後によく見られるのが、改ざんされたファイルから呼び出された存在しない関数によるエラーや、不完全に削除されたコードの残骸による構文エラーだ。ログの内容を手がかりに、問題のファイルを特定して修正するか、該当プラグインを完全に削除する。
WP_DEBUG を一時的に有効化して詳細を表示する
サーバーのエラーログが見つからない場合は、WordPressのデバッグモードを有効にしてエラーを画面に直接表示させる。これはwp-config.phpに以下の定数を追加または変更することで実現できる。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);WP_DEBUGをtrueにするとWordPressがエラーを表示するようになり、WP_DEBUG_LOGで/wp-content/debug.logにエラーが記録される。WP_DEBUG_DISPLAYをtrueにすると、ブラウザ上にもエラーメッセージが直接表示される。なお、作業が終わったらこれらの定数をfalseに戻すか削除すること。本番サイトでデバッグ表示を有効にしたままにすると、訪問者にもエラー内容が見えてしまいセキュリティリスクになる。
.htaccess ファイルの破損を疑う
不正アクセスの痕跡として、.htaccessファイルが改ざんされているケースも多い。このファイルはWebサーバー（Apache）の挙動を制御しており、ここに不正なリダイレクトルールやアクセス制限が書き込まれていると、サイト全体にアクセスできなくなる。
WordPressルートディレクトリの.htaccessをダウンロードしてバックアップを取り、一度ファイル名を.htaccess_backupに変更して無効化する。その後、WordPress管理画面の「設定」→「パーマリンク設定」で「変更を保存」をクリックすれば、クリーンな.htaccessが自動生成される。ただし管理画面にアクセスできない現状では、以下の内容で新規に.htaccessを作成してもよい。
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressこれでサイトが表示されるようになれば、原因は.htaccessの改ざんだったと特定できる。旧ファイルは内容を精査し、不審な行（知らないドメインへのリダイレクトや、怪しいIPアドレスからのアクセス許可ルールなど）がないか確認してから削除する。
バックアップからの復元がうまくいかない場合の対処
サーバー会社のサポートからバックアップ復元を提案されたが失敗したという状況は、バックアップデータ自体が破損しているか、復元先の環境に不整合があることを示している。特に多いのが、バックアップを上書き復元した後にデータベースの接続情報が古いままになっているケースだ。
バックアップ復元後にサイトが表示されない場合、まずwp-config.php内のデータベース名・ユーザー名・パスワード・ホスト名が、現在のサーバー環境と一致しているか確認する。バックアップが別のサーバーや別のデータベースインスタンスの情報を持ったまま復元されると、WordPressはデータベースに接続できず「データベース接続確立エラー」を返す。
もうひとつの可能性は、バックアップに不正アクセス後の改ざんファイルが含まれていたケースだ。攻撃を受けた後の状態をバックアップしてしまい、それを復元しても問題が再発するだけという悪循環に陥っている。この場合、バックアップからwp-content/uploads/（メディアファイル）とデータベースのダンプファイルだけを取り出し、WordPressのコアファイルとプラグインは公式のクリーンなファイルで置き換える方法が有効だ。
よくある質問
FTPの接続情報がわからない場合はどうすればよいか
多くのレンタルサーバーでは、契約時に送られてくる「サーバーアカウント情報」メールにFTPのホスト名・ユーザー名・パスワードが記載されている。見つからない場合はサーバーの管理パネルにログインし、「FTPアカウント」や「ファイルマネージャー」の項目から確認できる。管理パネル自体にログインできない場合は、サーバー会社のサポートに連絡してFTP情報を再発行してもらう必要がある。
「このサイトで重大なエラーが発生しました」のメールが届いたが確認できない
WordPress 5.2以降では、サイトに致命的なエラーが発生すると管理者メールアドレスに自動通知が届く。このメールには「リカバリーモード」へのリンクが含まれており、クリックするとプラグインを無効化した状態で管理画面にログインできる。メールが届いていない場合は、サーバーのPHPバージョンが古くてメール送信機能が動作していない、または管理者メールアドレスが間違って設定されている可能性がある。
不正アクセスを受けた後、どのプラグインを疑うべきか
攻撃者は多くの場合、更新が長期間止まっている脆弱なプラグインや、公式リポジトリ以外から入手したnulledプラグイン（正規ライセンスを回避した改変版）を経由して侵入する。/wp-content/plugins/内で更新日時が不自然に新しいファイル、プラグイン名とは無関係なファイル名（config.bakやabout.phpなど）が紛れ込んでいないか確認する。また、長期間更新されていないプラグインは、たとえ攻撃の経路でなかったとしても今後のリスクになるため、代替プラグインへの移行を検討すべきだ。
すべて試しても復旧しない場合の最終手段は
サーバー上の全ファイルをローカルにバックアップし、データベースをエクスポートした上で、WordPressを新規インストールする。その後、エクスポートしたデータベースのうちwp_posts（投稿・固定ページ）とwp_postmeta（カスタムフィールド）、wp_options（サイト設定）のテーブルだけをインポートし直す。この方法ではテーマやプラグインの設定の一部が失われる可能性があるが、コンテンツを救出できる可能性が最も高い。作業前には必ず現状の完全バックアップを取っておくことが大前提だ。
この記事のポイント
- 管理画面もサイトも表示されない場合、まずは静的なHTMLファイルが表示されるか確認し、問題の切り分けを行う
wt-config.phpの文法ミスやプラグインの強制無効化、.htaccessのリセットで多くのケースが解決する- 不正アクセス後はコアファイルが改ざんされている可能性があるため、
wp-content以外をクリーンなファイルで上書きする - バックアップ復元に失敗したら、データベース接続情報の不一致やバックアップ自体の破損を疑う
- エラーログやWP_DEBUGで具体的なエラー内容を特定し、根本原因に対処するのが最も確実な復旧手順である
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
GitHubへの不正アクセス調査詳報、攻撃者は内部リポジトリに侵入するも影響は限定的
2026年5月20日、GitHubは自社が所有する一部の内部リポジトリに対して、第三者による不正アクセスがあったことを公表した。GitHubの最高情報セキュリティ責任者（CISO）であるAlexis Wales氏がGitHub Blogで発表した調査報告によれば、ユーザーデータや個人リポジトリ、GitHub.comを含むサービスには一切の影響がなかったという。
攻撃者は漏洩したトークン（認証情報）を用いて、GitHub社が管理していた内部リポジトリの一部を閲覧・クローンした。ただし、ソースコードの改ざんやマルウェアの注入、ユーザー情報へのアクセスは確認されていない。GitHubのインシデント対応チームは、発覚から数分以内に問題のトークンを無効化し、侵入経路を遮断した。
本稿ではこのインシデントの技術的な背景、影響範囲、そしてGitHubを利用する開発者が今すぐ実践すべきセキュリティ対策について詳しく解説する。大規模プラットフォームでさえトークン管理のミスが致命的になりうるという現実は、すべてのソフトウェア開発者にとって重要な教訓だ。
何が起きたのか、侵入の経路と期間
GitHubによれば、最初に異常が検知されたのは2026年5月中旬のことだ。同社のセキュリティ監視システムが、特定のGitHub Actionsトークンを用いた不審なリポジトリアクセスを検出した。このトークンはある外部サービスとのインテグレーションに使用されていたが、意図しない形で第三者の手に渡っていた。
トークンとは、パスワードの代わりにシステム間の認証に使う文字列のことを指す。たとえばAPIを呼び出すときやCI/CDパイプライン（コードのビルドやテストを自動化する仕組み）でリポジトリにアクセスする際に必要になる。このトークンが漏れると、正規のユーザーになりすましてリポジトリを操作できてしまう。
問題のトークンは、GitHubが所有する特定のリポジトリに対する読み取り権限と、一部のリポジトリに対しては書き込み権限も持っていた。これにより攻撃者は、リポジトリの内容を手元にクローン（複製）することが可能だった。ただしGitHubの発表では、攻撃者が実際にコードを改ざんしたり、悪意ある変更を加えたりした証拠は見つかっていないとされている。
攻撃者の行動を振り返る
GitHubのセキュリティチームがログを詳細に分析したところ、攻撃者は以下のような行動をとっていた。トークンを取得したあと、GitHubのAPIを経由してターゲットのリポジトリリストを取得。次に、少数のリポジトリを選んでクローン操作を実行していた。このアクセスパターンは自動化されたスクリプトによるものではなく、人間が手動で操作している形跡が強かったという。
重要なのは、攻撃者がアクセスできたのが「GitHub自身が管理する内部リポジトリ」に限定されていた点だ。一般ユーザーや企業がGitHub上で運用するプライベートリポジトリ、オープンソースプロジェクトのリポジトリ、そしてGitHub.comのサービス基盤そのものには一切アクセスできていなかった。
上の図は、今回のインシデントにおける攻撃者の侵入経路とGitHubが取った即時対応を比較したものだ。漏洩トークンによる不正アクセスは数分で封じ込められ、ログ解析によって影響範囲が正確に特定された。
なぜトークンは漏洩したのか
現時点でGitHubは、トークン漏洩の正確な経路について詳細を明らかにしていない。しかし、過去数年にわたってソフトウェア業界で多発しているトークン漏洩インシデントと照らし合わせると、いくつかの可能性が浮かび上がる。
考えられる漏洩パターン
最も多いのは、ソースコード内にトークンがハードコード（直接埋め込み）されていたケースだ。開発中の利便性からAPIキーやシークレットをコードに直書きし、そのままGitHubの公開リポジトリや内部リポジトリにプッシュしてしまう事故は後を絶たない。
別の可能性としては、CI/CDパイプラインの設定ミスだ。GitHub Actionsのワークフローファイルが適切に構成されておらず、ログにトークンが表示されていたり、サードパーティのサービスに意図せずトークンが送信されていたりするケースがある。
三つ目のパターンは、サプライチェーン攻撃だ。依存している外部ライブラリやツールに悪意あるコードが仕込まれ、ビルドプロセス中に環境変数からトークンを抜き取る手法である。2024年以降、AI開発ツールの増加に伴い、この種の攻撃は急増している。
いずれの経路であれ、根本的な問題は「トークンの権限が必要以上に強かった」ことだ。原則として、トークンには作業に必要な最小限の権限だけを付与すべきである。この「最小権限の原則」を守っていれば、たとえトークンが漏洩しても被害範囲は限定的だったはずだ。
インテグレーションの盲点
今回のケースで注目すべきは、攻撃者が狙ったのが「GitHub自身が所有する内部リポジトリ」であり、ユーザーのリポジトリではなかった点だ。Alexis Wales氏の発表によると、漏洩したトークンは外部サービスとのインテグレーションに使われていた。つまり、GitHubが信頼できるパートナーとして連携していたサービス側で何らかのセキュリティ問題が発生し、トークンが漏洩した可能性が高い。
これは多くの企業が直面するジレンマを浮き彫りにしている。業務効率化のために外部サービスとの連携を深めるほど、トークンの管理箇所は増え、攻撃対象領域（アタックサーフェス）も広がる。GitHubのようなセキュリティ専門企業でさえ、このバランスに苦心しているのだ。
影響範囲と被害の実態
GitHubが公表した調査結果から、今回のインシデントで実際にどのような影響があったのかを具体的に見ていく。
図の通り、影響は極めて限定的だった。GitHubの広報は「ソースコードの一部が意図せず開示された可能性は否定できないが、ユーザーに対する二次被害や連鎖的なセキュリティ侵害は発生していない」としている。
ソースコードの改ざんはなかった
GitHubの調査チームが最も注意深く検証したのは、攻撃者がリポジトリのコードを改ざんしたかどうかだ。結論としては、コミットログやファイルのハッシュ値を含む完全な監査の結果、コードの修正・削除・マルウェアの注入を示す証拠は一切確認されなかった。
これはGitHubのバージョン管理システム（Git）の特性が功を奏した面もある。Gitはすべての変更履歴をSHA-1ハッシュで保護しており、過去のコミットを改ざんしようとすると直ちに検知できる仕組みになっている。攻撃者が万が一コードを書き換えたとしても、その痕跡は完全に残るため、発見は容易だったはずだ。
このインシデントから開発者が学ぶべきこと
GitHubのような巨大プラットフォームですらトークン漏洩を完全に防げなかった事実は、すべての開発者にとって警鐘だ。しかしこのインシデントからは、単に驚くだけでなく、具体的な教訓と実践可能な対策を引き出すことができる。
トークン管理の基本を徹底する
GitHubはインシデント報告の中で、トークン管理のベストプラクティスを改めて強調している。特に重要なのは以下の4点だ。
- トークンの有効期限を短く設定する。可能であれば数時間単位でローテーションする
- トークンに付与する権限を必要最小限に絞り込む。特定のリポジトリだけに読み取り権限を与え、書き込みは別トークンに分離する
- ソースコードや設定ファイルにトークンを直接記述しない。GitHubのシークレット機能や専用のシークレット管理サービス（例としてHashiCorp Vaultやクラウド各社のキー管理サービス）を使う
- リポジトリにトークンが誤ってプッシュされていないか、定期的にスキャンする。GitHubにはプッシュ時に自動検出する機能が標準搭載されている
これらの対策は決して難しいものではない。むしろGitHub Actionsや各種CI/CDツールには、トークンを安全に扱うための仕組みが最初から用意されている。設定を後回しにせず、プロジェクト開始時点で組み込んでしまうのが賢いやり方だ。
侵害を前提とした設計へ
より根本的な教訓は「侵害は起こりうる」という前提に立つことだ。どんなにセキュリティに投資していても、サプライチェーン攻撃やゼロデイ脆弱性（修正パッチが存在しない未知の脆弱性）によって防御線を突破される可能性は常にある。
GitHubのインシデント対応が迅速だった背景には、異常なAPI呼び出しパターンを即座に検知できる監視システムと、トークンを数クリックで無効化できる運用フローが整備されていたことがある。これらは事後対応（インシデントレスポンス）の設計が十分だったからこそ機能した。
この図が示すように、セキュリティの考え方は「侵入を100%防ぐ」から「侵入されても被害を最小限に抑える」へとシフトする必要がある。具体的には、トークンの権限制限、ネットワークのセグメント分離、操作ログの集中管理といった対策を組み合わせることになる。
GitHubの対応から見る、透明性あるインシデント開示の重要性
今回のインシデントで特筆すべきは、GitHubが公表のタイミングと内容において高い透明性を示したことだ。CISOであるAlexis Wales氏が自ら筆を取り、わずか数日のうちに詳細な調査報告を公開した。
セキュリティ業界では、こうした迅速な情報開示は「ラディカル・トランスペアレンシー（徹底した透明性）」と呼ばれ、近年ではGoogleやMicrosoftも同様の姿勢を取っている。ユーザーにとっては、隠蔽されるよりも正直に報告されたほうが信頼を損なわず、適切な防御策を取る時間も確保できる。
GitHubの発表には「ユーザーが取るべき具体的なアクションはない」と明記されていた。これ自体が重要な情報だ。影響範囲が明確に線引きされているからこそ、ユーザーは不要な心配をせずに済む。逆に言えば、影響範囲が不明瞭な発表ほどユーザーの不安と憶測を招く。
この記事のポイント
- 2026年5月、GitHubが内部リポジトリへの不正アクセスを公表。攻撃者は漏洩したトークンを使用して一部のリポジトリを閲覧・クローンしたが、コードの改ざんやユーザーデータへのアクセスはなかった
- 影響を受けたのはGitHub自身が所有する一部の内部リポジトリのみで、一般ユーザーのプライベートリポジトリやオープンソースリポジトリには一切影響が及んでいない
- トークン漏洩の原因は調査中だが、過去の業界事例からハードコードやCI/CD設定ミス、サプライチェーン攻撃などの可能性が考えられる
- 開発者が取るべき対策は明確で、トークンの有効期限短縮、最小権限の原則の徹底、シークレット管理サービスの利用、プッシュ時の自動スキャン活用が有効
- GitHubの迅速かつ透明性の高いインシデント開示姿勢は、業界全体の模範となる対応だった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験