AIが特定したPHPの深刻な脆弱性：各国サイトの緊急停止とOpenAIによる修正協調の全貌

ITmediaの報道によると、10月21日夜、日本の高市早苗首相がXで緊急の呼びかけを行い、ウェブサイト運営者に対してPHPのセキュリティパッチを至急適用する準備を求めました。迅速な更新が困難な場合には、サイトを一時停止することもリスク軽減策の一つとして挙げられています。

リスクの本質は、悪用条件を満たす稼働環境において、攻撃者がログイン不要で細工したネットワークリクエストを送るだけで、サーバープロセス内の機密情報を読み取ったり、PHPやWebサービスプロセスに悪意ある処理を実行させたりできる点にあります。問題が生じたのは、数多くのサイトが共通して依存しているPHPのコアエンジンです。このエンジンはサーバー上でウェブページを組み立て、ユーザーから送信されたデータを処理するため、上位のサイトコードに不備がなくても影響を受ける可能性があります。攻撃によって生じる被害の規模は、稼働環境やサービスプロセスの実行権限、隔離措置にも左右されます。

今回の緊急対応は、行政機関や公共サービス、日頃利用されている商用サイトにまで波及しました。ロイターのまとめによると、オランダ国家サイバーセキュリティセンター、ロッテルダム港、フィンランド政府の公共Webサービスなどが予防的な停止措置を講じ、ドイツ連邦ITサービスプロバイダー（ITZBund）も複数のウェブサイトを停止しました。日本の財務省も一部のウェブページやサービスを休止し、ITmediaの報道によればBASE、pixiv、Cygamesなどの関連オンラインサービスもメンテナンス対象として挙げられました。これらは当時の停止やメンテナンスの記録であり、その後に復旧したサービスも含まれるため、すべてが実際に侵害されたと推測することはできません。

影響はこれらのサイトを支えるプラットフォーム側にも及びました。ウィキメディア財団は、百科事典本体の停止を回避しつつ、ToolforgeやCloud VPS内の関連サービスを含む、多くの支援サービスを予防的に一時停止しました。日本の複数のホスティング事業者も緊急パッチ適用に追われ、ユーザーのウェブサイトを停止して対処する事業者もあれば、管理画面のみを一時停止してユーザーサーバーの稼働を維持する事業者もありました。各事業者の対応方針の違いが、ユーザーがサイトを閲覧できるか、管理画面にログインできるか、あるいは復旧を待つ必要があるかを左右することになりました。

W3Techsの統計によると、サーバーサイド言語が識別可能なウェブサイトのうち約70%がPHPを採用しています。これは共通の依存関係が極めて広範に及んでいることを示しているのであり、同等の割合のサイトが実際に侵害されたことを意味するわけではありません。Redditの議論では、自身のブラウザ、メールクライアント、個人用クラウドストレージにも影響が及ぶのかと尋ねるユーザーも見られました。ここでは責任の所在を明確に整理しておく必要があります。各サイトのPHP更新は運営者やホスティング事業者がサーバー側で実施するものであり、一般の利用者は利用中サービスの公式発表やサービス復旧状況、事業者が求めるアカウント関連の事後対応に留意することが基本となります。

今回の一連の対応において、OpenAIはPatch the Planetプログラムを通じてメンテナーとサービス事業者の協調に参加し、影響を受けるバージョンの調査に役立つ確認ツールをオープンソースで公開しました。AIは研究者が複雑な攻撃経路を検証する支援を行いましたが、パッチによってウェブサイトが実際に保護されるまでには、サービス提供チェーン全体の連動が不可欠です。

脆弱性研究におけるAIの実際の役割分担：専門知識とモデルの補助

OpenAIの公式発表によると、Patch the Planetプログラムにおいて、セキュリティ企業のCalifがGPT-5.6 Solを活用して深刻な脆弱性を発見しました。またWizのチームも独自にこれら2件の脆弱性を発見して報告しており、最終的な修正とリリース作業はPHPメンテナーが主導しました。

