先日大騒ぎになったPHP2Shellですが、修正版リリースの提供直後、PHP財団公式ブログ記事Today's PHP Security Release, and How We're Strengthening PHP Securityが公開されました。
そもそもどんな脆弱性？
以下は簡易化のため正確ではありません。
PHPは、リクエストが来るとリクエストをメモリに展開し、プログラムを実行し、最後にメモリをきれいに初期化してから再び次のリクエストの処理を開始する、という仕組みになっています。
ここで細工したリクエストが送られてくるとメモリへの展開に失敗することがあり、その際にはメモリの一部が初期化されずリクエストが書き込まれたままになってしまうのです。
これによって、悪意のあるコードを送り込むことでサーバ上で実行することができてしまう、とざっくりいうとこんなかんじです。
もちろん簡単に実行できるわけではなく、実は理論上のバグ自体は2年前から見つかっていたのですが現実的な攻撃経路が見つからなかったので修正が後回しになっていました。
それほど難しい攻撃方法だったというわけです。
正直に言うと、このくらいの脆弱性はPHPに限らずよくあることだったりします。
つい先日もReactがReact2ShellでPHPより遙かに重大なバグをやらかしたばっかりですし、さらにPHP2Shellのまさにその日にNode.jsもOOMのバグを修正しています。
ではどうしてPHPだけ、IT界隈だけではなく一般社会まで巻き込むほどの騒動になってしまったのでしょうか。
その原因のひとつが、情報漏洩です。
すなわち、協調的脆弱性開示プロセスが破られたということです。
ということで以下はPHP財団公式のブログ記事、Today's PHP Security Release, and How We're Strengthening PHP Securityの概要です。
Today's PHP Security Release, and How We're Strengthening PHP Security
本日、PHPプロジェクトはPHP 8.5.12・8.4.27・8.3.36・8.2.35をリリースしました。
これらのリリースには、特定の条件下で攻撃者がPHPを実行していているサーバでコードを実行できてしまう2つの脆弱性が修正されています。
PHPを使っているのであれば、今すぐアップデートしてください。
php.netのアナウンスには、脆弱性の詳細と攻撃経路、どのシステムでアップデートが必要かの手順が記載されています。
この記事はアップデート方法の案内ではありません。
この脆弱性がどのように発見され修正されたのか、過去2年間でPHPのセキュリティ対策がどのように変化したか、そしてPHPのセキュリティ対策を維持するために何が必要なのかを解説します。
Two related critical remote code execution vulnerabilities
関連するRemote Code Execution脆弱性。
CVE-2026-109618
GHSA-w8hw-w9fx-j79w：OOMによるRCE。
リクエストが特定のタイミングでmemory_limitに達した場合、データが一部分だけ初期化されない状態で残ってしまうことがある。
その後そのデータが有効なものとして扱われることで、メモリ破壊が生じる。
CVE-2026-109619
GHSA-6wmf-4rv5-p3rp：グローバル状態残存によるRCE。
特定のタイミングで致命的エラーが発生すると、内部状態がリセットされないまま残ってしまうことがある。
その後、同じワーカーがそのメモリを使うことで、use-after-free脆弱性が生じる。
これらの問題はいずれも、メモリ操作とエラーハンドリングという、あらゆるPHPリクエストが影響を受ける部分に存在します。
重要な部分であることが、この脆弱性が深刻なものとなった原因であり、そして互換性を損なわず、パフォーマンスを低下させず、サードパーティ製品のエコシステムに影響を及ぼすことなく修正することが困難であった理由です。
A first external audit and increased security focus
初めての外部監査と、セキュリティ。
2024年にPHPは外部からのセキュリティ監査を受けました。
PHP財団は監査を実施するためドイツのSovereign Tech Agencyから資金を調達し、OSTIFに監査を依頼し、そしてQuarkslabが実際に監査を実行しました。
この監査で報告された問題をPHPコア開発者が修正していた際に、CVE-2026-109618の原因となるOOM問題の最初の兆候を発見しました。
このときは潜在的なexploitは存在したものの具体的な攻撃経路が発見されなかったため、実害を伴う他の問題への対応が優先されました。
OOM問題を解決するべくPHPセキュリティチームは解決策を検討しましたが、考えられたアプローチはいずれもトレードオフがありました。
すなわち後方互換性が失われる、別の攻撃経路が発生してしまう、あるいは事実上対応不可能なほど大量のサードパーティ拡張の修正が必要になる、などです。
PHPの意思決定プロセスは合意に基いています。
RCEの発生する実際の攻撃経路が見つからなかったこと、そしてエンジンに対する深い理解を持つコア開発者が少数であることもあり、いずれの選択肢を選ぶべきかで修正の方針決定プロセスが何か月も停滞しました。
この遅延は、セキュリティチームの意思決定プロセスと、開発者のリソース不足両方によって引き起こされた構造的失敗でした。
その後セキュリティチームの合意形成プロセスは、多数決と妥協が許されるように変更されつつあります。
Building a sustainable professional security organization
持続可能なセキュリティチームの構築。
ここ数か月で、PHPのセキュリティ対策の体制は大きく変化しました。
2026年5月にPHP財団はセキュリティチームを設立し、トリアージ・セキュリティ強化・調整を連携して行っています。
セキュリティエンジニアとして活躍するVolker Duschの貢献により、PHP財団とセキュリティチームのコミュニケーションが大きく改善しました。
また7月にはAlexandre DauboisがPHP財団に加入し、セキュリティ対応を支援しています。
9月にはDaniel Scherzerが加入し、セキュリティ強化を担当しています。
今年のはじめ、Alpha-Omegaの協力のもとAnthropicのClaude Mythosを用いたPHPのスキャンを実施しました。
さらにその後、OpenAIのDaybreak Redなどのツールも追加され、PHPがサポートする全てのプラットフォームでCIが動作する環境が構築されました。
またPHPプロジェクトをPatch the Planetに登録し、その一環としてセキュリティ企業Califが2026年7月30日に監査を開始しました。
8月11日にCalifの研究者Ryan Aから、2024年のOOMと同じ原因を起因とするRCEが発見されました。
さらに8月24日にはWizから、9月18日にはOpenAIからも個別に報告がありました。
これらの報告によりOOMの全容が明らかになり、この問題への対応が最優先課題となりました。
PHP財団の資金提供により、複数の担当者が最終的には24時間体制で取り組むことが可能になりました。
AIの成長に伴い、PHPセキュリティチームが受け取るレポートは格段に増大しました。
先週Alexandre DauboisがHow the PHP Security Team Handles Your Reportsの記事で説明しましたが、7月1日以降セキュリティチームは15件のCVEに対応し、そして重複・無効・再現不可能だった100件以上のレポートを破棄しました。
AIは報告を検証し、同じ原因を持つ脆弱性をグループ化することに役立ちますが、最終的な判断とパッチの適用は人間の手で行われます。
Leak and disrupted disclosure
これらの脆弱性に対する協調的脆弱性開示は、2日前まではうまく機能していました。
10月20日UTC15時ごろ、2つのCVEIDがソーシャルメディアで拡散され始めました。
リリース日程と、CVSSスコアが実際は9.2のところ誤って10.0と記載されていました。
詳細な技術情報は記載されていません。
これを受け、PHPプロジェクトは事前告知を前倒しにしてUTC19:30に公開しました。
アップデートのリリース日も10月22日UTC14時から10月21日UTC14時に変更しました。
ディストリビュータがまだパッケージング作業を完了していない可能性があるため、即座に公開すると多くのユーザがアップデートに影響を受ける可能性がありました。
リリース日の1日前倒しは、迅速な対応と準備期間の確保、アップデート手段の確保を天秤にかけた妥協点となりました。
さらにUTC20時、Califが誤って動画を公開してしまいました。
その動画では限定的であるものの複数のPoCが示されており、脆弱性の追加情報が明らかになってしまいました。
動画が削除されたあともコピーはすぐに拡散し、PoCの開発も加速しました。
10月20日UTC23時ごろ、一部のインフラプロバイダに対して提供していた緩和策が漏洩した可能性があります。
こちらが流出したあとで現れたPoCをセキュリティチームは調査しましたが、この時点では実際に脆弱性を突破可能なプログラムは発見されませんでした。
10月21日UTC07:41、協調リリース日時の6時間以上も前に、Chainguardは公開禁止措置を一方的に破って修正済みビルドを公開しました。
Chainguard以外のユーザがリリースを待っている間に、攻撃者がバイナリから脆弱性を抜き出すことが可能になりました。
これは、他の多くの関係者が協調的脆弱性開示に向けて努力してきた何週間もの日々を無駄にする行為でした。
A cautiously optimistic outlook
本日のリリースは、PHPのセキュリティ対策の進歩を示すものです。
8月にOOMの全貌が明らかになったあと、セキュリティチーム・PHP財団・リリースマネージャは一丸となって、全てのサポート対象に対して修正プログラムを提供することができました。
またディストリビュータや長期サポートベンダーには、ユーザが迅速にアップデートできるように、事前にパッチが提供されました。
修正に困難が見込まれる深刻な脆弱性については、今後はPHP財団のリーダー層に迅速に共有されることになるでしょう。
リーダー層が状況をタイムリーに把握し対応できるように、プロセスを改善しているからです。
PHP財団とPHPセキュリティチームは、ここしばらくで多くのことを学びました。
この経験を永続的で再現可能なプロセスへと転換していく予定です。
What we need from you
お願いしたいこと。
PHPは、政府機関、オンラインストア、銀行サイト、メディアサイト、そして企業が毎日利用するソフトウェアなど、Webのほとんどを支えています。
しかし、PHPのセキュリティ対策はいまだに、PHP財団に所属する少数の開発者グループと、わずかなボランティアだけに支えられています。
現在は、攻撃側にも防御側にも、かつてないほどの速度で脆弱性を発見できるツールが登場してきており、そのためバグの報告件数は今後も増加し続けることでしょう。
しかしツールだけでは、長年にわたり保持されてきたPHPエンジンの設計を適切に修正する方法を決定し、トレードオフを取捨選択し、パッチをレビューすることはできません。
そのような行為を行うためにはPHPのコードベースを熟知したエンジニアが必要ですが、現在はその人材が不足しています。
PHP財団の使命の中心は、PHPのコードベースを深く理解しているエンジニアを増やし、セキュリティチームに必要なリソースを確保することです。
この目標を達成するためには、PHPに依存している人たちからの支援が必要です。
PHP製品やサービスを開発している企業。
ホスティングプロバイダ、クラウドプラットフォーム。
PHPでサービスを運用している公共機関、政府機関。
2024年に行われたドイツSovereign Tech Agencyからの資金提供は、公共投資が何ももたらすかを示してくれました。
PHP財団へのスポンサーシップは、大きな問題が起きる前に解決する最も直接的な方法です。
https://thephp.foundation/sponsor/からスポンサーになることができます。
Thank you
PHPセキュリティチーム、ボランティア、PHP財団の開発チーム、リリースマネージャ、ディストリビュータや長期サポートベンダーのパッケージメンテナーの皆様。
今回のリリースを実現していただきありがとうございました。
Calif、OpenAI Codex Security、OSTIF、Quarkslabの皆様、調査と協調的脆弱性開示に感謝します。
Alpha-Omega、OpenAI、Anthropic、ツールへのアクセスとセキュリティ対策絵の一部支援を感謝します。
Sovereign Tech Agencyには2024年の監査への支援を感謝します。
そして全てのスポンサーの皆様に感謝致します。
コメント欄
Chainguard許せねぇなーおい？
We took our website down this morning when the "PoC"s were released, only serving a static website. Our customers were not pleased. Then we got contacted by Chainguard affiliates using our public support form if we would like to schedule a meeting with them, so that they could sell us their security services.
彼らが協調的脆弱性開示を破り、インターネットの半分を危機に至らしめたという記事を読んで私は激怒した。
Chainguardとは二度と取引しない。
全てのOSSセキュリティ関係者への警告です。
メーリングリストからChainguardを削除してください。
もしそうしなかった場合、今後も同じことが起こるでしょう。
最初の1日で、PHPサイトの23%にパッチが適用されました。
PHPで金を稼いでいる全ての企業が少しずつ支援してくれれば、チームはこれらの問題に迅速に対応できていただろう。
彼らのほとんどはボランティアで、支援を検討したことすらない連中から血眼になって非難されているわけだ。
これは警鐘となるべきだ。
支援もなしに、AI後の世界でインターネットインフラが存続できるとは思えない。
↑残念ながら、この問題は最初ではなく、そして最後でもない。
パッチが提供されなくなり、実害を被った時点で初めて事態の深刻さに気付くのだ。
そのときまでは、何もしないことが一番うまくいくのだ。
いいかげんC言語をやめて、メモリ安全性の高いRustなどに移行すべきだ。
↑C言語で書かれた多くのライブラリなどに依存している。
十分な資金を投入すればRustに変換はできるかもしれないが、開発者への支援なしには長期的な維持はできないだろう。
感想
2年間も全く知られることなく進められていた脆弱性問題の対応ですが、予定のほんの2日前に漏洩してしまったせいで世界的騒動になってしまったという顛末でした。
協調的脆弱性開示プロセスは、たった一人の裏切り者(もしくは粗忽者)がいただけで脆くも崩れ去ってしまう幻想であるという悪い実例が、たまたまPHPで発生してしまったわけですね。
そもそもが協調的脆弱性開示プロセスはボランティアにタダ働きさせるための脅迫でしかないなどと考えている人もいて、今後は協調的脆弱性開示プロセスという考え方もまた何かの変化を求められるかもしれませんね。
どの方向に進むべきなのか、なんてことはさっぱりわかりませんが。
そういえばPHP欠陥でサイト止めた日本、止めなかった米国とかいうあまりにも頭の悪すぎる記事が目に入ったのですが、もちろん言うまでもなくアメリカ含めた海外のWebサイトも大量に一時停止しています。
単に日本まで名の知れているような有名どころはPHPを使っていないか、運用しながらでも対応できる技術力資金力を持っているような大手が多いってだけですね。
というか、所謂オールドメディアの記事はどれもこれも酷いですな。
最もよいクラスの記事でも、事実や起きたことを羅列してあるだけで、ほぼ一切の深掘りがなされていない。
下のものはもう何もかもが適当出鱈目嘘灰だらけで、見るだけ損でしかない。
まあ自分の専門分野だからそう見えているだけかもしれませんが、実は私の知らない他の分野の記事も本職から見ればこんなかんじだったりするんだろうかと思うと恐ろしいですね。
そんな中聞いたこともないような得体の知れない自称識者ではなくPHPコア開発者の中の人を引っ張ってきた某テレビのファインプレーは光りますね。
まあテレビ見れないんで実際何を言ってたかはわかんないんだけど。
お前はどうだったの？
私は当日普通に寝て翌日悠々と出社してdnf module update php:remi-8.xって打っただけですわ。
いやもうほんとうremi様様です。
また、公式にはパッチしか用意されなかったPHP7.4までもバックポートを用意してくれていたので、ちょっと古いやつも軽々対応でした。
対策までの数時間に攻撃されてたら？
そんなことは知らん。
というか直後にNodeのアプデまでやらされる羽目になったのでどちらかというとそっちのほうが大変だったよ。