WordPress乗っ取りの仕組み—弱い管理者IDとパスワードから何が起きるか

「WordPress 乗っ取り」という言葉で検索してこのページに来た方の状況は、いくつかに分かれます。すでに管理画面に入れない、表示や検索結果に異常が出ているなど、具体的な症状に直面している方。「脆弱性が悪用されました」という警告だけを受け取り、何が起きているのか分からない方。そして、まだ何も起きていないものの、不安だけが先にある方です。

この記事は、WordPressサイトについて、乗っ取りが実際にどう起きるのかを知りたい方に向けたものです。扱うのは、入口・被害の現れ方・気づき方の3点であり、復旧の具体的な手順や料金、所要時間はここでは扱いません。すでに画面が開かない状態にある方向けの案内は、記事の途中で触れています。まだ何も起きていない方も、途中で読むのをやめず最後まで見てください。気づき方の話は、そのまま予防の話にもつながります。

「乗っ取り」という言葉は幅が広く、検索する側の状況によって求めている答えが違います。今まさに画面がおかしい方には気づき方の確認が要りますし、警告文だけを受け取った方には何が起きうるのかという見通しが要ります。両方に共通する土台として、この記事では保守の現場で実際に対応した事例をもとに、入口・現れ方・気づき方の順に見ていきます。最後まで残る論点は、入口の状態と、見ている人の有無という2点。

結論から言うと、「乗っ取られた」はサイトが壊れることと同じ意味ではありません。侵入されることと、被害が表に出ることは別の出来事として起きます。この分離が、この先の話全体の前提になります。

何者かが管理画面に入り込んだ瞬間と、それによる被害が実際に表へ出てくる瞬間は、同じタイミングでは起きません。保守の現場で実際に対応した事例でも、侵入そのものと、被害が明確な形で見えるようになるまでの間には時間差がありました。侵入と被害は、別の出来事です。この時間差が、後述する「なぜ長い間気づけないのか」という問いに直結します。侵入された瞬間に何かが分かりやすく壊れる、という想定は、いったん外して読み進めてください。

管理画面にログインできない、あるいは画面が真っ白になっている状態を見ると、たいていの方はまず乗っ取りを疑います。実際に乗っ取られた事例でも、発見時はサイトが白い画面になり、ログイン画面そのものが表示されない状態でした。

ただし、ログインできない・画面が真っ白になるという症状は、乗っ取り以外の原因でも起こります。保守の現場では、テスト環境を用意せずに本番環境へ直接プラグインの更新を反映し、そのまま画面が真っ白になったという相談を受けた事例もあります。この場合の原因は更新の不具合であり、侵入ではありません。

見分けを誤ると、対応の方向そのものを誤ります。乗っ取りだと思い込んで身構える前に、まず何が起きているのかを切り分けることが必要です。この記事の主題は乗っ取りですが、原因を切り分ける前提として、症状だけでは判断できないという事実を先に置いておきます。更新不具合そのものの直し方はここでは扱いません。

「脆弱性が悪用されました」という警告を受け取って検索している方も少なくありません。この警告文そのものを主語にした解説は、検索結果の上位にもほとんど見当たりません。

保守の現場でセキュリティ診断の結果を見せると、項目によって相手の反応に濃淡が出ます。自分に関わる情報が外部から見えてしまうと分かると強く反応する一方、専門的に響く項目については、それの何が問題なのかピンとこない、という反応になりがちです。抽象的な説明だけでは、危険性は実感として伝わりません。

警告文を受け取った方が本当に知りたいのは、何でしょうか。脆弱性という言葉の定義ではなく、自分のサイトに何が起きうるのかという点のはずです。定義の説明を重ねるだけでは、この温度差は埋まりません。だからこそこの記事では、脆弱性という言葉の解説ではなく、実際に何が破られ、何が起きたのかという具体の側から説明していきます。この記事で先に答えておくと、警告が届いた時点でまだ被害が出ていないなら、次章で説明する「実際に破られた入口」を先に確認することが、最も具体的な次の一歩になります。

結論から言うと、今回取り上げる事例で実際に破られた入口はログイン画面でした。「パスワードが弱いと突破される」という一般論ではなく、実際に1本の経路がどう破られたかを、ここでは具体的に見ていきます。

保守契約を結んでいるかどうかで、見ている人がいるかどうかが変わります。対象は、過去に制作を担当したものの、保守契約は結んでいなかったサイトでした。このサイトの管理者IDは admin のままで、パスワードも複雑さの面では最低限の体裁を保っているに過ぎませんでした。この水準の認証情報は、繰り返し試されれば遅かれ早かれ破られます。実際に、この状態のままログイン画面を通じて侵入を許す結果になりました。