脆弱性の背景を遡ると、根本的な火種は以前からまったくの手がかりなしだったわけではありません。The PHP Foundationの振り返り告知によれば、Sovereign Tech Agencyの助成を受けてQuarkslabチームが実施した監査において、メンテナーが関連課題を修正する過程でメモリ制限（OOM）経路に異常が存在すること自体は認識されていました。しかし当時は、その経路がリモートコード実行に転じ得るという確証はなく、コアのメモリ管理ロジックに手を加えることでサードパーティ拡張の互換性が損なわれる懸念もありました。合意形成に頼る従来の意思決定プロセスではトレードオフの選択が難しく、限られた人員の中での修正作業は先送りされてきた経緯があります。

今回の発見プロセスにおいて、モデルは分析支援と環境適応の役割を果たしました。Califの研究者Ryan Austinによる技術解説によれば、最初の発見には一般公開されているモデルが用いられ、数年前にStefan Esserが指摘した過去の脆弱性に対する個人の専門的理解を組み合わせ、リクエスト制限を回避して例外的な中断を引き起こす特定のパターンをコードベースから検索するようモデルを誘導したことがブレイクスルーとなりました。Austinは、ターゲットシステムのアーキテクチャの歴史を理解することは依然として代替不可能であり、現在のモデルは単純なプロンプトを与えるだけであらゆる脆弱性を自律的に見つけ出せるわけではないと指摘しています。

一方、Wizの研究実践では、社内プラットフォームのWiz AtlasとGemini 4 Argon、GPT-5.6 Solが組み合わされました。Wizはレポートの中で、従来チームで数か月を要していた作業を1名の研究者が1週間で完了させたと述べ、複数アプリケーションを横断する悪用手法の適応をモデルが数時間で支援したと説明しています。実際の作業では、PHPのバージョンやアプリケーションごとに異なるメモリ配置の差異に対し、モデルが実行時エラーの分析やエクスプロイトパラメータの調整を支援することで、環境ごとの個別検証に伴う人的コストを引き下げました。Hacker Newsの議論サンプルでは、投稿者asbv-1qqが公式アナウンスの宣伝トーンに疑問を呈し、公表されていないモデル検索やエクスプロイト開発の計算リソースコストについて問いかけています。効率化の報告を捉えるにあたっては、研究に要した時間だけでなく、それに伴う計算資源の消費規模にも目を向ける必要があります。

なお、OpenAIの発表で言及された10億ドル規模の支援は、第一線の防御者を対象とした既存の「Daybreak」プログラムにおけるモデル利用補助金であり、重要サービスの防御を担いながらもセキュリティ予算が限られている組織を支援するためのもので、今回の脆弱性のために緊急拠出された特別資金ではありません。OpenAIは、メンテナー支援策としてモデルアクセスの提供、直接的なエンジニアリング協力、Codex for OSSのサブスクリプション付与、Rust Foundation等のプロジェクトへの寄付などを挙げており、優先順位の決定は各プロジェクトに委ねられています。また発表では、悪用を防止するための分類フィルターが正当なセキュリティ研究を妨げる可能性にも触れられており、不正利用の防止と防御側への十分な能力提供との間で継続的なバランス調整が求められていると指摘されています。

リクエスト、強制中断、乱れたポインタ：2つのメモリエラーの成因と影響

PHPインタプリタがWebアクセスを処理する仕組みは、製造ラインの作業台に例えると理解しやすくなります。

常駐型のPHPプロセスを採用しているウェブサイトでは、PHPによる処理を必要とするページやフォームのリクエストが届くと、WebサーバーからPHPのWorkerプロセスへ引き渡されます。Workerは、そのリクエストのために確保された専用のヒープメモリ（作業台）上に部品を展開し、送信データの解析や内部変数インデックスの構築を行います。スクリプトの実行が完了すると、クリーンアップ処理によって作業台がクリアされ、待機中のWorkerは次のリクエスト処理へと移ります。

今回開示された2件の脆弱性は、作業台の上でデータが半分組み立てられた段階、および直前のリクエストの作業台が解放された直後に発生する異常な中断をそれぞれ悪用するものです。

CVE-2026-109618：メモリ上限超過による中断と初期化未完了データの誤用

PHP公式セキュリティアドバイザリおよびCERT-EUの技術勧告によると、この脆弱性のCVSSスコアは9.2と評価されています。PHP内部にはリソース枯渇を防ぐため、1リクエストあたりのメモリ使用量を制限する設定（memory_limit）が存在します。細工されたリクエストによってメモリ割り当てがこの上限値に達すると、コア機構がパーサーの実行を途中で強制中断します。

