PHPのセキュリティチームは2026年10月20日、重大な脆弱性2件に対処する修正版を、翌21日14時UTC(日本時間23時)に公開すると予告した。深刻度はいずれもCVSS v4.0で9.2とされ、利用可能になり次第更新できるよう、全PHPユーザーに準備を呼びかけている。日本のIPAも事前の棚卸しを求めており、対象は自社のウェブアプリに加えて、PHPを内包するソフトウェア製品やネットワーク機器にも及ぶ。公開を待つ間に確認したいのは、PHPをどこで使い、誰がどの経路で更新するかだ。

AD

2件とも9.2、詳細と影響版は公開時に発表

PHPの公式告知が明らかにしたのは、2件とも深刻度がCriticalで、CVSS v4.0のスコアが9.2という点だ。脆弱性の詳細、影響を受けるバージョン、修正版の番号は、リリースと同時に公表する方針である。

つまり、事前告知の段階では、手元の構成が影響を受けるかを公式の一覧で照合することはできない。告知には対象の機能やOS、攻撃成立に必要な設定も記されていないため、スコアだけから全構成で攻撃が成立すると結論づけるのは早計だ。

公開予定時刻にも留保がある。いずれかの脆弱性の詳細が公になった場合や、実際の悪用を示す証拠が現れた場合には、予定を前倒しする可能性をPHPチームは示した。23時まで待ってから準備を始めるのでは、前倒しに対応しにくくなる。

ただし、前倒しの条件を示したこと自体は、攻撃発生の確認を意味しない。IPAの注意喚起も「本情報の対象となる2つの脆弱性について、現時点でIPAが悪用した攻撃を確認しているわけではありません。」と明記する。予防的な準備の要請と、実際の被害報告は分けて受け止める必要がある。

設定変更だけで攻撃を防げるのか

CERT-EUは、対象をCVE-2026-109618とCVE-2026-109619として注意喚起を公開した。認証なしで任意コード実行につながる可能性や、PHP 5以降に影響する可能性を挙げている。任意コード実行とは、離れた攻撃者がサーバー上で自分のコードを動かすことを指す。

もっとも、CERT-EUは流出情報を含む複数の情報源に基づいて評価しており、PHP公式の事前告知はCVE番号やその広い影響範囲まで示していない。「PHP 5以降」という情報は警戒対象を考える材料にはなるが、公式に確定した影響バージョン一覧とは区別すべきだ。

国内では、GMO Flatt Securityが独自調査を踏まえた対応指針を公表している。同社は、独自調査で確認した問題と「php2shell」と呼ばれる今回の脆弱性が一致する限り、ファイルのアップロード進捗をセッションに記録する機能が関係するとみる。ただし、今回の開示調整には関与していないという。

注意したいのは、その後の追記だ。10月21日14時(日本時間)の更新で同社は、session.upload_progress.enabledの設定変更だけでは緩和にとどまり、攻撃自体は回避できない見込みだとした。初期に紹介された機能の無効化だけで対応済みと判断するのは危うい。同社の判断では、根本的にはパッチが必要となる。

また、同社は脆弱性を悪用できると主張するコードがインターネット上に出回り始めたと指摘する。コードの流通は準備を急ぐ理由になる一方、それだけで本番環境への攻撃が確認されたことにはならない。技術情報の流出、攻撃の実行可能性、現実の攻撃観測は、それぞれ異なる情報である。

AD

PHPを内包する製品とホスティングも確認する

PHPの更新準備は、自社で管理する実行環境、PHPを内包する製品、ホスティング事業者が管理する環境で、確認先を分けて進める必要がある。

IPAは、PHPがソフトウェア製品やネットワーク機器の内部で使われ、利用者には把握できない場合があると説明する。英国のNCSCの推奨事項にも、PHPを内包する機器やサービスを含め、第三者ベンダーの更新情報を継続して確認するよう記載がある。サイトの運営者が自ら更新できるPHPと、製品やサービスの提供元を通じて更新するPHPでは、準備の窓口が変わる。

両機関の推奨事項と、KAGOYAが10月21日18時20分(日本時間)に更新した対応案内を、更新を管理する主体に着目して分けると、確認事項は次のようになる。

PHPを使う環境 公開前に確認すること 根拠となる案内
自社で管理する実行環境 PHP利用の棚卸しと更新手順。インターネットに公開したシステムを優先する IPAの概要・推奨対応、NCSCの推奨事項
PHPを内包する製品・機器 マニュアルや提供元のセキュリティ情報、修正プログラムの案内 IPAの概要、NCSCの第三者ベンダーに関する推奨事項
事業者が管理するホスティング 契約プランとPHP系統ごとの対応方針、更新予定 KAGOYAのプラン別案内

この表は同日の公開前情報を管理主体別に分類したもので、環境ごとの危険度や修正完了を比較したものではない。製品とホスティングのように分類が重なる場合もあり、すべての提供形態を網羅しているわけではない。

KAGOYAの例では、レンタルサーバープランのPHP 8.2系、8.3系、8.4系、8.5系について、公開予定の修正版を確認した後、順次アップデートする予定だ。一方、マネージド専用サーバーや共用サーバー、WordPress専用サーバーの各プランなどは、対応方針を調整中としている。同じ事業者を使っていても、契約プランまで確認しなければ更新の見通しは分からない。

これはKAGOYAの予定であり、他社の対応や更新完了を示す情報ではない。また、IPAは、内部でのPHP利用が不明なものを含め、すべての製品について個別確認するよう求めているわけではないと補足する。まず把握できている利用箇所と公開情報から確認し、提供元の続報を追うのが同機関の案内だ。

修正版の公開から適用・動作確認へ

公開後は、PHPチームが示す影響バージョンと修正版を、自組織で把握した利用環境に照らし合わせる段階へ移る。製品やサービスに組み込まれたPHPなら、IPAが促すように開発元・提供元の情報も確認する必要がある。PHP本体の公開予定と、利用中の製品に修正が届く時点は、別々に確かめたい。

Flatt Securityは、更新手順に加え、その後のアプリの動作検証手順も事前に確認するよう勧めている。停止を伴う場合の連絡フローを確かめ、サーバー内のデータや権限を必要な範囲に抑えることも準備項目に挙げた。ログが記録され、改ざんを受けにくい形で保全されているかも確認対象となる。

直ちに更新できない場合、CERT-EUはインターネットに公開したアプリを公開ネットワークから隔離することの検討を勧め、NCSCも十分に緩和できるまでシステムをオフラインにする選択肢を示す。設定を一つ変えれば安全になるとの前提で運用を続けるのではなく、更新までの公開継続を判断するための助言である。

21日23時の予定を目安に、PHP公式の影響版・修正版と、利用先の提供元が示す対応を確認する。その情報を実際の更新と動作確認につなげられるよう、公開前に担当者と手順をそろえておくことが求められる。