「ログイン保護を怠るとこうなる」という主張を、実例として言い切れる事例です。管理者IDが admin のままだと、侵入を試みる側は最初から手がかりの半分を持っている状態になります。残るパスワードを繰り返し試されるだけで、突破される可能性は上がっていきます。パスワードの複雑さだけでは守り切れないという現実が、ここにある。

なお、当該サイトを運営していた事業者や、被害の規模を特定できる情報は本記事に含めていません。

破られる場所は、ログイン画面だけとは限りません。本体や、導入しているプラグインが長い間更新されないまま残っている状態も、そこが糸口になることがあります。

本体・プラグインいずれについても、修正が必要な状態が見つかるたびに更新版を公式に配布する仕組みがWordPressには備わっています。実際に2026年8月にも、本体の更新版が複数回、公式に配布されています(出典: WordPress.org 公式リリース情報、2026年9月2日確認)。更新が用意されているということは、その裏に直す必要のある状態があったということです。

使っているプラグインの数が増えれば、その分だけ更新すべき対象も増えます。1つでも長く放置されたものが残っていれば、そこが入口になり得る。未更新がどのような弱点を生むのか、その種類や塞ぎ方までは、別の記事で扱う範囲になります。ここで押さえておきたいのは、入口はログイン画面だけに限らないという事実だけです。

侵入の経路について、断定できることと、断定しないことをここで分けておきます。

弱い管理者IDとパスワードによってログイン画面から侵入されたことは、事実として断定できる。一方、FTP(ファイルをサーバーへ直接送り込むための古くからある接続手段)の認証情報も同様に弱い状態だったため、FTP経由でも不正なファイルを直接仕込まれた可能性が現場では指摘されていますが、これは推定にとどまり、断定はしていません。

同様に、不審なファイルをすべて取り除けたかどうかについても、完全に除去しきれたと言い切ることはしていません。ハッカーがどのような手口を使ってくるかは一般論でしか分からない、という前提に立ち、復旧後は保守の中で日々状態を確認する継続監視の体制に移行しています。

断定できることは断定し、断定できないことは断定しない。この線引き自体が、対応の姿勢を表しています。分かっていないことを分かっているかのように語らないことは、報告を受け取る側の判断を誤らせないための最低条件でもあります。

結論から言うと、被害には画面を見て分かるものと、画面を見ても分からないものがあります。同じ入口から侵入されても、その後どんな形で被害が現れるかは一様ではない。同じ弱点から始まった被害でも、現れ方が違えば気づき方も違ってきます。

最も気づきにくい被害の現れ方が、これです。サイト自体を開いても、表示は正常に見える。しかし検索結果だけが別物になっているケースがあります。

実際の事例で確認された被害は、検索エンジンを狙ったスパムでした。自社の名前で検索してみると、検索結果から外部のサイトへ転送されるケースや、ページ自体は普段どおり開けるのに、検索結果の見出しと説明文だけが書き換わっているケースがありました。

なぜこうなるのでしょうか。侵入者は、訪問者が直接見る画面ではなく、検索エンジンが読み取る情報を狙って書き換えを仕込みます。そのため、自分のサイトを普段どおり開いているだけでは異常に気づけません。どこを見れば分かるのかというと、検索エンジンで自社名を検索し、表示されるタイトルと説明文が本来の内容と一致しているかを確認することです。

この現れ方は、実害としても軽くありません。自社名で検索した見込み客が、本来のページに代わって見慣れないタイトルを目にすれば、そのまま離脱してしまいます。サイトの中身は無事でも、外から見える入口だけが乗っ取られている、という状態です。

この現れ方には、固有の呼び名があります。「リダイレクトハッキング」です。検索結果からサイトへアクセスしようとすると、意図しない別のサイトへ転送されてしまう症状を指します。

今回のケースでも、検索結果を経由すると別サイトへ転送される状態が確認されています。前項で見た「検索結果の表示だけが変わる」現象と、根っこは同じ入口から出ています。転送先への案内は検索結果の側に仕込まれているため、サイトを直接開いて運営している人の視界には入りません。管理画面をいくら確認しても、ファイルを一つずつ見ても、この現れ方には気づけないことがあります。検索エンジン経由の動線を通らなければ再現しない症状だからです。

「勝手に別のサイトへ飛ばされる」という症状名だけで検索すると、原因が分からず不安が先に立ちます。しかし固有の呼び名を知っていれば、次に何を調べればよいかの見当がつけやすくなります。この記事で扱うのは、リダイレクトハッキングという症状が起きる背景と、この呼び名の存在までです。型の分類や、この症状固有の確認・防止の実装レベルの話には立ち入りません。

