PHPの重大な脆弱性は、OpenAI(ドットエーアイではなくOpenAI)が2026年10月21日に発表したもので、同社のAIモデルが発見し、OpenAIがメンテナーやWiz、Cloudflareらと連携して開示前の修正・防御策の準備を主導した案件です。修正とリリース自体はPHPメンテナーが主導しました。
室谷代表取締役いやこれは相当大きいニュースなんですよね。OpenAIが「Patch the Planet」の一環として、AIモデルでPHPの重大脆弱性を見つけたと発表しました。
PHPは推定70%のウェブサイトで使われている言語ですから、影響範囲が桁違いなんですよ。
PHPは推定70%のウェブサイトで使われている言語ですから、影響範囲が桁違いなんですよ。
テキトー教師DotAI 認定講師しかも単に「見つけました」で終わってないのがポイントで。2か月かけてメンテナー、研究者、セキュリティベンダーを束ねて、開示前に修正と防御策を準備したと。
単に脆弱性発見の話じゃないんですよ。
単に脆弱性発見の話じゃないんですよ。
室谷代表取締役そうなんです。しかも「攻撃者より先にフロンティアAIが見つけた」と。
これがDefender's Windowという概念の実例だと。まず何が起きたのか整理しましょう。
これがDefender's Windowという概念の実例だと。まず何が起きたのか整理しましょう。
OpenAIのAIがPHPの重大脆弱性を発見——何が起きたのか
PHP重大脆弱性 発見から修正までの役割分担
発見
CalifがGPT‑5.6 Solを使って発見。Wizも両方の脆弱性を独立に発見・報告
修正・リリース
PHPのメンテナーが主導。修正は非常に複雑でPHPエンジンへの大規模な変更が必要だった
研究・技術支援・調整
OpenAIのチーム、Wiz、Cloudflareなどが貢献。開示前の調整に2か月を要した
現在の状態
PHPを使っている全てのサイトが安全にアップグレードできる状態になった
室谷代表取締役発表によると、OpenAIのモデルがPatch the Planetの取り組みの一環としてPHPの重大なセキュリティ欠陥を発見した、という流れです。PHPは推定70%のウェブサイトを動かしているオープンソース言語で、その規模ゆえに「近年で最も影響の大きい脆弱性の一つ」と位置づけています。
テキトー教師DotAI 認定講師役割分担を正確に見ておきたいんですよ。公式ページには、CalifがGPT‑5.6 Solを使って発見し、Wizも両方の脆弱性を独立に発見・報告したとあります。
修正とリリースはPHPのメンテナーが主導して、OpenAIのチームやWiz、Cloudflareなどが研究・技術支援・調整で貢献した、という構造です。
修正とリリースはPHPのメンテナーが主導して、OpenAIのチームやWiz、Cloudflareなどが研究・技術支援・調整で貢献した、という構造です。
室谷代表取締役ここ大事ですよね。「OpenAIが修正した」わけじゃなくて、あくまでメンテナー主導のリリースを、OpenAIが調整役として支えたと。
MYUUUでもOSSの依存関係は常に追いかけていますけど、こういう開示前の調整って地味に一番大変な部分なんですよ。
MYUUUでもOSSの依存関係は常に追いかけていますけど、こういう開示前の調整って地味に一番大変な部分なんですよ。
テキトー教師DotAI 認定講師しかも準備に2か月かかっている。公式スレッドでも「修正が非常に複雑で、PHPエンジンへの大規模な変更が必要だった」と説明されています。
だからこそ開示前に時間を稼ぐ必要があった、と。
だからこそ開示前に時間を稼ぐ必要があった、と。
室谷代表取締役で、今は「PHPを使っている全てのサイトが安全にアップグレードできる」状態になった、と。ここがゴールなんですよね。
発表を見た人が「で、私は何をすればいいの?」となるので、そこを具体的に掘っていきます。
発表を見た人が「で、私は何をすればいいの?」となるので、そこを具体的に掘っていきます。
PHPの脆弱性とは?影響を受けるバージョンと危険度(CVSS 9.2)
修正された2件のRCE脆弱性
CVE-2026-109618
- GHSA-w8hw-w9fx-j79w
- メモリ不足(OOM)処理の不整合を突くRCE
- 内部リクエストデータが部分的にしか初期化されていない状態で処理が中断
- 後続のクリーンアップが不正なデータを有効なものとして扱う
CVE-2026-109619
- GHSA-6wmf-4rv5-p3rp
- 古いグローバル状態を突くRCE
- リクエストが所有する内部状態がメモリ解放後も残存
- 同じワーカーの後続リクエストが初期化前に古い状態を使用
テキトー教師DotAI 認定講師PHP公式のセキュリティアドバイザリが同日付で出ています。修正されたのは2件の重大な脆弱性で、いずれもCVSS v4.0で9.2。
認証なしでリモートコード実行(RCE)が可能になるものです。
認証なしでリモートコード実行(RCE)が可能になるものです。
室谷代表取締役RCEって一番ヤバい部類じゃないですか。外部から送ったリクエストでサーバー上で任意のコードを動かせるわけですから。
PHP公式も「全てのPHPユーザーに直ちの更新を強く推奨」と書いています。
PHP公式も「全てのPHPユーザーに直ちの更新を強く推奨」と書いています。
テキトー教師DotAI 認定講師2件の中身も公式に書かれています。整理するとこうです。
- CVE-2026-109618(GHSA-w8hw-w9fx-j79w): メモリ不足(OOM)処理の不整合を突くRCE。内部リクエストデータが部分的にしか初期化されていない状態で処理が中断され、後続のクリーンアップが不正なデータを有効なものとして扱ってしまう
- CVE-2026-109619(GHSA-6wmf-4rv5-p3rp): 古いグローバル状態を突くRCE。リクエストが所有する内部状態が、そのメモリ解放後も残存し、同じワーカーが処理する後続リクエストが初期化前にその古い状態を使ってしまう
室谷代表取締役なるほど、両方ともPHPエンジンの内部状態管理の問題なんですね。アプリケーションコードの問題じゃないから、アプリ側でいくら気をつけても防げない。
だからPHP本体の更新が必須だと。
だからPHP本体の更新が必須だと。
テキトー教師DotAI 認定講師影響範囲も公式に明記されています。「Webリクエストを処理する全てのPHPインストール」で、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが挙げられています。
中でもリスクが最も高いとされているのがmod_phpで、認証なしのリクエストがアプリケーションコードの実行前に攻撃を引き起こす実証済みのエクスプロイトがある、と。
中でもリスクが最も高いとされているのがmod_phpで、認証なしのリクエストがアプリケーションコードの実行前に攻撃を引き起こす実証済みのエクスプロイトがある、と。
室谷代表取締役アプリのコードが動く前、つまり入口でやられるわけですよね。これはWAFである程度は防御できても、根本はPHP本体を上げるしかない。
CVSS 9.2という数字も、認証不要でRCEという条件を考えれば妥当なんですよ。
CVSS 9.2という数字も、認証不要でRCEという条件を考えれば妥当なんですよ。
テキトー教師DotAI 認定講師ちなみにCVSSの表記はPHP公式では「CVSS v4.0 9.2」と書かれています。背景ブリーフでは「CVSS 9.2」とまとめられていますが、出典に沿ってv4.0であることも添えておきたいところです。
修正版へのアップデート方法とPHPバージョンチェッカー
修正版へのアップデート手順
- 01対象バージョンを確認修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35の4つ。PHP公式が明示している。
- 02入手経路を選ぶソースは公式ダウンロードページから。Windows向けソースとバイナリも同ページ。LinuxディストリビューションやLTSベンダーは各ベンダーの更新パッケージを確認する。
- 03PHP 8.1以前の扱いを確認PHPプロジェクトからの更新は提供されない。ベンダーのバックポート提供を確認するか、サポートされているバージョンに上げる。
- 04rpms.remirepo.net依存を点検公式が名指しで警告。ディストリビューションのパッケージかソースビルドへの切り替えを強く促している。
- 05該当サーバーを洗い出すPHPバージョンチェッカーやCodexスキルで脆弱な可能性のあるバージョンを特定し、どの更新が該当するか判断する。
- 06更新を適用PHP公式と各プロバイダーのガイダンスに沿って更新する。更新が唯一の安全な選択肢。
- 07すぐ更新できない場合は緩和策公式アドバイザリの緩和策は時間稼ぎ。完全な緩和策はなく、更新が本命。
- 08サポート終了を見据えた移行計画PHP 8.2は2026年12月31日にEOL。それ以降はセキュリティ修正が来ないため、サポートされているバージョンへの移行計画を立てる。
室谷代表取締役で、実際どうすればいいか。PHP公式が修正版のバージョンを明示しているので、そこは迷いようがないですよね。
テキトー教師DotAI 認定講師修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35の4つです。ソースのダウンロードは公式のダウンロードページ、Windows向けのソースとバイナリも同じページにあります。
LinuxディストリビューションやLTSベンダーには事前にパッチが渡っているので、各ベンダーの更新パッケージを確認する流れです。
LinuxディストリビューションやLTSベンダーには事前にパッチが渡っているので、各ベンダーの更新パッケージを確認する流れです。
室谷代表取締役ここで注意なのが、PHP 8.1以前はPHPプロジェクトからの更新がもう提供されないということ。ディストリビューションやLTSベンダーがバックポートを提供している場合があるので、ベンダーに確認するか、サポートされているバージョンに上げる必要があります。
テキトー教師DotAI 認定講師あと公式が名指しで警告しているのが、ボランティア運営のrpms.remirepo.netに依存しているケースです。「ディストリビューションのパッケージかソースビルドに切り替えるよう強く促す、このリポジトリには当日の更新がない」と明記されています。
ここは見落としやすいので、該当する人はすぐ確認したほうがいいです。
ここは見落としやすいので、該当する人はすぐ確認したほうがいいです。
室谷代表取締役緊急度でいうと、PHP 8.2は2026年12月31日にEOLを迎えて、それ以降はセキュリティ修正が来ないと公式が案内しています。今回の更新を機に、サポートされているバージョンへの移行計画も立てておきたいところですね。
テキトー教師DotAI 認定講師そしてOpenAI側も運用支援を用意しています。公式ページには「PHPバージョンチェッカーを共有する」とあり、さらに「Codexスキル」も用意して、脆弱な可能性のあるPHPバージョンの特定や、どの更新が該当するかの判断を支援すると書かれています。
室谷代表取締役これはありがたいですよね。現場だと「うちのどのサーバーが該当するんだっけ」の洗い出しが一番時間かかるので。
チェッカーで当たりをつけて、PHP公式と各プロバイダーのガイダンスに沿って更新する、という順番になります。
チェッカーで当たりをつけて、PHP公式と各プロバイダーのガイダンスに沿って更新する、という順番になります。
テキトー教師DotAI 認定講師もしすぐに更新できない場合の緩和策も公式アドバイザリに書かれています。ただし「完全な緩和策はなく、更新が唯一の安全な選択肢」とPHP側が明言している点は絶対に外せません。
あくまで時間稼ぎです。
あくまで時間稼ぎです。
室谷代表取締役そこは誤解されやすいので、緩和策の中身も正確に紹介しておきたいですね。
テキトー教師DotAI 認定講師整理するとこうです。
- CVE-2026-109618(OOM経由)向け: memory_limit=-1を、アプリから上書きできない形(FPMプールやApache設定のphp_admin_valueなど)で設定する。post_max_sizeを低く設定し、アップロード不要なら8M、必要なら32Mにする。upload_max_filesizeはpost_max_sizeより小さく保つ。Webサーバーやプロキシ側でデコード後のリクエストサイズ、入力フィールド数、マルチパートのパート数、ヘッダー数、ネスト深さの制限も検討する。コンテナやcgroupの制限は可用性の境界として使い、影響ワーカーだけを落とすポリシーが望ましい。RLIMIT_ASやRLIMIT_DATAでの代替は避ける(脆弱なアロケーション失敗を招きうるため)
- CVE-2026-109619(古いグローバル状態)向け: session.upload_progress.enabled=0を設定し、全ワーカーを再起動する。php.iniやFPMプール、サーバー設定などリクエスト解析前に効く場所で設定し、ini_set()やFPMの.user.iniには頼らない。PHP 8.5ではfatal_error_backtraces=0を設定して全ワーカーを再起動する。初期化前に診断を出す、リクエスト単位の無効・非推奨設定を除去する。error_reportingやdisplay_errors、@で診断を隠すのは効果がない。攻撃者が到達できる致命的エラーや実行タイムアウト(コールバック、アップロード・インポート処理、クリーンアップの失敗など)を修正する
室谷代表取締役かなり細かいですけど、要は「更新が本命、緩和策はあくまで補助」という順番を間違えないことですよね。
Patch the Planetとは?AIによる脆弱性発見・調整の仕組み
室谷代表取締役ここで背景のPatch the Planetなんですけど、これは2026年6月22日にOpenAIが発表したDaybreak構想の一環で、Trail of Bitsと組んで始めた取り組みなんですよね。
テキトー教師DotAI 認定講師はい。狙いは「発見だけで終わらせない」ことです。
AIは脆弱性発見を加速しますが、発見だけではユーザーは守られない。むしろメンテナーには「より速く、より多くの報告」が押し寄せて、限られた時間とリソースで仕分けする負担が増える。
Patch the Planetはその負担を増やさず減らすために設計されている、と。
AIは脆弱性発見を加速しますが、発見だけではユーザーは守られない。むしろメンテナーには「より速く、より多くの報告」が押し寄せて、限られた時間とリソースで仕分けする負担が増える。
Patch the Planetはその負担を増やさず減らすために設計されている、と。
室谷代表取締役具体的には、セキュリティエンジニアがメンテナーに届く前に所見をレビューして、パッチとテストの開発を一緒に進めて、最初の修正が入った後も改善を続けられる再利用可能なワークフローを作る、と。MYUUUでも「AIで見つけた」で終わって現場が疲弊するケースは見てきたので、この設計は理にかなっているんですよ。
テキトー教師DotAI 認定講師参加プロジェクトも公式に列挙されています。cURL、NATS Server、pyca/cryptography、Sigstore、aiohttp、Goプロジェクト、freenginx、Python、python.orgが初期参加です。
Trail of Bitsは19のオープンソースプロジェクトでCodexとGPT‑5.5‑Cyberをフルタイムで使って、数百件のセキュリティ問題を特定し、数十件のパッチをマージ済みと報告しています。
Trail of Bitsは19のオープンソースプロジェクトでCodexとGPT‑5.5‑Cyberをフルタイムで使って、数百件のセキュリティ問題を特定し、数十件のパッチをマージ済みと報告しています。
室谷代表取締役しかも「全所見をセキュリティエンジニアが手動レビューしてからメンテナーに届ける」という工程を入れているのが現実的で。フロンティアモデルは誤検知も大量に出すので、そこを人力でふるいにかける。
この一手間が保守者の信頼につながるんですよね。
この一手間が保守者の信頼につながるんですよね。
テキトー教師DotAI 認定講師今回のPHPの件も、この仕組みがあって初めて「開示前に2か月かけて準備する」という芸当ができたわけです。OpenAIはさらに、防御側支援として10億ドル規模の「Daybreak for Frontline Defenders」による補助的アクセスも表明しています。
室谷代表取締役ただ、同じ能力は攻撃者側にも使えるわけで。公式ページでも「同じ能力が攻撃者の攻撃ツールやエクスプロイト開発を加速させうる」と明記されています。
ここは冷静に見ておく必要があります。
ここは冷静に見ておく必要があります。
Defender's Windowとは?防御側が先手を取れる理由と限界
テキトー教師DotAI 認定講師Defender's Windowは、防御側が攻撃者より先に脆弱性を把握して、修正準備の時間を稼げる状態を指すOpenAIの概念です。今回、OpenAIの認識する限り、フロンティアAIが攻撃者より先にこの脆弱性を見つけ、メンテナーやセキュリティプロバイダーが開示前に修正と防御策を準備する時間が生まれた、と。
室谷代表取締役これ、概念としてはすごく前向きなんですけど、条件付きなんですよね。「フロンティアAIが攻撃者より先に」という前提が崩れたら、窓は閉じる。
公式ページでも、フロンティア能力が広く利用可能な能力よりそこまで先にいない場合、準備時間は乏しくなりうると書かれています。
公式ページでも、フロンティア能力が広く利用可能な能力よりそこまで先にいない場合、準備時間は乏しくなりうると書かれています。
テキトー教師DotAI 認定講師そこが限界ですよね。OpenAI自身も「同様の発見は今後数か月で急増すると予想する」と述べていて、今回が特別な一発ではなく、これから日常になるという前提で枠組みを提案しています。
室谷代表取締役その枠組みが5段階のプロセスとして示されているのが面白いんですよ。整理すると、上流の脆弱性を検証・修正する、影響を受ける組織に行動する時間を与える、政府パートナーと連携して重要システムを守る、影響製品全体で更新を準備する、パッチ公開後にガイダンスを出して展開を支援する、という流れです。
テキトー教師DotAI 認定講師PHPの件では、米政府の複数部門とも連携したと書かれています。ホワイトハウスのSuper Intelligence Force、Office of the National Cyber Director(ONCD)、CISA、そして国際パートナーです。
重要インフラを守る組織にガイダンスを届けるための動きですね。
重要インフラを守る組織にガイダンスを届けるための動きですね。
室谷代表取締役あと実務的に効くのが、WAFルールのような防御策をセキュリティベンダーが事前に用意できる点です。今回もCloudflareなどが調整に参加していますし、更新までのつなぎとして現実的です。
テキトー教師DotAI 認定講師一方で、OpenAIはこの枠組みについて「コミュニティと一緒に改善したい」と公開して、論点も並べています。開示ウィンドウはどれくらい必要か、緊急パッチはどう扱うか、事前通知は誰に出すか、上流の修正が待てない下流パッケージをどうするか、といった問いです。
完成形ではなくたたき台なんですよね。
完成形ではなくたたき台なんですよね。
室谷代表取締役そこは正直に伝えたほうがいいと思います。Defender's Windowは魔法じゃなくて、調整の設計と運用で成り立つものだと。
PHP×OpenAI API連携で気をつけるべきセキュリティ対策
室谷代表取締役ここからは実務者向けの話です。PHPでOpenAI APIを使っている、あるいはこれから使うアプリのセキュリティをどう考えるか。
まず前提として、今回発表されたのはPHP本体(コア)の脆弱性に関するもので、OpenAI APIのクライアントライブラリ固有の脆弱性として発表されたものではありません。
まず前提として、今回発表されたのはPHP本体(コア)の脆弱性に関するもので、OpenAI APIのクライアントライブラリ固有の脆弱性として発表されたものではありません。
テキトー教師DotAI 認定講師そこは正確にしておきたいですね。今回の2件はPHPエンジン側の問題で、アプリのコードで防げる種類のものではない。
だからこそPHP本体の更新が最優先です。そのうえで、API連携アプリ側の一般的な注意点は公式アドバイザリの緩和策と重なる部分があります。
だからこそPHP本体の更新が最優先です。そのうえで、API連携アプリ側の一般的な注意点は公式アドバイザリの緩和策と重なる部分があります。
室谷代表取締役具体的には、入力サイズの制限ですよね。post_max_sizeやupload_max_filesize、リクエストサイズやフィールド数の制限は、APIに限らず外部入力を受けるアプリ全般で効きます。
逆に言うと、外部入力の入口を絞るのは基本中の基本なんですよ。
逆に言うと、外部入力の入口を絞るのは基本中の基本なんですよ。
テキトー教師DotAI 認定講師あとはセッション設定です。session.upload_progress.enabled=0は今回の攻撃経路の一つを塞ぐので、API連携アプリでも設定を見直す価値があります。
設定はini_set()ではなく、リクエスト解析前に効くphp.iniやFPMプールで行うのがポイントです。
設定はini_set()ではなく、リクエスト解析前に効くphp.iniやFPMプールで行うのがポイントです。
室谷代表取締役それと、APIキーの管理ですね。これは今回の脆弱性とは別の話ですが、PHPアプリからOpenAI APIを叩く構成だと、キーがアプリの設定や環境変数に置かれることが多い。
権限を最小化して、漏れたときにすぐローテーションできる運用にしておく。ここはAI連携アプリ共通の勘所です。
権限を最小化して、漏れたときにすぐローテーションできる運用にしておく。ここはAI連携アプリ共通の勘所です。
テキトー教師DotAI 認定講師受講生さんからも「AI連携のアプリは何から守ればいいか」とよく聞かれるんですけど、順番としては、基盤のPHPを最新に保つ、外部入力の入口を絞る、秘密情報を分離して管理する、の3つをまず固めるのが現実的です。
室谷代表取締役あと今回の件で意識したいのが、依存関係の棚卸しです。PHPのバージョンだけでなく、FPMやApacheのmod_php、LiteSpeed、FrankenPHPなど、どの実行形態で動いているかを把握しておく。
公式がリスク最高としているmod_phpを使っているなら、なおさら優先度を上げるべきです。
公式がリスク最高としているmod_phpを使っているなら、なおさら優先度を上げるべきです。
テキトー教師DotAI 認定講師更新後は「ちゃんと修正版で動いているか」の確認までがセットです。Patch the Planetのサイトでは、影響システムの特定、適切な更新の探索、更新後の稼働確認までを支援する情報がまとめられていると公式に書かれています。
CISAの優先順位付けと修復のガイダンスを使って、露出度や悪用状況に応じて緊急パッチか計画更新かを判断する、という考え方も示されています。
CISAの優先順位付けと修復のガイダンスを使って、露出度や悪用状況に応じて緊急パッチか計画更新かを判断する、という考え方も示されています。
室谷代表取締役侵襲を受けた可能性があるならフォレンジック調査も必要になる。この一連の流れを一度社内で型にしておくと、次に同種の発表が来たときに迷わないんですよね。
よくある質問
室谷代表取締役ここまでの話を、よく聞かれる形で整理しておきますね。
テキトー教師DotAI 認定講師まず「どのバージョンに更新すればいいか」。PHP 8.5.12、8.4.27、8.3.36、8.2.35のいずれかです。
PHP 8.1以前はPHPプロジェクトからの更新がないので、ディストリビューションやLTSベンダーのバックポートを確認するか、サポートされているバージョンに上げてください。
PHP 8.1以前はPHPプロジェクトからの更新がないので、ディストリビューションやLTSベンダーのバックポートを確認するか、サポートされているバージョンに上げてください。
室谷代表取締役「緩和策だけではだめか」という質問も多いですよね。PHP公式は「完全な緩和策はなく、更新が唯一の安全な選択肢」と明言しています。
緩和策は特定の攻撃経路の露出を減らすもので、インストールを安全にするものではありません。
緩和策は特定の攻撃経路の露出を減らすもので、インストールを安全にするものではありません。
テキトー教師DotAI 認定講師「OpenAI APIのPHPクライアントライブラリに脆弱性があるのか」という点については、今回発表されたのはPHP本体(コア)の脆弱性に関するもので、クライアントライブラリ固有の脆弱性として発表されたものではありません。個別ライブラリの状況は、現時点では明らかにされていません。
室谷代表取締役「AIが見つけたならAIで直せるのか」というのも気になるところですけど、今回の修正はPHPエンジンへの大規模変更を要する複雑なもので、メンテナー主導で2か月かけて準備されたものです。AIは発見や検証、テスト生成を加速する役割で、最終的な判断と責任はメンテナーにある、というのが今回の構図ですね。
テキトー教師DotAI 認定講師最後に「今後も同じような発表が続くのか」。OpenAIは同様の発見が今後数か月で急増すると予想していて、枠組みへのフィードバックも募っています。
防御側としては、更新を素早く回せる体制を日常にしておくことが、一番の備えになります。
防御側としては、更新を素早く回せる体制を日常にしておくことが、一番の備えになります。
室谷代表取締役というわけで、まずは自分の環境のPHPバージョンを確認して、該当するなら今日中に更新を。これに尽きますね。
