PHPの脆弱性で、保守の現場は何をしたか。版を上げる前に知っておきたいこと

こんにちは、株式会社ソライルの波多野です。

10月21日に公表されたPHPの脆弱性について、まず確かめることは「PHPの脆弱性（2026年10月）WordPressで確かめること・しなくていいこと」にまとめました。

この記事では、WordPressの保守を仕事にしている立場からの見解を書きます。

今回いちばんお伝えしたいのは、次のことです。

PHPの更新は、日頃からやっておいたほうがいい。

PHPの脆弱性は、今回始まった話ではありません。これまでも何度も見つかり、そのたびに修正版が出てきました。発表があってから慌てて動くのではなく、常に日頃から、PHPの版を確かめて上げておくことが大事だと考えています。

保守先のサイトを、翌朝に一斉に確かめた

PHPの修正版が出たのは、日本時間の21日22時半ごろでした。
翌22日の朝、お問い合わせを待たずに、保守でお預かりしているサイトのPHPの版を一斉に確かめました。台帳をもとに、次の3つに分けています。

• 修正済みの版で動いているサイト（サーバー会社の案内から、修正済みと見込んでいるものを含む）
• 修正済みの版への切り替えが必要なサイト（PHP 8.1や7.4系で動いているもの）
• PHP 5.6のままで、切り替えが大きな作業になるサイト（個別にご相談）

サーバー会社のメンテナンス中で、確認を待っているサイトもあります。結果は、お客様ごとに順にお知らせしています。

版の確認には、サーバー会社の管理画面ではなく、WordPressの「サイトヘルス」を使いました。管理画面を止めているサーバー会社があったためです。サイトヘルスなら、実際に動いている版の番号が読めます。

PHPの発表では、mod_phpという方式のほうが攻撃が成り立ちやすいとされています。ただ、保守先のサイトの多くが使っているPHP-FPMという方式でも、条件によっては外からプログラムを動かせることが確かめられています（PHPのセキュリティチームの告知）。方式ではなく、直った版になっているかで判断しました。

公開が早まった理由と、攻撃の今

今回の問題の根っこは、2024年に行われたPHPの外部監査のころから、開発側に気づかれていました。直し方が決まらないまま時間がたち、2026年8月に複数の研究者が攻撃の方法を報告して、修正が急がれました。PHP財団は、遅れを「構造的な失敗」と認めています（PHP財団のブログ、10月21日）。

公開の直前には、識別番号が予定より早くネットに出回り、PHPは公開を1日早めました。続いて攻撃の実演動画も出回り、予告から修正版まではおよそ18時間しかありませんでした。サーバー会社の多くが修正版を待たずに予防の作業に入ったのは、この流れの中でのことです。

攻撃の状況は、22日午前の時点で次のとおりです。

• 公的機関は、悪用を確認していません。アメリカのCISAの悪用が確認された脆弱性の一覧には載っておらず、IPAの事前の注意喚起も、悪用した攻撃は確認していないと書いています
• PHP財団は、公開の時点で、出回った実証コードの中に動く攻撃コードは見つからなかったとしています
• セキュリティ会社の見方は分かれています。攻撃の試みを観測したと発表した会社（watchTowr、Patchstackなど）がある一方、観測していないとする会社（Huntress、Sophos）もあります。観測したとする側も、件数や被害の中身は示していません

私の見方は、まだ大丈夫でも、もう攻撃されているでもありません。攻撃の試みは始まっていると考えて、直すのを急ぐ段階です。

サーバー会社の対応の違いを、どう読むか

サーバー会社の対応は、速さも中身も知らせ方も違いました。22日の午前から正午にかけて、各社の公式の案内で確かめた内容を並べます。

• エックスサーバー：21日16時から、公式サイトや管理画面、Webメールなどを予防的に止め、サイトの表示やメールソフトでの送受信は通常どおりとした。22日6時45分の時点で8.2〜8.5への修正の適用を終え、古い版は確認が済んだものから順に適用
• さくらのレンタルサーバ：21日夜から22日朝に更新作業を行い、コントロールパネルで選べるすべての版で対応を完了。利用者が行う緊急の対応はないとしつつ、サポート期間中の最新版への移行の検討を勧めている
• カラフルボックス：8.2〜8.5の更新に加え、7.4・8.0・8.1などの古い版にもサーバー側で修正と保護措置を当て、どの版でも「そのまま安全にご利用いただけます」と案内
• KAGOYA：マネージド専用・共用・WordPress専用サーバーのプランは恒久的な対応を調整中で、暫定的なリスク低減策として、サイトの公開停止（メンテナンス画面への切り替え）やアクセス制限の検討を利用者に呼びかけている（22日10時35分更新）
• ロリポップ：修正版の公開に先立ち、予防措置として緊急メンテナンスを実施。22日12時に確認した告知では、ロリポップ！レンタルサーバーの「現在利用できません」に「お客様のサイト」が入っていた

違いは、何を守るために、どこを止めたかにあります。
サイトのPHPを直す、会社側の仕組みを止める、利用者に作業をお願いする。どこまでを会社の側で引き受けるか、線の引き方が違ったのだと受け取っています。

サイトをお持ちの方にとって大事なのは、ご契約の会社がどの線を引いたかを知っておくことです。
管理画面が止まれば、その間はPHPの切り替えもできません。保守の現場でも、切り替えは管理画面の再開を待ちました。何が止まり、何を待てばよいかが分かっていれば、次に同じことが起きても慌てずに済みます。