CERT-EUの分析によると、脆弱性の根本原因は、メモリ枯渇の例外によってリクエスト処理が強制中断された際、一部の内部データ構造が完全に初期化されていない状態にとどまる点にあります。その後に実行されるリクエスト終了処理が、この未完成のデータを誤って正常なオブジェクトと見なして解放処理を行ってしまい、メモリ状態の破壊を招きます。

CVE-2026-109619：リクエスト解放後に残存するダングリング状態の再利用

2件目の公式アドバイザリおよびCERT-EUの解説によると、CVE-2026-109619の根本原因は、複数のリクエストを跨いで残存する残留状態にあります。

致命的エラーによってリクエストが強制終了されると、そのリクエストが使用していた作業台のメモリは解放されます。しかし影響を受けるバージョンでは、エンジン内部の一部グローバル状態に、解放されたメモリ領域を指す参照が残存してしまいます。同一のWorkerプロセスが後続の新しいリクエストを処理する際、この状態がリセットされる前にダングリングポインタを誤用することで、すでに無効化されたメモリや新たなデータで上書きされた領域へのアクセスが発生します。

メモリエラーがもたらす影響

これらのメモリエラーが引き起こす影響は、主に以下の2つに大別されます：

1. 機密メモリの漏洩（Memory Disclosure）：無効化されたポインタや残留したメモリ参照が、エンジンによって正常データと誤認されて出力（レスポンスヘッダーやCookieへの反映など）された場合、攻撃者はコード実行権限を奪取することなく、プロセス内のメモリ断片を直接読み取ることが可能になります。このデータには、他のリクエストやサーバープロセス内に保持されているセッション情報、APIキー、パスワードなどの機密データが含まれる可能性があります。
2. リモートコード実行（RCE）：プログラムはユーザーデータを保持するだけでなく、内部のオブジェクト参照などを頼りに次にどのオブジェクトをどう処理するかを決定します。細工されたリクエストデータによってメモリ構造が改ざんされ、制御可能なデータが正規の内部構造として誤認されると、後続の処理フローが狂わされます。複雑なエクスプロイトチェーンを組み合わせることで、攻撃者は実行フローを掌握し、インジェクションした悪意あるロジックをインタプリタに実行させることが可能になります。攻撃者が取得できる権限はPHPやWebサービスプロセスが元々保持している権限の範囲内にとどまり、影響範囲はその実行ユーザーの権限やシステムの分離措置に依存します。

サイバーセキュリティ企業Wizの技術解説では、これら2種類のリスクの実証プロセスが示されています：

リクエストの中断、状態の残留、Workerプロセスの生存状況の関係性は、以下のプロセス図で確認できます：

mod_php と PHP-FPM：実行アーキテクチャが悪用経路に与える影響

PHP公式およびCERT-EUの勧告では、従来のApache mod_phpが最もリスクの高い構成形態であり、広く普及しているPHP-FPMでは悪用の前提条件が異なると指摘されています。

両者の差異の核心は、例外発生後にWorkerプロセスが生存して後続リクエストを処理し続けるかどうかにあります：

• Apache mod_php 構成では、PHPがApacheの子プロセス内部のモジュールとして動作します。公式アナウンスによると、デフォルト設定下において未認証のリクエストがアプリケーションコードの実行前に初期化段階のメモリエラーを誘発し、リモートコード実行を引き起こす実証が行われました。このモードでは初期化解析で異常中断が発生してもリクエストの終了処理が実行され、生き残った子プロセスが破損した状態を再利用し続ける可能性があります。ただしこれは特定の検証経路に基づくものであり、脆弱なmod_php環境のすべてが単一のリクエストで必ず侵害されることを意味するものではありません。
• PHP-FPM 構成では、独立したプロセスプールがWorkerを管理します。リクエストの初期段階で致命的エラーが発生した場合、FPMの機構により該当Workerプロセスは即座に終了するため、初期化時の状態残留に基づく悪用経路の一部が遮断されます。しかしリクエストが初期化段階を通過し、実処理段階（アプリケーション固有のデシリアライズやエラー処理ロジックなど）でメモリ中断が発生した場合、Workerは終了せず生存して次のリクエストを処理する可能性があります。研究者らはPHP-FPM環境においても、アプリケーション実行フェーズを通じたリモートコード実行経路が存在することを確認しています。

