2026年10月21日の夜、PHPに重大な脆弱性が公表されました
2026年10月21日の夜、ホームページを動かしている「PHP」というプログラムに、外から1回の通信を送るだけでサーバーを乗っ取られかねない脆弱性が2件公表されました（CVE-2026-109618／CVE-2026-109619、通称 php2shell）。WordPressで作られたホームページは、ほぼすべてPHPの上で動いています。
僕はハンズバリュー株式会社の代表で、ITコーディネータとして中小企業のホームページの制作と保守をしています。当社では、保守をお預かりしているお客様のホームページ約100件を、その夜のうちにすべて「メンテナンス中」の表示に切り替え、10月23日までに順番に元へ戻しました。
この記事は、その3日間に何をして、何がうまくいき、何を反省しているかの記録です。ご自分でホームページを管理している方が「うちは何を確かめればいいのか」を判断する材料になればと思って書いています。保守をお預けいただいているお客様への正式なご報告は、【ご報告】PHPの脆弱性に伴う緊急メンテナンスの対応と結果についてに掲載しています。
先に結論を書きます。
- 当社が管理するサーバーを点検した範囲では、改ざんや不審なファイルは見つかっていません
- 当社が管理するホームページのメンテナンス表示は、10月23日にすべて解除しました
- 一方で、予告なしにホームページを止めたことで、お客様にご心配とご迷惑をおかけしました。この点は当社の反省です
何が危なかったのか
公表された内容を、専門用語をできるだけ使わずにまとめます。
- PHPがリクエスト（ホームページへのアクセス）を処理している途中で、後片付けの手順に穴があった
- そこを突くと、外部から送り込んだ命令をサーバー上で実行させられる（遠隔コード実行）
- 深刻度の評価は 10点満点で 9.2
- 直った版は PHP 8.2.35／8.3.36／8.4.27／8.5.12。それより古い 7.4・8.0・8.1 には公式の修正が出ない
ここで多くの方が誤解しやすい点があります。「PHP 8に上げた」ことは、今回の修正ではありません。修正が入っているのは上の4つの版だけで、PHP 8.3でも 8.3.35 以前なら穴は開いたままです。
3日間に起きたこと
10月21日（昼〜夕方）公表の予告を受けて、できる準備をする
昼前に、夜に重大な脆弱性が公表されるという報道が出ました。この時点では中身が分かりません。当社の制作部は「中身が出るまで待つだけでなく、上げられるサイトは今日のうちにPHP 8へ上げる」と判断し、夕方までにレンタルサーバー上のお客様サイトを次々と切り替えていきました。古いPHPのままだと、修正が出たときに当てる先がないからです。
ところが夕方、大手のレンタルサーバー会社が、利用者用の管理画面を予防のために止めました。管理画面に入れないと、PHPの版を切り替えることができません。ここで、上げられずに古い版のまま残るサイトが出ました。
10月21日（夜）「止める」と決める
夜に公表された内容を読み、制作部の担当者と相談して、PHP 8に上げただけでは危険と判断しました。修正版がサーバーに当たるまでは、外からPHPに届く道そのものを閉じるしかありません。大手のサイトの多くも同じ対応を取っていました。
その夜のうちに、次のことをしました。
- 保守契約のお客様の連絡先（67件）へ「緊急メンテナンスのお知らせ」をメールでお送りした
- 各サーバーのホームページの入口に、「メンテナンス中（503）」を返す設定を入れた。作業の前に、元の設定ファイルを全部控えとして保存した
- 当社が自社で運用しているサーバー（AIチャットや分析ツールが動いているもの）も、外からの接続を一晩止めた
作業の途中で、監視の名簿に載っていないホームページがあることにも気づきました。名簿は「当社が見守っているサイト」の一覧であって、「サーバー上でPHPが動いている場所」の一覧ではなかったのです。そこで、当社が入れるサーバーの中身をすべて洗い出し、古い複製サイトなども含めて止めました。
10月22日（朝）直ったことを確かめてから開ける
朝、まず改ざんがないかを確かめました。当社が入れる全サーバーで、前日の昼以降に書き換わったファイルを洗い出し、すべてが当社の作業の跡か、プラグイン更新の跡であることを確かめています。
当社が自社で運用しているサーバーについては、10月24日にアクセスの記録とログインの記録も読み直しました。PHPが異常終了した跡や、見覚えのないログインの跡は見つかっていません。ただし、送られてきた通信の中身までは記録に残らないため、「攻撃が一度も来なかった」とまでは言えません。分かることと分からないことを分けて、お伝えしておきます。
次に、サーバー会社が修正版を本当に当てたかを、告知だけでなくサーバーの中身で確かめました。各版のPHPが作り直された日時を見て、修正版に置き換わっていることを確認したものから、順番にメンテナンス表示を外していきました。当社の自社サーバーも、OSの配布元が出した修正版を当て、朝7時半に接続を戻しています。
解除の作業は、制作部の担当者がサーバーごとに指示を出し、当社のAI（Claude Code）が前夜の控えから設定を戻し、担当者が1件ずつ画面を目で確かめる、という分担で進めました。前夜のうちに「全部記録を取り、元に戻せる形で作業する」ことを決めていたので、約100件を半日で巻き戻せました。
午後には、古いPHP 7.4についてもレンタルサーバー会社から修正の発表がありました。
10月23日 すべて解除、復旧のお知らせ
個別の調整が必要だった最後の数件（テーマの修正が要るサイト、サーバーのエラーを直す必要があったサイト）も、この日のうちに解除しました。夜、21日に緊急メンテナンスをお知らせしたのと同じ67件へ、対策の完了と復旧のお知らせをお送りしました。
御社のWordPress、いま動いているPHPの版をご存じですか？
GA4・Search Console・セキュリティの3視点から、現状を無料で診断します。ITコーディネータが1〜2枚のレポートにまとめてご報告します。
ご自分でホームページを管理している方へ：確かめてほしい3つのこと
1. PHPの版を「番号の最後まで」見る
WordPressの管理画面の「ツール → サイトヘルス → 情報 → サーバー」で、PHPの版が見られます。8.2.35／8.3.36／8.4.27／8.5.12 以上なら、今回の修正が入っています。「8.3」とだけ見て安心しないでください。
2. 7.4・8.0・8.1のままなら、サーバー会社の告知を確かめる
この3つには公式の修正がありません。レンタルサーバー会社が独自に修正を当てている場合もありますが、その場合でも版の番号は変わりません。サイトヘルスの表示では見分けられないので、ご利用のサーバー会社の告知で確かめる必要があります。そのうえで、できるだけ早くPHP 8.3以上へ移ることをおすすめします。WordPressのプラグインも、PHP 8でしか動かないものが増えています。
3. 「表示されている」は「直っている」の証拠にならない
レンタルサーバーによっては、トップページを一時保存（キャッシュ）して表示しています。PHPを止めていても、トップページだけは古い画面が出ることがあります。当社も解除作業の途中、トップページで確かめて「開いている」と誤って報告し、ログイン画面で測り直して訂正しました。確かめるときは、トップページ以外のページで見てください。
当社の反省
対応を終えて、社内で反省点を3つにまとめました。
事前のメンテナンスの案内は出す。対応する人の負担が大きすぎる。
手動の更新は廃止。自動化が望ましい。プラグインの導入で解決を図る。
ガーディアン（監視システム）のメールや登録は正確にする。今回のように対応するときに楽になる。
予告なしに止めたこと
今回は、夜に公表された内容を見て、その夜のうちに止めました。止めたこと自体は正しかったと考えていますが、お客様にとっては、ある朝突然ホームページが「メンテナンス中」になっていたことになります。前日の夜に「作業が完了しました」とご連絡したお客様には、その数時間後に止めるご連絡をすることにもなりました。翌朝、複数のお客様からお問い合わせをいただき、「障害のときは、メールよりまず電話で知らせてほしい」というお叱りもいただきました。もっともなご指摘です。
今後、同じ規模の警告が出たときは、公表を待つ前の段階で「メンテナンスのお時間をいただく可能性があります」とお知らせします。急ぎのときの連絡は、メールだけでなくお電話でも行います。
手で入力していた情報が、肝心なときに古かったこと
当社の監視システム（つなぐWPガーディアン）では、各サイトのPHPの版を担当者が手で入力する運用にしていました。事故の2日前に切り替えたばかりで、当日の値は事故前のままでした。「8.3.36になっているサイトから開ける」と決めても、その判定に使えなかったのです。手で入力する欄は、更新されなければ必ず古くなります。PHPの版はサイトから自動で取得する形に戻します。
連絡先の名簿が正確でなかったこと
緊急のお知らせを一斉にお送りした際、連絡先が登録されていなかったり、普段お使いでないアドレスだったりして、届かなかったお客様がいました。名簿は、平時に正しておかなければ緊急時に使えません。全件を見直します。
名簿ではなく、実物を見る
3日間を通して一番の学びは、記録や名簿ではなく、実物を見て確かめることでした。
- 対象のサイトは、監視の名簿ではなくサーバーの中身から洗い出す
- 修正が当たったかは、告知ではなくサーバー上のPHPで確かめる
- 開いたかどうかは、トップページではなくPHPを通るページで確かめる
当社はこの3日間の作業を、どのサーバーで何をいつ変えたかまで、すべて記録に残しています。その記録があったから、一晩で止めたものを半日で元に戻せました。保守の仕事は、普段は何も起きないことが成果です。何かが起きたときに「止める」「確かめる」「戻す」を速く正確にできるかどうかで、保守の値打ちが決まると、あらためて感じています。
保守をお預けいただいているお客様には、ご心配とご不便をおかけしました。あらためてお詫び申し上げます。そして、夜を徹して対応した制作部のメンバーと、翌日のお問い合わせに丁寧に対応してくれた社員にも、この場を借りて感謝を伝えます。
関連記事
- 【ご報告】PHPの脆弱性に伴う緊急メンテナンスの対応と結果について
- 【重要】PHPの脆弱性に伴うホームページ緊急メンテナンスについて（10月22日のお知らせ）
- WordPress保守の費用相場と「見えない保守」の問題
- つなぐWPガーディアン（WordPressの見守りサービス）
「作って終わり」のホームページ、変えませんか？
守る・知る・書く・話す — 4つのAIが、御社のホームページを24時間働く営業担当に変えます。まずは無料のHP診断レポートで現状を把握するところから。