想定読者
自社サイトをWordPressで運用している中小企業の広報・総務担当者(IT専任者不在で、外部の制作会社に委託しつつ日常更新は自社で行っているケースを想定)
要点
- WordPressの脆弱性は「更新放置」と「不正ログイン」の2パターンに集約されます
- ツール導入や大掛かりな改修は不要で、設定変更だけでできる対策を優先順位付きで紹介します
- メールのなりすまし対策とは別領域のため、本記事はCMS本体の防御に限定します
「うちは狙われない」が一番危ない
中小企業サイトが狙われる理由
サイバー攻撃というと大企業を思い浮かべがちですが、実際の攻撃の多くは自動化されたプログラムによる無差別スキャンです。攻撃者は企業の規模ではなく、古いバージョンのまま放置されたサイトを機械的に探し出します。「小さな会社だから狙われない」という前提は成り立ちません。
被害が起きたときの実害
サイトの内容を書き換えられる改ざんや、サイトを乗っ取って別の攻撃の踏み台にされる被害に加え、検索エンジンから警告表示され問い合わせが減るなど、信用面での損失も小さくありません。
脆弱性の入り口は2つしかない
放置されたバージョン(本体・テーマ・プラグイン)
WordPress本体だけでなく、デザインを決めるテーマや機能を追加するプラグインにも脆弱性は見つかります。開発元は修正版を公開していますが、更新を後回しにしている間は既知の弱点が公開されたままになります。
推測されやすい管理画面ログイン
もう一つの入り口はログインです。管理者IDが初期設定の「admin」のままだったり、パスワードが単純だったりすると、ID・パスワードを機械的に総当たりで試す攻撃(ブルートフォース攻撃)の標的になりやすくなります。
今日からできる3つの対策
自動更新をオンにする
WordPress本体は管理画面の設定で自動更新を有効にできます。テーマやプラグインも多くは個別に選べるため、制作会社と相談のうえ重要なものから順にオンにしましょう。
管理者IDを変え、ログイン試行回数を制限する
「admin」など推測されやすいIDを使っている場合は新しい管理者を作成して切り替えます。あわせて、ログイン失敗を一定回数で一時ブロックする設定や、パスワードに加えて追加確認を行う二段階認証を導入すると、不正ログインのリスクを大きく下げられます。
定期バックアップを別サーバーに残す
万一被害に遭っても、直前の状態に戻せるバックアップがあれば復旧の時間を短縮できます。サイトと同じサーバーだけでなく、別のサーバーやクラウドストレージにも定期的に保存しておくことが重要です。
制作会社に任せている場合の確認ポイント
更新作業の頻度と責任範囲を契約で確認する
「更新は制作会社がやってくれているはず」という思い込みは危険です。本体・テーマ・プラグインそれぞれの更新頻度と、誰がどこまで対応する契約になっているかを確認しておきましょう。
月次点検レポートをもらう習慣をつける
更新状況やバックアップの実施状況を毎月レポートしてもらう習慣をつけると、対応漏れに自社でも気づきやすくなります。
なお、メールのなりすまし対策については別記事で扱っていますので、そちらをご参照ください。
2026年10月のPHP脆弱性への対応策
何が起きたのか
2026年10月21日（日本時間23時ごろ）、PHPの開発元が重大な脆弱性2件（CVE-2026-109618・CVE-2026-109619）を修正した版を公開しました。
深刻度はCVSS v4.0で9.2の「緊急」に当たり、条件がそろうと、ログインしていない外部の人にサーバー上でプログラムを実行される恐れがあります。
対象はWebのリクエストを処理するPHP全般で、PHP-FPMやApacheのmod_phpなどが含まれます。
修正版は8.5.12・8.4.27・8.3.36・8.2.35です。
この記事で取り上げてきた本体・テーマ・プラグインの問題とは違い、WordPressが動く土台であるPHPそのものの問題です。
そのため、WordPressを最新にしていても影響を受けます。
お店に例えると、WordPressの本体やプラグインの脆弱性は「店内の棚や裏口の鍵」の問題でした。
今回は「お店が入っている建物の基礎」の問題です。店内をどれだけ整えても、建物の土台に穴があれば、そこから入られてしまいます。
「ログインせずにプログラムを実行される」とは、合鍵を持たない人が外から入り込み、レジや機械を勝手に操作できてしまう状態です。
改ざんや情報の持ち出し、ほかへの攻撃の踏み台など、サーバーの上でできることはほぼ何でもされる恐れがあります。
2件の仕組みは、受付の窓口に例えると分かりやすくなります。1件目（CVE-2026-109618）は、受付係が荷物を受け取る途中で手がいっぱいになり（メモリ不足）、書きかけの伝票を残したまま作業を打ち切ってしまう問題です。
あとで片付ける係が、その書きかけの伝票を正しいものとして処理してしまい、そこを突かれます。
2件目（CVE-2026-109619）は、前のお客さんが返したはずのロッカーの番号札が、次のお客さんの手続きでまだ使われてしまう問題です。
PHPは1つの処理係が何人ものお客さん（リクエスト）を順番に受け付けるため、前の人の後始末が不完全だと、次の人の手続きに古い情報が紛れ込みます。
開発元は公開の時点で実際に動く攻撃コードは確認していないとしています。
しかし、海外のセキュリティ報道では公開前から攻撃の試みが観測されたと伝えられており、国内でもレンタルサーバー各社が管理画面を一時停止するなどの予防的なメンテナンスを行いました。
まずPHPのバージョンとサーバー会社の告知を確認する
WordPressの管理画面で「ツール」→「サイトヘルス」→「情報」→「サーバー」を開くと、PHPのバージョンを確認できます。
「8.3」ではなく「8.3.36」のように末尾の数字まで見てください。
共用のレンタルサーバーでは、PHP本体の更新はサーバー会社の仕事です。たとえばエックスサーバーは、10月22日14時までに提供中のPHP 5.6〜8.5のすべてに修正を適用したと告知しています（5.5以下は準備中）。
共用のレンタルサーバーは賃貸マンションのようなもので、建物の修繕は大家さん（サーバー会社）が行います。
入居者がすべきことは、大家さんのお知らせを読み、修繕が済んだか、部屋の側で何かする必要があるかを確かめることです。
サーバー会社が独自の修正で対応している場合は、表示されるバージョンの数字が修正版と一致しないこともあります。
数字だけで判断せず、契約しているサーバー会社のお知らせで、対応が済んだか、利用者側の作業が必要かを確かめましょう。
PHP 8.1以前ならサポート中の版へ切り替える
PHP 8.1以前は開発元からの更新が終わっており、今回も正式な修正版は出ていません。サーバーの管理画面で8.1以前を選んでいる場合は、サポート中の版へ切り替えましょう。
メーカーの部品の供給が終わった古い型の鍵を使い続けているようなもので、今回のような欠陥が見つかっても、メーカーからの交換部品は届きません。
8.2も2026年12月31日でセキュリティ修正が終わるため、切り替えるなら8.3以上が目安です。
切り替える前にバックアップを取り、切り替えた後はページの表示やお問い合わせフォームが正しく動くかを確認してください。
VPSや自社管理のサーバーはすぐに更新する
VPSやクラウドでサーバーを自社管理している場合は、修正版へ更新したうえで、PHP-FPMやApacheを再起動します。
主なLinuxディストリビューションには事前に修正が配られているため、OSのパッケージの更新を確認してください。
VPSや自社管理のサーバーは持ち家と同じで、修繕を代わりにしてくれる大家さんはいません。自分で直さない限り、穴は開いたままです。
すぐに更新できない場合に向けて、開発元は一時的な緩和策も示しています。
ただし「更新だけが完全な対策で、設定変更では安全にはならない」と明記されているため、あくまで更新までのつなぎです。
割れた窓に板を打ち付けるような応急処置で、確認されている侵入経路はふさげても、窓そのものが直ったわけではありません。
- session.upload_progress.enabled を 0 にし、すべてのPHPプロセスを再起動する（php.iniやFPMプールの設定で行う。ini_set() や .user.ini では効かない）
- memory_limit を -1 にし、アプリから上書きできない形（php_admin_value など）で設定する
- post_max_size を小さくする（ファイルのアップロードを使わないなら8M、使うなら32Mが目安）
- PHP 8.5では fatal_error_backtraces も 0 にする
10月23日に追加された脆弱性への対処
10月23日、PHPの開発元は新たな脆弱性（CVE-2026-115560）についての告知を出しました。
この脆弱性も、条件がそろうと、外部の人にサーバー上でプログラムを実行される恐れがあるものです。
ただし、起きるのは珍しい設定とプログラムの組み合わせのときだけです。開発元も実際には起こりにくいとして、緊急の修正版ではなく、次の定例の更新で直すとしています。
起きるのは、次の3つがすべてそろったときです。
- 設定で session.serialize_handler（セッションの保存形式）を php_binary か php_serialize にしている
- プログラムの中で ini_set() を使い、session_start() の前にその形式を php に切り替えている
- session.upload_progress.enabled（アップロードの進み具合の記録）が有効のまま
session.serialize_handler の初期値は php なので、初期設定のまま使っていれば当てはまりません。WordPress本体にも、この形式を途中で切り替える処理はありません。
対処は、10月21日の緩和策の1つ目と同じです。修正版が出るまで、session.upload_progress.enabled を 0 にしておきます。
10月21日の時点でこの設定をしていれば、追加の作業は要りません。先ほどの例えで言えば、割れた窓に打ち付けた板は、次の修理が済むまで外さずに残しておきましょう。
共用のレンタルサーバーでは、この設定を利用者が変えられるか、サーバー会社が対応しているかは会社によって違います。新しい告知が出ていないか、契約しているサーバー会社のお知らせを確認してください。
定例の更新が出たら、10月21日の修正版のときと同じように、末尾の数字まで確かめて更新しましょう。
保守を任せている場合は対応状況を文面で確認する
制作会社や保守会社に任せている場合は、CVE番号（10月21日の2件と10月23日の1件）を伝え、対応が済んだか、まだならいつ済むかを文面で確認しておきましょう。
前の章で触れた「責任範囲の確認」や「月次点検レポート」が、こうした緊急時に役立ちます。
詳しい内容は、PHP公式のセキュリティ告知（英語）と、10月23日の追加の告知（英語）で確認できます。
お勧めのセキュリティ系プラグイン
ここまで紹介した対策の多くは、専用のセキュリティプラグインを導入することで手間をかけずに実現できます。自社の運用体制に合わせて選ぶ際の参考にしてください。
CloudSecure WP Security(Xserver)
Xserverが提供するプラグインで、ログイン試行回数の制限や管理画面への不正アクセス検知など、本記事で挙げた対策の多くをまとめて設定できます。Xserverのレンタルサーバーを利用している場合は親和性が高く、導入のハードルが低い点が特徴です。
SiteGuard WP Plugin
国内の開発元が提供する定番プラグインで、ログインページのURL変更や画像認証の追加など、不正ログイン対策に特化した機能が揃っています。管理画面が日本語で分かりやすいため、IT専任者がいない体制でも扱いやすいプラグインです。
All In One WP Security & Firewall
ログイン保護に加えて、ファイアウォール機能やファイルの改ざん検知など、サイト全体を幅広くカバーするプラグインです。機能が多い分、最初はすべてを有効にせず、優先度の高い設定から段階的に取り入れることをおすすめします。
いずれのプラグインも、本記事で紹介した「更新」「ログイン」「バックアップ」という3つの基本対策を補強する位置づけです。プラグイン任せにせず、まずは本体の対策を固めたうえで導入を検討しましょう。