協調開示のプロセスと公表前後の対応

責任ある協調開示（Coordinated Disclosure）は、オープンソースのメンテナー、Linuxディストリビューション、インフラ事業者が防御措置の準備やパッチの検証を行うための猶予期間を確保することを目的としています。このプロセスは、関係者全員が秘密保持契約を交わしていることを意味するわけではなく、詳細が公表された瞬間にすべてのユーザーが円滑にアップグレードを完了できることを保証するものでもありません。

The PHP Foundationの経緯記録や業界メディアの報道によると、今回の協調開示は度重なる日程変更や突発事態に見舞われました：

1. 識別番号とスコアの流出：当初予定されていた公表日時の2日前、2つのCVE番号と「10.0」という深刻度スコア（実際の評価値は9.2）が技術フォーラムやSNS上で出回り始めました。ただしこの段階では具体的な技術的詳細は流出していませんでした。
2. リリース日の前倒し：外部からの注目が高まったことを受け、配布準備時間を考慮しつつ、PHPチームは事前告知を出し、正式パッチのリリースを1日前倒ししました。
3. 検証動画の誤公開：事前予告の公表後、脆弱性発見に携わったセキュリティ企業のCalifが検証用デモ動画を誤って公開しました。動画は速やかに削除されたものの第三者によって保存・拡散され、脆弱性の詳細の一部が明らかになりました。
4. コンテナイメージの先行公開：協調開示予定時刻の約6時間前、コンテナソリューションを提供するChainguardが修正を含むコンテナイメージをビルドして公開しました。
   • PHP Foundation側の見解：財団は振り返りの中で、修正済みバイナリが事前に公開されたことで攻撃者によるバイナリ差分解析が可能となり、関係各所の協調歩調が乱されたと指摘しています。
   • Chainguard側の回答：The Registerの報道によると、ChainguardのCEOはPoCの拡散と攻撃活動の報告を確認したことを受け、ユーザー保護を最優先としてパッチを前倒し提供することを決断し、公開と同時に協調グループへ通知したと説明しています。

攻撃の観測状況に関して、ロイターが引用したAmazonのセキュリティ責任者CJ Mosesの発言によると、脆弱性の公式公表の数日前から、自社のハニーポットにおいて匿名の探索パケットが検知されていました。セキュリティチームによる脆弱性の特定時期はそれよりも前であり、初期の探索が実際のサイト侵入に成功したかは確認されていないものの、正式な情報開示の前にネット上で試行的な攻撃が存在していたことが示唆されています。その後、Cloudflareの公式技術ブログでも、公表の前後を通じて攻撃トラフィックが観測され続け、シグネチャを回避しようとペイロードを次々に変化させる攻撃者の動向が確認されています。

5段階のグローバル協調と長期的なセキュリティ方針

インターネットのエコシステム全体にまたがる基盤ソフトウェアの脆弱性に対し、OpenAIのアナウンスでは、今回のPHPの件は同社が特定し修復に取り組んでいる複数の重大なセキュリティ懸念の一つにすぎないと説明されています。今後AI支援による脆弱性発見が大幅に増加することを見越し、再現可能で能力向上に伴い適用範囲を拡張できる協調対応メカニズムが必要であるとして、コードの修正から世界中のサイトへ実際の防御が行き渡るまでの「5段階のレスポンスプロセス」が提示されました：

1. 上流の脆弱性検証と修正：メンテナーと研究チームが原因を特定し、対策案を検証します。パッチ単体の有効性だけでなく、亜種や迂回手法を洗い出すための敵対的テストも実施します。
2. 主要防御側の準備期間の確保：各組織の防御責任、対応に必要な時間、機密情報の取り扱い能力に基づき、メンテナーが共有先を選定します。ディストリビューターは旧バージョンへのバックポートを行い、ホスティング事業者は緩和策をテストし、セキュリティベンダーはWAFルールの有効性を検証します。共有される情報は侵害指標（IoC）を含むネットワークログから実稼働可能な検証コードまで必要性に応じて制限されます。詳細の共有は脆弱性の手がかりを漏洩させるリスクを伴うため、適用範囲の拡大と機密保持の間で慎重な判断が行われます。
3. 政府機関と連携した重要システムの防護：各国のサイバーセキュリティ機関と連携し、重要インフラや公共部門へ防御ガイダンスを迅速に伝達します。
4. 下流製品の準備完了の推進：パッチの安定化に伴い、対象を一般の下流ベンダーやホスティングプラットフォームへ拡大し、展開可能な更新パッケージを準備して保護の空白を埋めます。
5. 公開ガイダンスの発行と実装支援：脆弱性情報とパッチを正式に公開し、運用担当者に向けてアップグレードの検証や緊急対応のガイダンスを継続的に提供します。

