修正版の公開を前もって告知し、「すぐ適用できるよう準備してほしい」と呼びかける。この形で出てくる更新は、影響の大きさを示しています。WordPressやEC-CUBEをはじめ、国内のWebサイトの多くはPHPで動いています。自社のサイトが対象かどうかを待つ前に、「自社サイトのPHPを誰が更新するのか」を今日中にはっきりさせておく必要があります。

何が起きたか

PHPのセキュリティチームは10月20日(協定世界時)、2件の重大な脆弱性(いずれもCVSS v4.0で9.2)を修正するセキュリティリリースを、協定世界時10月21日14時(日本時間同日23時)に公開すると事前に告知し、全利用者に公開後すぐ更新できるよう準備を求めました。脆弱性の内容、影響を受けるバージョン、修正版のバージョンは公開と同時に明らかにするとしており、詳細が外部に漏れた場合や悪用の兆候が見つかった場合は予定を早める可能性があるとしています。EUの機関向けCERTであるCERT-EUは、2件にCVE-2026-109618とCVE-2026-109619が割り当てられていること、CVSSの値から遠隔からのコード実行につながる可能性があること、外部の情報では古い版を含む広い範囲に影響する懸念があることを挙げ、PHPで動くアプリケーションの洗い出しと即時適用の準備を推奨しています(php.net、ITmedia NEWS)。

なぜ自社に関係があるのか

  • *「うちはPHPを使っていない」と言える会社は多くありません。**サーバー側の言語が分かるWebサイトのうち約7割がPHPで動いているとされます。WordPressで作ったコーポレートサイト、EC-CUBEのECサイト、問い合わせフォーム、社内のグループウェアやWiki。自社で意識していなくても、どこかでPHPが動いている可能性が高いと考えてください。
  • *問題は、誰が更新するかです。**共用のレンタルサーバーなら、PHPの更新は事業者が行います。VPSやクラウドで自社が管理しているサーバーなら、自社か保守会社の仕事です。制作会社に作ってもらったまま保守契約がないサイトは、誰も更新しないまま残ります。今回の告知が求めているのは、この「誰が」を公開前にはっきりさせることです。
  • *古い版で動くサイトは、別の問題を抱えています。**現在サポートされているのは8.2から8.5の系統で、8.1以前は通常の修正の提供が終わっています。公開後に対象の版が示されたとき、古い版で動いているサイトには修正が来ない可能性があります。その場合は「修正を当てる」ではなく、版を上げる作業になり、動作確認の時間が要ります。
  • *事前告知は、攻撃側への合図でもあります。**公開された修正の内容から攻撃の方法が作られるまでの時間は、年々短くなっています。先日の月例更新の記事で書いたとおり、更新を数か月まとめて当てる運用では間に合いません。公開から適用までの時間を、どれだけ短くできるかが問われます。

明日やること

  • 今日中に、PHPで動いているサイトとシステムを一覧にし、それぞれの「PHPの版」と「更新する人(事業者、保守会社、自社)」を書き出す。分からないものは、保守先に今日問い合わせる。公開資産の棚卸しの一部として残す
  • 自社で管理するサーバーは、バックアップ、動作確認の手順、再起動の時間帯を今夜の公開に合わせて準備する。公開後は、自分の版が対象かを確認してから適用する
  • すぐに適用できないサイトは、適用までの間、WAFのルール更新や外部からの公開範囲の一時的な制限を検討する。8.1以前の版で動くサイトは、今回を機に版を上げる計画を立てる

もっと知るには

「9.2」という数字を自社の優先順位に読み替える方法はCVEとCVSSとはで解説しています。修正を当てるまでの時間を稼ぐ仕組みはWAFとは、PHPで動くECサイトのプラグインの管理はEC-CUBEの公式Amazon Payプラグインの記事をご覧ください。

出典

PHP緊急セキュリティリリースWordPress脆弱性対応Webサイト運用