最も分かりやすい被害の現れ方は、画面が開かなくなる、あるいは真っ白になるというものです。実際の事例でも、発見時はサイトが落ち、ログイン画面すら表示されない状態でした。

分かりやすい反面、この段階まで進んでいるということは、被害がすでにかなり進行しているとも言える。表示不可・エラーページ・サーバー会社による停止措置など、より重大な事象が起きて初めて気づくケースが大半を占めています。裏を返せば、それより前の段階、つまり検索結果だけが書き換わっている段階では、気づけていないということです。この気づけない構造については、次章で詳しく扱います。

すでにサイトが開かない、真っ白になっているという状態にある方は、原因の見きわめから対応が必要な段階です。改ざんサイトの緊急復旧サービス（当日〜スポット対応）で対応しています。

結論から言うと、気づけないのは注意力の問題ではありません。見える場所に異常が出ないという構造そのものが、気づきを遅らせています。

前章で見た検索結果だけの書き換えは、まさにこの典型です。自分のサイトを開いても異常は見えません。検索結果の変化に気づいて連絡してくる方は、実際には稀です。表示できない・エラーが出る・サーバー会社から連絡が来るといった、より分かりやすい事象が起きてから初めて発覚するケースがほとんどです。画面の上に何も出ない期間がある限り、気づく手がかり自体が存在しないのです。注意深く見ていなかったからではなく、見える場所に手がかりが出ない被害だから見過ごされる。この違いを取り違えると、対策の的も外れてしまう。

もう一つの理由は、そもそもサイトを見ている人がいない期間が続くことです。過去に制作を担当したものの保守契約のなかったサイトが、長期間の連絡の途絶のあと、被害として戻ってきた事例があります。

サイトを公開したあと、誰も定期的に状態を確認していなければ、異常が起きても誰にも見えません。特別な話ではなく、保守契約という「見ている人」がいるかどうかの違いが、そのまま結果に表れた形です。制作した時点では最新の状態でも、時間が経てば経つほど、見ている人のいないサイトと、そうでないサイトの差は開いていく。

「うちのような小さい会社のサイトが狙われるはずがない」という考え方は、根強く残っています。しかし、狙われるかどうかを分けているのは会社の規模ではありません。規模ではなく、入口の状態です。

独立行政法人情報処理推進機構(IPA)が2026年1月に公表した「情報セキュリティ10大脅威 2026」の組織編は、企業規模を区分せず「組織」を対象にランキングを構成しています(出典: IPA公式サイト、2026年9月2日確認)。上位2位には「サプライチェーンや委託先を狙った攻撃」が挙げられており、取引先を経由する形で、規模の小さい組織も対象に含まれうることを示しています。1位のランサム攻撃による被害は11年連続11回目、2位のサプライチェーンや委託先を狙った攻撃は8年連続8回目のランクインです(出典: 同上)。単発の傾向ではなく、それぞれが長期にわたって上位に居座り続けているということです。

保守の現場でも、規模の小さいサイトだからという理由で被害を免れているという実感はありません。そうしたサイトであっても、狙われる可能性から除外されるわけではないのです。狙われるかどうかを決めているのは、規模ではなく、弱い入口が残っているかどうかです。

結論から言うと、見え方だけでは分からなくても、記録には残ります。見え方からではなく記録から確認するという、順序の話をします。

画面が落ちた・白くなった・表示が崩れたという見た目の症状を起点にするのではなく、まずサーバー側の記録—アクセスログや負荷の状況—を確かめる。保守の現場では、この順番が徹底されている。

特に異常が起きていなくても、今の状態の理由が気になって問い合わせが来ることがあり、その際も記録を確かめたうえで理屈を説明する、という対応が取られています。ご自身で確認する場合の最初の一歩も同じです。アクセスログと負荷の状況を開き、普段と違う時間帯の集中や、見覚えのないアクセス元がないかを見てください。見た目の症状から入ると、その症状に引きずられて判断を誤りやすくなりますが、記録から入れば起きた順番をそのまま追うことができます。

「管理画面を見て問題がなかったから大丈夫」と思ってしまう場合が少なくありません。ただ、不具合の原因になりうる場所はいくつかあり、そのすべてがWordPress自体の中にあるとは限らない。

回線がサーバーへ届くまでの手前の部分、サーバー自体の設定、そしてWordPress本体の作り。この3か所のどこかに、見つけるべきものが隠れている可能性があります。手前の部分については利用者がすでに用意していることが多く、それをうまく使えるかどうかも鍵になります。