古い版のまま置かれたサイトが、いちばん危ない

PHPの公式の修正版が出たのは、サポート中の8.2〜8.5だけです。サポートが終わった7.4・8.0・8.1向けには、PHPの開発チームが「サポート終了版向けの最小限の緩和」として、ソースの修正を出しています。

修正の大きさも違います。テストを含めた追加は、8.3向けの修正が1万行あまり、8.1向けの修正が約300行でした。単純に比べられるものではありませんが、守られる範囲が同じとは言い切れません。

サーバー会社が古い版に独自の修正を当てても、PHPの版の番号は変わりません。保守先の実測でも、8.1系は22日の時点で8.1.34と表示されていました。どの修正をどこまで当てたかを、利用者の側からは確かめられないのです。

次に何かが見つかったとき、古い版向けの修正がまた出る保証もありません。PHP財団によると、7月1日以降に公表した脆弱性は15件で、AIを使った調査の広がりから報告が急増しています。

WordPress.orgの統計では、PHP 8.1以前で動いているWordPressのサイトは、合わせて約36%あります（10月22日時点）。8.2も、2026年12月31日でセキュリティ修正が終わります。
古い版のまま置かれているサイトほど、直ったかどうかを確かめられない状態になります。いちばん危ないと考えるのは、そのためです。

「最新の版」より「直っていて、問題なく動く版」

では、どの版に上げればよいか。私は、いちばん新しい版がいつも正解だとは考えていません。
選ぶのは、修正済みで、そのサイトのテーマやプラグインが問題なく動く版です。WordPressの公式は8.3以上を勧めているので、その中から、サイトに合う版を選びます。

PHPの版を上げて不具合が起きやすいのは、古いテーマやプラグインが、新しいPHPで使えなくなった書き方を残している場合です。たとえばPHP 8.0では、クラスと同じ名前の関数を初期化の処理として扱う古い書き方が使えなくなりました（PHPの移行ガイド）。

保守先でも、7.4で動いていたあるサイトのテーマに、8.0で使えなくなった書き方が6か所ありました。切り替えの前に、テーマのほうを直します。ネットショップは、表示と決済を段階を分けて確かめます。PHP 5.6のままのサイトはWordPress本体も古いため、本体、テーマとプラグイン、PHPの順に進める大きな作業になります。

私がこれまでのキャリアで保守やPHPの更新に携わってきたサイトは、100件を超えます。版を上げるとき、現場でいちばん気をつけているのは、次のことです。

PHPの版を上げることで、サイトが見られなくなってしまうことがあります。そういうことが起きないように、版を上げるなら、サイトのほうも新しい版に対応した書き方にしておく必要があります。テーマやプラグインのコードを、新しいPHPに合わせて直しておく、ということです。そこまで含めて、問題なく進めることを大事にしています。

そのうえで、作業は次の備えをしてから始めます。

• 切り替える前に、サイト全体のバックアップを取る
• 切り替えたあと、トップページ、主なページ、お問い合わせフォーム、管理画面、ネットショップなら決済までを順に確かめる
• 問題が出たときに元の版へ戻す手順を、先に決めておく

PHPの版は、多くのレンタルサーバーで管理画面から元に戻せます。WordPress 5.2以降は、重大なエラーが起きても管理者にメールが届き、原因のプラグインやテーマを止めて管理画面に入れる仕組みもあります（WordPressの開発者向けの案内）。
備えがあれば、版を上げるのは怖い作業ではありません。

任せていると、何が違ったか

今回、保守をお任せいただいている会社には、ご自分で調べていただく必要がありませんでした。

保守先のサイトを半日で一斉に確かめられたのは、ふだんから台帳と毎月の確認の記録があったからです。どのサイトがどのサーバーの、どの版で動いているかが分かっていれば、脆弱性の発表があっても、確かめる先で迷いません。

私がお届けしたいのは、作業そのものより、Webのことを自分で考え続けなくても大丈夫だという安心です。
PHPの更新は、今回で終わりではありません。8.2の修正も年末で終わり、次の発表もいずれ来ます。

ご自分のサイトのPHPの版を見て迷ったときや、切り替えから動作の確認までを任せたいときは、「PHPの脆弱性への対応」のページをご覧ください。確かめるだけのご相談でも構いません。

よくある質問

Q. 今回の脆弱性を使った攻撃は、もう起きていますか？

A. 10月22日午前の時点で、公的機関は悪用を確認していません。
一方で、攻撃の試みを観測したと発表したセキュリティ会社もあり、見方は分かれています。安心とも危険とも言い切れないため、直った版にすることを急ぐ段階だと考えています。

Q. サーバー会社が、古い版も直したと案内しています。そのまま使い続けてよいですか？

A. 当面は案内のとおりで構いませんが、8.3以上への切り替えを計画しておくことをおすすめします。
古い版は修正後も番号が変わらないため、どこまで直ったかを利用者の側から確かめられません。次に脆弱性が見つかったとき、古い版向けの修正が出る保証もありません。

Q. PHPの版は、いちばん新しいものに上げればよいですか？

A. 新しい版がいつも正解とは限りません。
修正済みで、サイトのテーマやプラグインが問題なく動く版を選びます。バックアップを取り、切り替えたあとに表示やフォームを確かめ、問題があれば元の版に戻せるようにしてから進めます。