PHP の重大な脆弱性に修正版が公開。サイト運営者が確認したいこと【2026年10月22日更新】
– PHP 公式の修正版公開情報・CERT-EU・EU 共同声明の確認日時: 2026年10月22日8時51分 (日本時間)
– PHP Foundation の経緯説明の確認日時: 2026年10月22日0時7分 (日本時間)
– IPA の情報確認日時: 2026年10月22日8時49分 (日本時間)
この記事は、10月20日の事前告知を受けて作成し、10月21日の修正版公開を受けて更新しました。10月22日には、PHP Foundation が公表した経緯に加え、EU 関係機関の共同声明と CERT-EU の更新を反映し、今必要な対応を先に確認できる構成に改訂しました。過去の確認内容は末尾の変更記録に残しています。
現在の対応状況
PHP の重大な脆弱性2件に対応する修正版が公開されました。PHP 公式は直ちに更新するよう強く呼びかけています。 インターネットに公開しているシステムを優先し、サイトで実際に使っている PHP に修正が適用されたかを、更新担当者に確認してください。
| 利用している系列 | 今回の修正版 |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
対象の脆弱性は CVE-2026-109618 と CVE-2026-109619 です。CVE 番号は、それぞれの脆弱性を区別するための識別番号です。事前告知では、深刻度はいずれも CVSS v4.0 で9.2とされていました。
公開予定は日本時間10月21日23時でしたが、今回の調査では22時56分に公式ページ上の公開を確認しました。この時刻は確認時刻であり、正確なリリース時刻を示すものではありません。
PHP の脆弱性とは、何の問題なのか
PHP は、サーバー側でプログラムを動かし、Web ページを作るために使われる言語です。サイトを見る人のパソコンではなく、サイトを動かす側の環境に関わる話です。
脆弱性とは、悪用されると安全性を損なうおそれがある、ソフトウェアの弱点です。ただし、弱点があると分かっただけでは、どのサイトで、どんな被害が起こり得るかまでは決まりません。利用しているバージョンや設定などの条件を照らし合わせる必要があります。
今回公式に確認されたのは、ログインしていない攻撃者にも、離れた場所からサーバー上で不正なプログラムを実行されるおそれがある問題です。これを「認証不要のリモートコード実行」と呼びます。影響する環境で実行の危険があることと、個別のサイトですでに被害が起きたことは、分けて判断する必要があります。
「深刻度9.2」はどう受け止めればよいか
CVSS は、ソフトウェアの脆弱性の深刻さを共通の基準で表す仕組みです。0から10の範囲で評価し、9.0以上は「Critical」に分類されます。今回の9.2は、この最も深刻な区分に入ります。
ただし、9.2という数字は「自分のサイトが92%の確率で攻撃される」という意味ではありません。対応を優先する判断材料にしつつ、自分の環境では修正が適用されたかを確認する必要があります。
Web サイトを動かす PHP が確認の対象
PHP 公式は、Web からのリクエストを処理するすべての PHP 環境をリスクの対象に挙げています。PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が含まれます。これらは PHP の動かし方の違いです。自分で判別できなければ、環境を管理する担当者に確認してください。
特に mod_php は、サイト側のプログラムが動き始める前に攻撃が成立する実証があり、公式は最もリスクが高いとしています。「サイト側のプログラムでチェックすればよい」と判断せず、PHP 自体の修正を確認する必要があります。
PHP 8.1以前を使っている場合
PHP 8.1以前は、PHP プロジェクトの通常の更新対象ではありません。OS などの提供元が古い系列に修正を取り込んで提供する場合があるため、提供元への確認、またはサポート中の系列への移行が必要です。
今回、PHP セキュリティチームは例外的に、7.4、8.0、8.1向けの最小限の修正コードも提供しています。ただし、これは自分で PHP を構築する担当者などを支援するもので、古い系列の通常サポート再開とは区別してください。
設定変更だけで対応を終えない
PHP 公式は、更新だけが完全な解決策だとしています。 更新できない間に特定の攻撃経路への露出を減らす設定も示していますが、それだけで環境が安全になるとはしていません。
設定の変更は、サイトの機能やサーバーの動作に影響するため、技術担当者が公式の暫定措置とその限界を確認したうえで判断してください。この記事では、一般の運営者がそのまま貼り付ける設定例としては掲載しません。
サイト運営者が今確認したいこと
利用環境の把握から、更新と動作確認までを担当者と共有しましょう。
PHP を使っているサイトやプログラムを洗い出す
IPA は、開発・運用しているプログラムのうち、PHP を使っているものを可能な範囲で洗い出すよう呼びかけています。担当するサイトが複数ある場合は、サイトごとに利用状況と更新担当者を整理しておくと、対応漏れの確認に役立ちます。
また、PHP はソフトウェア製品やネットワーク機器の内部で使われる場合もあります。PHP の利用が分かっている製品については、提供元のセキュリティ情報も確認してください。ただし、IPA は、すべての製品について内部での PHP 利用の有無を個別に調べるよう求めているわけではありません。利用状況が不明な製品は、提供元の案内を引き続き確認する形です。
利用中の PHP と、更新担当者を確認する
サーバーの管理画面で、対象サイトが利用している PHP のバージョンを確認してください。分からなければ、サーバー会社や保守担当者へ確認を依頼しましょう。
WordPress では、管理画面の「ツール」→「サイトヘルス」→「情報」から、サーバーに関する情報を確認できます。表示内容の確認が難しい場合は、サーバー会社の案内と合わせて担当者に見てもらうとよいでしょう。
そのうえで、PHP の更新はサーバー会社が行うのか、自分で切り替えるのか、保守担当者が作業するのかを整理します。サーバー会社の対応は、各社の公式案内で確認してください。
更新と動作確認を進める
修正版への更新にあたり、バックアップの取得と復元方法、作業後の確認項目を担当者と共有しておきましょう。
トップページだけでなく、お問い合わせフォーム、ログイン、予約や購入など、サイトで大切な操作を確認項目に入れておくと役立ちます。
更新による不具合を避ける準備は必要ですが、それを理由に対応を先延ばしにしないよう、確認作業を誰が行うかまで決めておきたいところです。
制作・保守担当者が確認したいこと
欧州連合の機関などを対象にサイバーセキュリティ対応を担う CERT-EU は、更新した勧告で、影響する PHP 環境を速やかに修正版へ更新することを強く推奨しています。
さらに、すぐに修正を適用できない場合は、インターネットに公開しているアプリケーションを、修正を適用してその結果を確認できるまで、外部のネットワークから隔離することも検討するよう勧めています。これは、外部からアクセスできない状態にするという考え方です。サイトや業務を利用できなくなる影響もあるため、公開を続けるか、一時的にアクセスを制限するかは、運営責任者と技術担当者で検討してください。 ここでは、個別環境に有効な具体的設定や、すべてのサイトの一律停止を指示するものとしては扱いません。
PHP の正式な告知と変更履歴を確認し、管理している環境の修正適用状況を調べます。そのうえで、サーバー会社や利用している OS の提供元から、修正を含む更新が提供されているかを確認してください。
更新を適用したあとは、実際にサイトで使われている PHP に修正が反映されたことと、主要な機能の動作を確認します。今回への対応が完了したかどうかは、更新作業を実行したという記録だけでなく、適用結果まで含めて判断する形にしましょう。
EU 関係機関も、外部公開システムを優先した更新を呼びかけ
2026年10月21日付で、欧州委員会、EU のサイバーセキュリティ機関 ENISA、CERT-EU、欧州刑事警察機構のサイバー犯罪対策部門 Europol EC3、EU 各国の対応チームのネットワークが共同声明を発表しました。
声明は、PHP を使うアプリケーションを把握し、サービス提供者と調整して修正版を適用するよう求めています。インターネットからアクセスできるシステムを優先し、すぐに更新できない場合は、修正まで外部からアクセスできない状態にすることも検討するという案内です。
また、見た目では PHP を使っていないように見える製品でも、内部で利用している場合があると指摘しています。製品への影響を調べる参考先として、オランダのサイバーセキュリティ機関 NCSC-NL が公開する情報一覧も案内しています。個別製品の判断では、利用中の製品とバージョンを確認し、その提供元の案内を照合することが大切です。
実証コードの流通と、実際の攻撃被害は分けて考える
CERT-EU は10月21日付で勧告を v1.1 に更新し、修正版や影響範囲を掲載しました。あわせて、技術的な詳細が公開の場で議論され、攻撃が成立することを試す実証コードが流通し始めたため、攻撃者がすでに悪用している可能性が高まっていると評価しています。
この評価は、特定の攻撃被害を確認したという報告とは異なります。 一方で、「被害の確認を待ってから更新する」という判断を支える情報でもありません。Foundation が述べた「公開時点では動作する攻撃コードを確認しなかった」という説明も、その時点での調査結果です。現在の更新判断には、公開後の情報も合わせて使う必要があります。
IPA も修正版公開に向けた事前準備を呼びかけ
2026年10月21日、IPA (独立行政法人情報処理推進機構) も、「【事前準備のお願い】PHPのセキュリティリリース公開予定について」を公開しました。
IPA は、修正版の公開後に速やかに適用できるよう、事前準備を呼びかけています。この案内は修正版公開前のものです。現在は、PHP 公式が公開した修正版への対応を進める段階になっています。
また、IPA は、この情報の発信時点で、対象の2件の脆弱性を悪用した攻撃を確認しているわけではないと説明しています。この案内は、修正版公開後の対応に備えるための予防的な情報発信です。 この説明を、あらゆる場所で攻撃が発生していないという意味には広げずに受け止めてください。
修正版公開までに何があったのか
PHP の開発を支援する PHP Foundation は、2026年10月21日付の記事で、問題の発見から修正までの経緯と、セキュリティ対応の改善方針を説明しています。以下は、その当事者による説明に基づく整理です。他組織の行動についても、Foundation が公表した説明として記載します。
最初の兆候は2024年。修正が進まなかった理由も説明
2024年、Foundation はドイツの Sovereign Tech Agency の資金を確保し、OSTIF を通じて Quarkslab による外部のセキュリティ監査を実施しました。監査で報告された問題を修正する過程で、Foundation と契約する PHP コア開発者が、今回の1件目につながるメモリ不足時の問題の兆候を見つけました。
ただし、当時は悪用の可能性が理論上指摘された段階で、具体的な攻撃経路は見つかっていなかったと説明しています。
修正案は複数ありましたが、既存のプログラムが動かなくなる、サービスを停止させる別の問題を生む、多くの拡張機能にも変更が必要になる、といった難しさがありました。全員の合意を重視する意思決定と、PHP の内部を深く理解する開発者の不足も重なり、修正作業は何か月も停滞と再開を繰り返したとしています。
Foundation は、この遅れを意思決定の仕組みと資源不足による「構造的な失敗」と認めています。 2024年の時点ですでに今回と同じ具体的な攻撃が実証されていた、という説明ではありません。
2026年8月、具体的な攻撃の報告で最優先の修正に
Foundation の説明による主な流れは次のとおりです。ここに挙げる日付は同記事の表記に従っています。
| 時期 | 公表された経緯 |
|---|---|
| 2026年5月 | Ecosystem Security Team を設け、既存の PHP セキュリティチームと報告の整理・調整・安全性の強化を進める体制を整備 |
| 7月・9月 | 報告対応や修正を支える Alexandre Daubois、堅牢化を担う Daniel Scherzer が順次参加 |
| 7月30日 | Patch the Planet プログラムを通じ、Calif が PHP の監査を開始 |
| 8月11日 | Calif の Ryan A が、2024年のメモリ不足問題と同じ根本原因によるリモートコード実行を報告。OpenAI も同日に独立して同じ根本原因を報告 |
| 8月24日・9月18日 | Wiz、OpenAI がそれぞれ追加の攻撃経路を報告 |
これらの報告によって影響の大きさが明確になり、8月11日以降は、Foundation のセキュリティ担当者にとって最優先の修正になったとしています。その後は Trail of Bits による監査も行われていると説明しています。
今回の2件は、メモリの管理やエラー処理という、多くのリクエストが通る PHP の中心部分に関わります。Foundation は、この位置づけが深刻さの理由であると同時に、互換性や性能、拡張機能への影響を抑えながら修正する難しさにもつながったと説明しています。
なぜ公開予定が1日前倒しになったのか
脆弱性の情報は、開発元だけでなく OS などの配布元とも調整し、修正を利用者へ届けられる状態にしてから公表する予定でした。こうした公開までの情報共有には、合意した時刻まで詳細を公開しない取り決めがあります。
ところが、Foundation によれば、予定の2日前からその調整が崩れました。以下の時刻は記事内の UTC 表記を日本時間に換算しています。
| 日本時間 | Foundation が説明する出来事 |
|---|---|
| 10月21日0時頃 | CVE 番号2件が掲示板や SNS で出回り始める。公開時刻と深刻度10.0という情報は誤りで、この段階では技術的詳細の流出はなかったと説明 |
| 同日4時30分 | PHP 側が事前告知を前倒しで公開。修正版の予定も、10月22日23時から10月21日23時へ1日前倒し |
| 同日5時頃 | 報告元の Calif が実証動画を誤って公開したと説明。削除後も複製が出回り、限定的な追加情報が明らかになったとする |
| 同日8時頃 | 一部の重要インフラ提供者に案内し始めた緩和策についても、流出した可能性があると説明 |
| 同日16時41分 | Chainguard が、合意した公開時刻より6時間以上前に、修正を含む構築済みイメージを公開したと説明 |
すぐに修正版を一般公開しなかったのは、配布元が更新用のパッケージを準備している途中だったためだとしています。即時公開では、多くの利用者が簡単に更新できない状態になるため、迅速な対応、準備時間、更新手段の確保を両立させる判断として、1日前倒しを選んだという説明です。
Foundation は、Calif の動画が攻撃の実証コードの開発を加速させ、10月21日にその流通が増えたとしています。また、修正を含むイメージの先行公開により、ほかの利用者が更新を待つ間に、攻撃者が修正内容を解析できる状態になったと指摘しています。これらは Foundation 側の説明であり、各組織の見解を比較して結論づけたものではありません。
「公開時点で動く攻撃コードを確認していない」の意味
Foundation によれば、PHP セキュリティチームは流出後に現れた実証コードを監視・調査しましたが、修正版の公開・情報開示時点では、動作する攻撃コードを確認しなかったとしています。
これは、研究者による攻撃の実証がなかったという意味ではありません。同記事は、1件目について mod_php の既定設定と PHP-FPM のアプリケーション内の処理経路でリモートコード実行を確認したこと、2件目についても報告者が mod_php 上の実在するアプリケーションで実証したことを説明しています。
また、公開時点の調査結果から、現在も悪用されないとは判断できません。修正版の適用を進める必要性は変わりません。
PHP のセキュリティ体制は、どう変わるのか
Foundation は、修正案が難しい判断で止まった場合に、より早く指導部へ相談し、解決へ進められる仕組みを優先するとしています。セキュリティチームでも、多数決で判断できるようにし、必要な折り合いをつけて前に進むための手順変更を始めたと説明しています。改善は継続中であり、すべて完了したという報告ではありません。
報告の増加への対応も課題です。同記事によれば、チームは7月1日以降に15件の CVE を公表し、無効・重複・再現不能だった100件超の報告にも対応しました。これは今回の2件だけの件数ではなく、期間中の報告対応全体の話です。
調査では Anthropic の Claude Mythos、報告や攻撃実証の検証では OpenAI の Daybreak Red などの AI ツールを使い、メモリの不正な扱いを検出する仕組みや、対応プラットフォームに合わせた再現環境も整えているとしています。ただし、個々の判断と修正作業には、必ず人が関わると説明しています。
問題を見つける道具が進歩しても、長年の設計をどう直すか、既存機能への影響をどう抑えるか、修正内容が適切かを判断するには、経験のある技術者が必要です。Foundation は、その人材を増やし、少人数の担当者とボランティアに依存する体制を支えるため、PHP を利用する企業や公共機関などに継続的な資金支援を呼びかけています。
この背景を知ることは、修正版の適用に加えて、PHP の安全性を継続的に支える体制にも目を向ける材料になります。
判断が難しいときは、情報をそろえて相談する
自分で確認する範囲は、利用中の PHP、サーバー会社の告知、更新担当者、バックアップの状況までを目安にするとよいでしょう。
PHP のバージョンが分からない、更新する人が決まっていない、古いサイトで更新後の動作に不安がある場合は、サーバー会社や制作・保守担当者へ相談してください。相談時に、サイト URL、サーバー会社名、分かる範囲の PHP のバージョン、保守契約の有無を用意すると、状況を共有しやすくなります。
WordPress サイトについて、どこから確認すればよいか整理できない場合は、オレインデザインのお問い合わせフォームからご相談ください。利用環境や管理体制を伺い、サーバー会社への確認が必要な点も含めて、対応の進め方を整理します。
参照した一次情報
- ENISA: Joint statement on critical PHP vulnerabilities (2026年10月21日)
- PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security (2026年10月21日)
- PHP: Security advisory: Critical remote code execution vulnerabilities, update now
- PHP: Upcoming Critical PHP Security Release (2026年10月20日)
- IPA: 【事前準備のお願い】PHPのセキュリティリリース公開予定について (2026年10月21日)
- CERT-EU: Critical Vulnerabilities in PHP (Security Advisory 2026-018)
- PHP 公式サイト
- PHP: Supported Versions
- FIRST: CVSS v4.0 Specification Document
- WordPress.org: Site Health screen
- PHP: PHP 8 ChangeLog
時系列での変更点・追記
以下は、この記事を変更した記録です。サービス側の発表日時や作業日時とは区別して記載します。時刻はすべて日本時間です。
2026年10月21日14時19分時点の情報: 初稿作成
PHP 公式の事前告知をもとに、修正版の公開予定と、公開前にサイト運営者が確認できることを整理しました。影響するバージョンや修正済みバージョンは、告知では未公表です。
2026年10月21日21時12分: IPA の注意喚起を追記
IPA が同日、修正版の公開に向けた事前準備を呼びかける情報を公開したことを本文に追記しました。IPA の情報発信時点における攻撃の確認状況と、予防的な情報発信であることも併記しています。この時刻は記事への追記時刻であり、IPA の公開時刻ではありません。
2026年10月21日21時19分時点の再調査: IPA・CERT-EU の推奨対応を追記
PHP 公式サイトの表示では、引き続き修正版の事前告知を確認しました。IPA の本文を取得して、PHP を使うプログラムの洗い出しと、製品内部での利用について確認する範囲を追記しました。また、CERT-EU 自身が示す、すぐに修正できない場合の一時的な隔離の検討を追加しました。
2026年10月21日22時56分時点の確認: 修正版公開を反映
PHP 公式で8.5.12、8.4.27、8.3.36、8.2.35の公開を確認しました。事前告知段階の説明を更新し、認証不要のリモートコード実行の危険、Web リクエストを処理する環境への影響、古い系列の対応、設定変更だけでは完全な対策にならないことを追記しました。読者への案内も、公開を待つ準備から修正の適用確認へ変更しています。
2026年10月22日0時7分時点の確認: 発見・修正・公開調整の背景を追記
PHP Foundation の説明をもとに、2024年の兆候発見、修正が停滞した構造的な要因、2026年8月以降の優先対応、情報流出と公開前倒しの経緯を追加しました。あわせて、公開時点の攻撃コード確認状況の意味と、意思決定・人員・検証環境・資金面の改善方針を追記しました。背景の時系列と記事の編集履歴は分けて記載しています。
2026年10月22日8時51分時点の確認: EU 共同声明と CERT-EU v1.1 を反映した改訂版
EU 関係機関の共同声明を追加し、外部公開システムを優先する対応と、製品内部の PHP 利用への注意を記載しました。CERT-EU v1.1 の実証コード流通に関する評価を、被害確認と区別して追記しています。本文は、修正版と必要な対応、公的機関の動き、公開までの背景、相談先の順に再構成しました。過去の経緯と変更記録は残しています。
PHP 公式の修正版は、今回確認したページでは引き続き8.5.12、8.4.27、8.3.36、8.2.35でした。IPA の本文に実質的な更新は確認できず、Foundation の本文変更も用語・句読点の調整で、背景説明の結論は変えていません。各資料の発表・更新日時と、この記事で確認した日時は区別しています。