このチェーンにおいて各工程に時間を要するのは、十分な検証を経ずに拙速なパッチ配布を行えば広範な業務の互換性が損なわれるリスクがあるためです。この期間中に実環境での悪用の広がり、情報の意図せぬ漏洩、公開パッチの不備発覚、修正作業の難航によるリスク増加などが生じた場合、協調チームは開示スケジュールを再評価して必要に応じて変更することになります。

長期的な観点として、OpenAIの発表では4つの基礎的なセキュリティ進化の方向性が提案されています。第一に、開発の起点で安全なデフォルト設定を採用しハイリスクな実装パターンを避けること。第二に、重要コンポーネントをメモリ安全な言語へ移行し、よくある種類のメモリ安全性のエラーを根本から排除すること。第三に、形式検証を用いて、明示した前提のもとで重要コンポーネントが指定のセキュリティ特性を満たすことを数学的に証明すること。第四に、より厳格なサンドボックス隔離を導入し、信頼できないファイルやメディアを処理するソフトウェアを制限環境で実行することで、処理プログラムが侵害された場合でも被害を局所化することです。AIはコード理解の支援、移行コード案の生成、テストケース作成をサポートできますが、業務上の動作一致を担保するには専門家によるエンジニアリングテストとコードレビューが欠かせません。さらに発表では、政府やその他の運用者が所有するか、管理の権限を与えられているシステムにおいて、管理者としてのアクセス手段を失った極端な事態を想定し、一定の条件下と安全措置のもとで脆弱性を利用して緊急修正を行うべきかという問いかけもなされています。これは権限と安全性の境界に関して議論を要する構想です。

同時にThe PHP Foundationは、AIツールによって脆弱性報告の作成速度は飛躍的に高まったものの、チームは100件を超える無効・重複・再現不能なレポートの対応にも追われたと強調しています。報告の選別、パッチのアーキテクチャ上のトレードオフ、互換性のレビューは依然として経験豊富なコアメンテナーの手作業に頼っています。報告数が増加するにつれ、オープンソースプロジェクトにおける人的レビューやエンジニアリングリソースのボトルネックが深刻化しており、継続的な資金援助と人的投資こそが基盤ソフトウェアの安全を保つ礎となります。

公式パッチからサイトの安全まで：バージョンサポートと緩和策の限界

公式セキュリティパッチがリリースされた後も、下流でのパッケージング、ホスティング事業者による適用、そして外部向けに実際に稼働しているPHPが更新されたことの確認というステップを経る必要があります。Hacker Newsのユーザーspenvoは、イメージ提供を待った体験について、新しいバージョンのタグが登場しても、必要なアーキテクチャ向けの公式コンテナイメージがまだビルド完了していなかったと記しています。この当時の個人の体験談は、「上流でのリリース」と「自身の環境への配備完了」との間に存在するタイムラグを端的に示しています。

ホスティング事業者のメンテナンス方法によっても影響は異なります。IDCフロンティアのZenlogicの告知では、日本時間10月21日22時から22日18時にかけてPHPのアップグレードとパッチ適用が予定されていました。告知によると、作業中はApacheを停止するため、ユーザーのウェブサイトやRoundcubeウェブメールへアクセスできなくなりますが、メーラーによるメール送受信やFTPには影響しないとされていました。GMOペパボが運営するロリポップ！のメンテナンス告知でも、共用サーバーにおけるユーザーサイト、ユーザー専用ページ、FTP、旧ウェブメールなどの停止項目が掲示され、他プランの稼働状況については個別に説明されました。

