結論：WordPressのサイトに関わる緊急の脆弱性が出た日は、「対象かを確かめる→更新する（できなければ一時対策）→入られていないかを確かめる→戻せるかを確かめる→記録して連絡する」の5段で動きます。直す対象はWordPress本体とプラグインだけではありません。2026年10月のPHPの緊急の脆弱性（PHP2Shell）のように、その下で動くPHPやサーバーが対象になることもあります。
- 最初の30分：公式の告知を読み、自社のサイトのWordPress・プラグイン・PHP・サーバーのどこが対象かを確かめます。
- その日のうち：自分で直せるものは更新し、事業者が直すもの（レンタルサーバーのPHPなど）は事業者の告知を確かめて、それまでの一時対策を決めます。
- 落ち着いたら：入られていないか、バックアップから戻せるかを確かめ、やったことを時刻つきで記録します。
対象読者：WordPressで会社のサイトを運営している経営者・Web担当者、サイトの保守を外部に任せている会社の担当者
読了後にできること：次に緊急の脆弱性が出た日に、迷わず順番に動けるようになります。
最終更新：2026年10月22日（JST）
2026年10月21日の夜、PHPの緊急の脆弱性とNode.jsのセキュリティ更新が同じ日に重なりました。私たちも、自社で運用しているWordPressのサイトを1台ずつ確かめ、自社で管理するサーバーには修正を当て、レンタルサーバーの上のサイトには更新が届くまでの一時対策を入れました。
その夜に一番時間を使ったのは、実は修正そのものではなく、「どのサイトがどこで動いていて、誰が直すのか」を確かめることでした。WordPressの画面からは同じように見えるサイトでも、PHPを自分で上げられるサーバーと、事業者が上げるのを待つしかないサーバーでは、その日にやることが変わります。
この記事では、その夜の対応で分かったことをもとに、緊急の脆弱性が出た日の初動を5つの段に分けて整理します。個別の脆弱性の詳しい対応は、PHPの緊急脆弱性（CVE-2026-109618）｜対象と今やることとNode.jsの脆弱性（2026年10月）｜22・24・26系の更新と今やることにまとめています。
緊急の脆弱性の知らせは、どこから来るか
脆弱性の知らせは、SNSやまとめ記事から先に流れてくることが多いですが、動く前に必ず公式の情報で確かめます。見るべき場所は次のとおりです。
| どこ | 何が分かるか |
|---|---|
| 開発元の公式の告知（php.net・nodejs.org・WordPress.org など） | 対象の版、修正版、深刻度、公式の一時対策 |
| IPA・JPCERT/CC の注意喚起 | 日本での注意の呼びかけ、悪用の確認の有無 |
| レンタルサーバー・保守会社のお知らせ | 事業者側で更新する部分の予定と完了 |
| Cloudflare などの前段のサービスの告知 | 自動で入る防御のルールの有無 |
今回のPHPの件では、PHPの開発チームが前もって公開の日時を予告し、IPAも公開前に「事前準備のお願い」を出しました。予告が出た時点で棚卸しを始めておくと、公開の当日にあわてずに済みます。
自社のサイトが対象かを確かめる
WordPressのサイトは、いくつかの層の上で動いています。層ごとに「誰が直すのか」と「どこで確かめるのか」が違います。
| 層 | 誰が直すか | どこで確かめるか |
|---|---|---|
| WordPress本体 | 自社（マイナーな更新は既定で自動） | 管理画面の「ダッシュボード」→「更新」 |
| プラグイン・テーマ | 自社（自動更新は個別に設定した場合） | 管理画面の「プラグイン」「外観」→「テーマ」 |
| PHP | レンタルサーバーなら事業者、VPSなら自社 | 「ツール」→「サイトヘルス」→「情報」→「サーバー」 |
| サーバーのOS・Webサーバー | レンタルサーバーなら事業者、VPSなら自社 | 事業者のお知らせ／サーバーのパッケージの版 |
| 前段（Cloudflareなど） | 自社の設定＋サービスの自動の防御 | サービスの管理画面と告知 |
WordPressの公式の説明では、既存のサイトでも、本体のマイナーな更新（保守とセキュリティの更新）は既定で自動で入ります。一方、プラグインとテーマは、特別な場合を除いて既定では自動で更新されません。「本体は勝手に直るから大丈夫」と思っていると、プラグインやPHPが置き去りになります。
更新する：自分で直すものと、事業者が直すもの
対象が分かったら、自分で直せるものから更新します。
- 更新の前に控えを取る：VPSならスナップショット、レンタルサーバーなら事業者のバックアップ機能か、ファイルとデータベースの書き出しを取ります。
- 自分で直せるものを更新する：WordPress本体・プラグイン・テーマ、VPSならOSのパッケージ（PHPを含む）を更新し、PHPのプロセスを再起動します。
- 前と同じに動くかを確かめる：主なページとお問い合わせの送信を、更新の前と後で比べます。私たちは、主なページの応答（表示できたか、転送されたか）を更新の前後で比べてから作業を終えました。
- 事業者が直すものは、告知を確かめて待つ：レンタルサーバーのPHPなどは、自分では上げられないことが多いです。事業者のお知らせで、影響の有無と更新の予定・完了を確かめます。
更新までの一時対策を決める
事業者の更新を待つ間や、すぐに更新できない間は、被害の入口を減らす一時対策を入れます。ただし、一時対策は「完全な対策」ではありません。公式の告知に一時対策が載っていれば、まずそれに従います。
- 前段の防御を確かめる：今回のPHPの件では、Cloudflareが公開の約9時間前から、無料プランを含めWAFを使っている利用者に自動の防御ルールを入れたと公表しています。前段のサービスを使っているなら、防御が有効かを確かめます。ただし、サーバーのIPアドレスへ直接届く経路が残っていると、前段の防御は抜けられます。
- 使っていない入口を閉じる：使っていないプラグインは止める、ファイルの送信を受けないフォームは止める、など。今回のPHPの件では、.htaccess でファイルの送信の形式（multipart）を止める方法がありました。その間はお問い合わせフォームも止まるので、電話やメールの窓口をサイトに出しておきます。
- 外すのを忘れない：更新が入ったら、一時対策を外して元の動きに戻します。外し忘れたフォームが何週間も止まっていた、ということが起きないように、入れた日時と外す条件を記録しておきます。
入られていないかを確かめる
更新したからといって、それより前に入られていないとは限りません。とくに、公開の前に情報が漏れていた場合や、悪用が報告されている場合は、次の点を確かめます。
- 画像などのアップロード用のフォルダ（wp-content/uploads）に、拡張子が .php のファイルが無いか。
- 最近変わった .php のファイルのうち、本体・テーマ・プラグインの更新で説明できないものが無いか。
- 知らない管理者ユーザーや、知らない定期実行（WordPressの予約イベントとサーバーのcron）が増えていないか。
- PHPのプロセスの異常終了がエラーログで急に増えていないか、外への不審な通信が無いか。
私たちの点検では、自分たちが対応のために足した定期実行の変更を、点検の仕組みが「入られた兆候」として拾ってしまう場面がありました。対応中に足した設定は記録しておき、兆候と取り違えないようにしてください。本当に兆候が見つかったら、サイトをメンテナンス表示に切り替え、ログを消さずに保存してから、事業者や専門家に相談します。
この記事の内容を社内で使うなら
要点と手順をまとめた資料を無料で受け取れます。研修6,000名以上・支援100社以上の実績をもとに、自社の業務に当てはめる相談も30分から受け付けています。
戻せるかを確かめる
乗っ取りの被害で一番困るのは、「どこまで戻せばよいか分からない」「戻す先が無い」状態です。次の点を、緊急の日に限らず定期的に確かめておきます。
- ファイルとデータベースの両方のバックアップがあるか。
- バックアップがサーバーの外にもあるか（同じサーバーの中だけだと、乗っ取られた時に一緒に消されたり書き換えられたりします）。
- 何日前の時点まで戻せるか、実際に戻す手順を一度試したことがあるか。
- 戻した後に替えるもの（管理者のパスワード、データベースのパスワード、wp-config.php の認証用キー、サイトに置いたAPIキー）が分かっているか。
記録して、社内とお客さまに伝える
最後に、やったことを時刻つきで記録します。どのサイトに、いつ、何の版を当て、何を確かめたか。一時対策をいつ入れて、どの条件で外すか。記録があると、あとで「あの夜どこまでやったか」を聞かれた時にすぐ答えられ、次の緊急の日の手順書にもなります。
サイトの保守を外部に任せている会社は、保守会社に「影響の有無」「更新の予定と完了」「自社でやることがあるか」の3点を聞いておくと安心です。逆に、お客さまのサイトを預かっている会社は、同じ3点を先にお伝えしておくと、問い合わせが落ち着きます。
2026年10月の例：PHPとNode.jsが同じ日に更新された
2026年10月21日は、PHPの緊急の脆弱性（CVE-2026-109618／109619）と、Node.jsのセキュリティ更新が同じ日に出ました。違いを並べると、急ぐ順番の考え方が分かります。
| 項目 | PHP（PHP2Shell） | Node.js |
|---|---|---|
| 関わるもの | WordPressなど、PHPで動く公開サイト | Node.jsで動くWebサービス・社内ツール・MCPサーバー |
| 深刻度 | 緊急（CVSS v4.0 で9.2） | 高 |
| 修正版 | 8.5.12・8.4.27・8.3.36・8.2.35 | 26.12.1・24.22.1・22.23.4 |
| レンタルサーバーの場合 | 事業者の更新待ち＋一時対策 | 多くは関係しない（Node.jsを自分で動かしている場合だけ） |
WordPressの公開サイトを持っている会社は、まずPHPから。Node.jsで動くサービスがある会社は、同じ日のうちにNode.jsも。この順番で、上の5段を回します。
よくある質問
Q. WordPressの自動更新を有効にしていれば、何もしなくてよいですか？
A. いいえ。自動で入るのは主に本体のマイナーな更新と翻訳で、プラグインとテーマは既定では自動で更新されません。さらに、PHPやサーバーの脆弱性は、WordPressの自動更新では直りません。
Q. レンタルサーバーを使っています。自分でできることはありますか？
A. 事業者の告知で影響と更新の予定を確かめること、WordPress本体とプラグインを最新にすること、使っていないプラグインやフォームを止めること、バックアップを取ることはできます。脆弱性によっては、.htaccess で入口を絞る一時対策が取れる場合もあります。
Q. 保守会社に任せています。何を聞けばよいですか？
A. 「影響の有無」「更新の予定と完了」「自社でやることがあるか」の3点です。あわせて、バックアップがサーバーの外にあるかも確かめておくと安心です。
Q. 夜中に脆弱性が公開されたら、朝まで待ってもよいですか？
A. 深刻度が「緊急」で、悪用が報告されている場合は、待たずに動く価値があります。今回のPHPの件では、Cloudflareが公開前の漏えいと攻撃の通信を観測したと公表していました。公開の日時が予告されている場合は、その時間に動けるよう前もって準備しておきます。
まとめ：緊急の日の5段
- 公式の告知で、自社のサイトのどの層（本体・プラグイン・PHP・サーバー・前段）が対象かを確かめる。
- 自分で直せるものは控えを取ってから更新し、事業者が直すものは告知を確かめて待つ。
- 更新までの一時対策を入れ、外す条件を決める。
- 入られていないか、戻せるかを確かめる。
- やったことを時刻つきで記録し、社内・保守会社・お客さまに伝える。
自社のシステム全体にどんな穴がありうるかを一通り点検したい方は、事例集と自社点検シートをまとめた「AIエージェント時代のサイバー攻撃 事例集と自社点検シート」も使ってください。中小企業の守り方の全体像は、AIサイバー攻撃とは｜中小企業の防御5手でも整理しています。
参考・出典
- Upgrading WordPress（自動更新の既定の動き） — WordPress.org（参照日：2026-10-22）
- PHP: Security advisory: Critical remote code execution vulnerabilities, update now — php.net（参照日：2026-10-22）
- Wednesday, October 21, 2026 Security Releases — The Node.js Project（参照日：2026-10-22）
- 【事前準備のお願い】PHPのセキュリティリリース公開予定について — IPA（公開日：2026-10-21・参照日：2026-10-22）
- Cloudflare deploys protections against php2shell vulnerability — Cloudflare（2026-10-21・参照日：2026-10-22）
この記事の内容を社内展開する方へ: 部門別 AIエージェント活用マップ 50選（無料・PDF 32ページ＋Excel） をダウンロードできます。
