数年前に制作会社へ発注したきり、更新も保守も誰も見ていないコーポレートサイト。ドメインとサーバーの請求だけは毎年落ちているけれど、管理画面に最後にログインしたのがいつだったかも思い出せない。そんな状態のサイトを持っている中小企業は、決して珍しくありません。
そのタイプのサイトにとって、2026年7月中旬に明らかになった WordPress 本体の脆弱性は、放置しておけない類のニュースです。多くのサイトが動いている WordPress で、「プラグインを入れているかどうか」に関わらず標準的な構成のサイトが対象になり、しかも未認証の攻撃者が乗っ取りに至り得る——普段はセキュリティの話を聞き流している発注者ほど、今回は自分のサイトの状態を確認してほしい理由があります。
この記事では、何が起きたのかをかみ砕いたうえで、保守契約を結んでいない・制作会社に任せきりの中小企業のサイトオーナーが今すぐ確認すべきことを、放置したときに何が起きるのかと合わせて整理します。専門用語はできるだけ避け、「発注した側」の視点で書きます。
何が起きたのか——「wp2shell」という本体の脆弱性
2026年7月17日、WordPress の運営元は、本体（コア）に危険度の高い脆弱性が見つかったとしてセキュリティ更新版を公開し、対象バージョンのサイトに対して自動更新システム経由での強制的なアップデートを有効化しました。修正版として WordPress 6.8.6・6.9.5・7.0.2 が配布されています。異例なのは、この「運営元が半ば強制的に更新をかける」対応です。
問題になったのは、REST API のバッチ処理でリクエストと処理内容の対応関係がずれる不具合（CVE-2026-63030）と、記事検索の内部処理に攻撃者が値を送り込める SQL インジェクションの不具合（CVE-2026-60137）の2件です。この2つを連鎖させると、ログインもパスワードも不要な「未認証」の状態から、サーバー上で任意のプログラムを実行できるリモートコード実行（RCE）にまで至り得るとされ、発見者はこの攻撃手法を「wp2shell」と名付けました。実際に悪用が観測され、攻撃コードも出回っているとして、各所から早期更新の注意喚起が出ています。
ここで押さえておきたいのが、危険度の並びです。今回の脆弱性は「誰でも撃てる（未認証）」「結果はサイトの乗っ取り（RCE）」「追加のプラグインが不要で標準構成のサイトがそのまま対象」という条件が同時に揃っています。WordPress の脆弱性は、集計によっては9割超がプラグインやテーマ由来とされ（Wordfence の2024年レポートでは約91%がプラグイン起因）、本体そのものでこのクラスの欠陥が見つかるのは稀です。「うちは特別なプラグインを入れていないから大丈夫」という感覚が、今回は通用しません。
もう一つ、放置サイトのオーナーにとって嫌な性質があります。攻撃に使われるリクエストは正規のエンドポイントへ送られる整った通信で、いかにも攻撃らしい怪しい文字列を含まないため、入口（WAF などの防御）で機械的に弾くのが難しいとされる点です。つまり「サーバー会社が何かで守ってくれているはず」という期待だけに頼るのは危うく、結局は本体を更新済みにしておくことが最も確実な守りになります。
なぜ「放置サイト」が特に危ないのか
脆弱性そのものは、更新すれば塞がります。問題は、更新する人がいないサイトです。制作会社に作ってもらったまま保守契約を結んでいない、あるいは当時の担当者が退職して管理画面の情報すら残っていない——そういうサイトは、運営元が強制更新をかけても、サーバーの設定や WordPress のバージョンによっては自動更新が効かず、古いまま放置されることがあります。守りの網から漏れやすいのは、いつも「誰も見ていないサイト」です。
乗っ取られたサイトに起きることは、派手なものばかりではありません。むしろ厄介なのは、静かに進行するタイプの被害です。攻撃者はサイトを乗っ取ると、まず気づかれないように振る舞います。よくあるのが、各ページに見覚えのない海外向けの不正リンクや広告を大量に埋め込む改ざんです。この状態が続くと、Google がそのサイトを「危険なサイト」「不正なコンテンツを含むサイト」と判定し、検索結果に警告が付いたり、ブラウザで開こうとすると赤い警告画面が表示されるようになります。
ここから先が、中小企業にとって本当に痛いところです。警告が付いたサイトは検索流入が急落し、それまで積み上げてきた検索評価（SEO）が大きく毀損します。取引先に「おたくのサイト、ウイルスの警告が出るよ」と指摘されて初めて気づく、というケースも実際にあります。改ざんの掃除と Google への再審査申請には時間がかかり、その間ずっと機会損失が続きます。「作って終わり」のサイトが抱えるこうしたリスクは、以前 「作って終わり」のホームページが危険な理由 でも整理したとおりで、今回の本体脆弱性はその引き金の一つが増えたと考えるとわかりやすいはずです。
もう一つ見落とされがちなのが、フォーム経由の個人情報です。お問い合わせフォームや資料請求フォームを設置しているサイトが乗っ取られれば、そこから送信された顧客の氏名・連絡先・商談内容が抜き取られる、あるいはフォームに不正なコードを仕込まれて入力情報を横取りされる恐れがあります。乗っ取りは「自社サイトが汚れる」だけでなく、「預かった顧客情報を漏らす」という、対外的な信用問題に直結します。
| 放置サイトで起こり得ること | 表に出る影響 |
|---|---|
| ページ改ざん・不正リンクや広告の埋め込み | Googleの警告表示、ブラウザの赤い警告画面 |
| 検索エンジンからの評価低下 | 検索流入の急落、SEO評価の毀損 |
| Webシェル設置・管理権限の奪取 | サイトを踏み台に他所を攻撃、復旧の長期化 |
| フォームからの情報流出 | 顧客個人情報の漏えい、対外的な信用失墜 |
自社サイトで今すぐ確認する3点
専門知識がなくても、発注者の立場で確認できることがあります。まずは次の3点です。
第一に、そのサイトが WordPress で作られているかどうかです。制作会社に「うちのサイトは WordPress ですか、バージョンはいくつですか、今回の本体脆弱性（wp2shell）の対応は済んでいますか」と一本連絡を入れるだけで十分です。返答があれば、更新状況を確認して記録に残しておきましょう。
第二に、そもそも「連絡が取れる先」があるかどうかです。制作会社と契約が切れている、担当者が退職した、当時の会社が廃業した——そうした「持ち主も管理者も曖昧なサイト」は、今回のような一斉更新の場面で最も取り残されやすい存在です。管理画面のログイン情報、サーバーの契約情報、ドメインの管理権限が今どこにあるのかを、この機会に洗い出してください。連絡の取れなくなったサイトをどう引き継ぐかは 制作会社と連絡が取れないサイトの引き継ぎ で扱っています。
第三に、更新が「自動で当たる状態」になっているかです。今回は運営元が強制更新をかけていますが、それはあくまで自動更新が有効に働くサーバー環境が前提です。古い PHP のまま止まっている、独自にカスタマイズしていて自動更新を切っている、といったサイトは対象から漏れることがあります。制作会社や保守事業者に「自動更新が効いているか、本体は最新のセキュリティ版になっているか」を確認してもらうのが確実です。
| 確認する人 | 確認すること |
|---|---|
| 発注者（自分）が今日できること | WordPress かどうか、連絡の取れる管理者がいるか、契約情報の所在 |
| 制作会社・保守事業者に確認すること | 本体バージョン、wp2shellの対応済みか、自動更新が有効か |
保守を外注で回すか、内製で回すかの判断
今回のような事態が示しているのは、「サイトは公開したら終わり」ではなく、公開後も誰かが継続的に面倒を見る必要がある、という当たり前の事実です。判断の軸はシンプルで、「脆弱性の一報が出たときに、24〜48時間以内に自社サイトの状態を確認して手を打てる人が社内にいるか」です。
いる場合は、内製でも回せます。WordPress の管理画面を定期的に確認し、本体・プラグイン・テーマの更新を当て、バックアップを取り、フォームの動作をチェックする——この程度の運用を担える担当者がいれば、外部に頼らずとも最低限の守りは成り立ちます。ただし、更新によって表示崩れや不具合が出ることもあるため、変更前後の確認をおろそかにしないことが前提です。
いない場合は、保守を外注で回すのが現実的です。今回のような緊急時に「誰に連絡すればいいか分からない」状態を避けられること自体が、保守契約の価値の中心です。プラグイン経由でリスクが持ち込まれるケースなど、判断に専門知識を要する場面も増えており、自社だけで抱え込むより外部の目を入れたほうが安全なことは多いはずです。なお、Webセキュリティの基礎を発注者としてひととおり押さえておきたい場合は Webセキュリティ対策入門 が参考になります。
自社サイトが今どういう状態にあり、どこまで守れているのかは、構成や運用体制によって一つひとつ異なるため、個別に診断してみないと判断できません。「うちのサイトは大丈夫なのか、保守はどう組めばいいのか」を切り分けたい場合は、状態を確認したうえで見積りを出すところから始めるのが確実です。
まず取る一手
難しく考えず、今日できる一手から始めてください。まずは制作会社か保守事業者へ「うちのサイトは WordPress か、今回の本体脆弱性の対応は済んでいるか、自動更新は効いているか」を一本問い合わせること。そして、連絡の取れる管理者がいない・契約情報の所在が曖昧だと分かったら、そのまま放置せず、サイトの引き継ぎと保守体制の見直しに動くことです。
自社サイトの状態確認から保守・リニューアルの相談まで、どこから手をつければよいか判断がつかない場合は、お問い合わせください。まずは今のサイトがどういう状態にあるのかを一緒に確認するところから始められます。
Sources
- WordPress本体に重大脆弱性、運営元が異例の強制更新 専門家が語る“本当の危険”（＠IT）
- WordPress Coreの脆弱性 CVE-2026-63030 / CVE-2026-60137（通称「wp2shell」）についてまとめてみた（piyolog）
- WordPressの深刻度「緊急」脆弱性 wp2shell の概要と対応指針（GMO Flatt Security Blog）
- WordPress 本体で危険度の高い脆弱性 wp2shell（セキュリティ対策Lab）
- wp2shellとは?WordPress緊急脆弱性(CVE-2026-63030)の対応方法とSEOへの影響（オレンジソフトウェア）
- Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6（Searchlight Cyber）
- Wordfence 2024 Annual WordPress Security Report（プラグイン起因が約91%）