エックスサーバーの告知では別のアプローチが取られました。自社公式サイトや管理パネルなどの機能を停止する一方で、ユーザーのホスティングサーバーの稼働を維持しながらパッチ適用を進行させました。10月22日、日本時間9時30分の進捗報告では管理機能が一部復旧したとされ、それに先立つ6時45分の報告では、PHP 8.2〜8.5の対象サーバーでパッチ適用が完了し、旧バージョンは別途対応中と発表されました。そのため「事業者のメンテナンス」という情報に接した際は、停止しているのが管理用インターフェースなのか、顧客が実際に利用しているWebサービスなのかを見極める必要があります。

管理権限の分散も復旧時間を長期化させる要因となります。ウィキメディア財団の説明によると、ToolforgeやCloud VPS内の一部のサービスはボランティア開発者によって運用されており、開発者自身がPHPバージョンを選択できる仕組みになっています。財団が各サービスの担当者に個別に連絡して協調修復を進める必要があるため、これらのサービスは復旧までに時間を要する場合があります。

1. サポート中バージョンとレガシー環境の差異

PHP公式は、現在サポート期間内にある4つのブランチに対して公式セキュリティリリースを発行しました：8.2.35、8.3.36、8.4.27、8.5.12。

ライフサイクルを終了（EOL）した旧バージョンに対しては、公式の定期セキュリティ保守は提供されません。ロイターが報じたCensysの調査データによると、PHPの稼働が確認・特定できた約260万台のホストサンプルのうち、約150万台がその時点では公式のビルド済み更新が用意されていない旧ブランチで稼働していました。コミュニティの初期の議論では、V2EXのフォーラムで開発者がPHP 7環境で稼働し続けているレガシーシステムに対する現実的な不安を吐露しています。公式の定期サポートは提供されないものの、対策が一切存在しないわけではありません。今回の深刻な脅威を受け、PHPセキュリティチームは自主コンパイルを行うユーザー向けに特例としてPHP 7.4、8.0、8.1を対象とした最小限のバックポートパッチを公開しました。また一部のLinuxディストリビューションやLTSベンダーも、サポート範囲に応じて保守パッケージを提供しています。しかし、継続的なメンテナンスが行われてこなかったレガシーシステムにおいて、メジャーバージョンを跨ぐアップグレードは文法の廃止、拡張モジュールの非互換、アプリケーション依存関係の破綻などを伴うため、短期間での迅速な適用は容易ではありません。

2. 一時的な緩和策の適用条件と限界

パッチの即時適用が困難な本番環境に対し、CERT-EUなどのセキュリティガイダンスでは暫定的な設定変更が提案されていますが、これらには厳格な前提条件が存在し、完全なアップグレードの代替にはなりません：

• アップロード進捗機能の無効化（session.upload_progress.enabled = 0）：この設定は、セッションのアップロード進捗機構を利用した既知の攻撃チェーンを遮断できますが、リクエストの解析前に設定が反映され、すべてのWorkerプロセスが再起動されている必要があります。また、他の悪用バリアントを網羅的に防ぐことはできません。
• 1リクエストあたりのメモリ上限の撤廃（memory_limit = -1）：この設定は単一リクエストのメモリ上限を撤廃することで、メモリ上限超過による例外中断とそれに続くクリーンアップ処理の誘発を回避しますが、可用性の保護を犠牲にするトレードオフとなります。単一リクエストの上限がなくなるとPHPレイヤーでの制限が失われるため、運用チームはシステムレイヤーのコンテナ制限やcgroupによるメモリ境界を設定し、マシン全体のリソース枯渇を防ぐ必要があります。この境界設定をRLIMIT_ASやRLIMIT_DATAで安易に代用することはできません。これらはプロセスレベルで低層のメモリ確保失敗を引き起こすためであり、物理メモリ枯渇によってシステムレベルの確保が失敗した場合、脆弱な例外クリーンアップ経路が依然として呼び出される恐れがあります。

本番環境の設定変更には専門的な評価とテストが求められます。暫定措置は特定経路の露出を減らすにとどまるため、根本的な解決にはPHP自体の更新が必要です。

バージョン確認ツールの位置づけと確認上の死角

情報開示と並行して、OpenAIは軽量なPHPバージョン確認ツール php2shell-checkerをオープンソースとして公開しました。このツールは主に単一URLまたはローカル環境のPHPバイナリを初期トリアージするためのものであり、インターネット全体や大規模アセットを自動スキャンする機能は備えていません。