どの部分に手を入れるかという選択の話は、この記事の範囲外です。ここで伝えたいのは、管理画面だけを見ていては答えが出ないケースがある、ということだけです。仮にWordPress内部を調べて何も出なかったとしても、それだけで油断すると、他の部分に潜んでいるものを取りこぼしてしまいます。

改ざん検知プラグインなど、自分でできる確認の手段もあります。ただし、これらの仕組みは基本的に「入られたあとに知らせるもの」であり、入口そのものを閉じるものではない。

保守の現場では、サーバー側の標準機能と、専用のプラグインを組み合わせて不正なプログラムの検知にあたっています。また前章で触れたとおり、外から見えてしまう情報がきっかけとなって、危険な状態に気づくこともあります。ただし、こうした確認手段はあくまで気づくためのものであり、それだけで入口が閉じるわけではありません。特定の製品を導入すれば安心、という考え方はここでは成立しません。検知の仕組みと、入口を閉じる対策は役割そのものが違います。製品の選定や導入手順はここでは扱いません。

結論から言うと、同じ弱点について、被害になった場合と、被害になる前に止まった場合の両方があります。

前の章で見た事例と同じ弱点、つまり管理者IDが admin のままになっている状態は、別の顧客のサイトでも見られました。あるサイトでは、管理者IDに admin が使われており、ログインの試行によるロックアウトが頻発していました。被害が実際に出る前に、保守チームからユーザー名の変更を提案し、実施しています。

変更してからは、ログインを試みる動きが目に見えて減り、いたずら目的と思われるアクセスもほとんど見かけなくなりました。同じ弱点でも、一方は被害につながり、もう一方は被害の手前で止まっています。分かれ目になったのは、被害が出る前に気づいて動けたかどうかです。二要素認証のような追加策を取り入れている顧客はまだ少数派ですが、管理者名の変更のようにすぐ始められる対策から着手する意味は大きいと言えます。

認証情報を直しても、入口そのものが開いたままであれば、同じ経路が再び使われる可能性は残る。前章で見た事例でも、必要な対応を行う一方で、取り除けたかどうかを完全には断定していません。

閉じたはずの入口は、本当に閉じているのか。断定できないことを断定せず、見続ける側に立つ。これが、再発を防ぐための現実的な姿勢です。復旧後は、保守の中で日々状態を確認する継続監視の体制に移行しています。一度直して終わりにするのではなく、閉じたはずの入口が本当に閉じているかを、時間をかけて確認し続けています。「対処したから、もう安心」と考えて確認をやめてしまうことが、再発を招く最も大きな落とし穴です。

WordPressに修正が必要な状態があることは、公式に更新版が配布されるたびに明らかになります。前述のとおり、直近でも本体の更新が複数回公式に配布されました。こうした局面で、連絡を受けてから動くのではなく、状況をこちらから先に伝え、対応済みであることを報告する。この動き方が、保守の現場に根づき始めています。

聞かれる前に動く、という運用は、地味に見えて実際には成功体験として現場に積み重なっています。保守は壊れたときのために存在するのではなく、壊れる前に動くために存在する。この考え方の一次的な裏づけです。連絡を待つ姿勢のままでは、この動き方は生まれません。状況を能動的に把握していることが前提になります。

ログインページの保護、本体とプラグインの更新、バックアップ体制の確保。これらは、セキュリティの話題では必ず出てくる基本の対策です。誰もが知っている内容であるにもかかわらず、保守の現場から見ると、この最低限が徹底されていない先が少なくない。

この記事でも、対策の一覧を並べ直すことに、あまり意味はありません。目を向けるべきは、一覧としては誰もが知っているのに、なぜ実行されないのかという理由の方です。理由の多くは、危機感の欠如や、何から手をつければよいか分からない状態にあります。知っていることと、実行していることは、別物です。まずは、自分のサイトで今の状態がどうなっているかを確認するところから始められます。

無料URLセキュリティ診断で再発の有無を確認する

入口を閉じたかどうかと、見ている人がいるかどうか。この2つが揃って初めて、同じことの繰り返しを避けられます。乗っ取りは、特別な攻撃を受けたから起きるとは限りません。開いたままの入口と、見ている人がいない期間が重なったときに起きています。逆に言えば、入口を閉じ、見ている人を絶やさなければ、同じ経路が使われる余地はそれだけ小さくなります。特別なことをする必要はありません。この記事で見てきた、入口を確かめる・被害の現れ方を知る・記録から状態を確認するという、地道な積み重ねの延長線上にあります。

WordPress保守・セキュリティ対策の詳細を見る

WordPress保守を担当するビークリエイトのチームの知見をもとに、本記事を構成しています。詳しくは会社概要をご覧ください。