ネットワーク検出の仕組みとして、デフォルトではHTTP HEAD リクエストのみを送信し、サーバーが405または501ステータスコードを返した場合にのみ GET へフォールバックします。ツールはHTTPリダイレクトを追跡せず、レスポンスボディの読み取りや解析も行いません。接続エラーが発生した場合、対象サーバーがバージョンヘッダーを公開していない場合、あるいは未収録のバージョンブランチに遭遇した場合は、いずれも UNKNOWN を返します。

旧バージョン、修正版、バージョン不明、あるいはベンダーのバックポートパッチが適用された環境など、取得できる情報に応じてツールの判定結果は分かれ、それぞれが示す証拠の確度も異なります。

ツールの利用手順

管理対象のサイトを確認する場合、Codex対応環境のユーザーはリポジトリの指示に従いスキルを導入して実行できます。公開URLの確認には phpcheck-url を使用し、サーバーへのアクセス権がある場合は phpcheck-server を用いてWebトラフィックを実際に処理しているPHPバージョンを突き合わせます。

Node.jsを用いてローカルから直接実行する場合は、完全なリポジトリコードを取得してターミナルで該当ディレクトリへ移動し、ローカルにNode.js環境が整っていることを確認したうえで、管理下のドメインまたはローカル環境に対してコマンドを実行します（https://example.com はプレースホルダーの例示であり、自身が管理するサイトへ置き換える必要があります。本ツールはバージョン比較のみを行うものであり、対象に対する脆弱性の悪用テストは行いません）：

node phpcheck.js "https://example.com" --json
node phpcheck.js --local --json

バージョン照合における4つの死角

実際の運用保守における評価では、バージョン比較の結果をシステムの安全性の証明と短絡させることはできません。以下の死角に留意する必要があります：

1. レスポンスヘッダーの非表示と未露出：本番環境では expose_php が無効化されていたり、ゲートウェイ層でバージョンヘッダーが除去されていたりすることが多く、ツールがバージョン情報を取得できずに UNKNOWN を返します。UNKNOWN は「パッチ適用状態を判定するための情報が不足している」ことを示します。
2. ディストリビューションによるソースコードのバックポート：Linuxディストリビューションがパッチをバックポートする場合、上流のバージョン番号を維持したままパッケージ全体のリビジョン番号で更新を識別することがあります。ツールは上流バージョンのみを比較するため、すでにパッチが適用されたパッケージであっても VULNERABLE と誤判定される場合があります。ベンダーのアナウンスを参照し、完全なリビジョン番号と照合することが不可欠です。
3. CLIコマンドラインとWeb実行環境の差異：ターミナルで php -v を実行して表示されるのはコマンドライン環境で呼び出されたバイナリのバージョンですが、Webサーバー（NginxやApacheなど）のバックエンドで実際にトラフィックを処理しているのは別のPHP-FPMプロセスプールや独立したコンテナである場合があり、両者のバージョンやビルドが一致しないケースがあります。
4. OK ステータスはバージョン番号が組み込みの基準値を満たしていることのみを意味する：このステータスは「以降の安定版パッチに修正が含まれている」という前提に基づく判定にすぎず、実際のメモリ上で脆弱性が再現可能かどうかをツールが独自にテストしているわけではありません。

運用チームはOSやディストリビューターの公式セキュリティ告知に依拠し、完全なパッケージバージョンとWebトラフィックを処理している実際の稼働ビルドを突き合わせる必要があります。アップグレード完了後は、ベンダーの推奨手順に従って関連するPHP-FPMやApacheのプロセスを再起動するか、コンテナイメージを再デプロイし、サービスが確実に修正済みバージョンへ切り替わっていることを確認してください。

ソフトウェアのアップグレードは脆弱性を塞ぐための措置です。仮にそれ以前に侵入を受けていた場合は、残された痕跡の調査と対処が別途必要となります。パッチ適用までの間、事業者による全トランザクション対象のWAFルールは既知ペイロードの緩和に役立ちますが、コアパッチの代わりにはなりません。迅速な更新が難しくリスクが高い場合は、自社のネットワーク構成を踏まえ、影響を受けるサービスを一時的にパブリックインターネットから切り離す運用も検討対象となります。