2026-10-21 · ← ニュース
CVSS 9.2のPHP重大脆弱性2件、パッチ前日に情報が漏れ、すでにエクスプロイトが出回る
10月21日、PHP 8.2から8.5に、認証なしの攻撃者がサーバー上でコードを実行できる2件の脆弱性の修正が出た。情報漏洩でリリースは1日前倒しになり、動作するエクスプロイトもすでに出回っている。PHPを運用しているなら今すぐ更新すべきだ。
画像を読み込めませんでした。
PHPプロジェクトは、認証なしの攻撃者がサーバー上でコードを実行できる2件の脆弱性を修正した。ただしCVE番号の漏洩と誤って公開された動画が攻撃者に先手を与え、管理者はすでに動くエクスプロイトとの競争を強いられている。
CVE番号が漏れたため、パッチは1日前倒しで公開された
PHPプロジェクトは10月21日、8.5.12、8.4.27、8.3.36、8.2.35を公開した。修正対象はCVSS v4.0で9.2と評価された2件の重大な脆弱性だ。1件目(CVE-2026-109618)は、リクエストが悪いタイミングでmemory_limitに達したときに起きる。PHPは初期化途中のデータを有効なものとして扱い、メモリを破壊してしまう。2件目(CVE-2026-109619)は、致命的エラーの後に、前のリクエストがすでに解放したメモリへの参照を残す。
パッチは本来10月22日14時(UTC)に出る予定だった。その前日の15時(UTC)頃、2つのCVE番号がフォーラムやSNSに出回り、しかも誤った10.0というスコアが付いていた。PHP Foundationによれば、技術的な詳細は漏れていない。プロジェクトはリリースを1日早めた。同じ夜、セキュリティ企業のCalifが、自社のproof of conceptが複数の標的で動く様子を映した動画を誤って公開した。動画は削除されたが、コピーは拡散を続け、財団によれば新たなエクスプロイトの開発を加速させた。
最も危険なのはApacheとmod_phpの組み合わせだ。ここでは認証なしのリクエスト1つで、アプリケーションのコードが動く前に攻撃が始まる。しかも初期設定のままでだ。ただし影響はWebリクエストを処理するすべての環境に及び、PHP-FPM、php-cgi、FrankenPHP、LiteSpeedも含まれる。脆弱性を報告した企業の一つであるWiz Researchは、WordPress、Drupal、Joomlaへの認証なしの攻撃を実演した。Wizによれば、PHP 5.4以降のすべてのバージョンが影響を受ける。同社は、PHPが全Webサイトの70%を支えているとしている。
バグは2年間PHPに眠り、フロンティアモデルがそれをこじ開けた
最も興味深いのは時系列だ。PHP Foundationが報酬を払う開発者が、2024年の時点でメモリ問題の最初の兆候を見つけていた。Sovereign Tech Agencyが資金を出し、Quarkslabが実施した外部監査の最中のことだ。当時はコード実行に至る道筋を誰も知らなかった。チームは複数の修正案を検討したが、どれも互換性、性能、サードパーティ拡張のいずれかを壊した。財団自身、この遅れを合意制で意思決定する小さなチームの構造的な失敗だと認めている。
転機は2026年8月に訪れた。8月11日、Califが同じ根本原因による無条件のコード実行を報告した。WizとOpenAIもさらに別の攻撃経路を加えた。Wizは、自社ツールWiz AtlasとGemini 4 Argon、GPT-5.6 Solを使って最初のバグを見つけたとしている。同社によれば、エクスプロイトには複数のバグを連鎖させ、標的ごとのメモリ配置に合わせて調整する作業が要る。フロンティアモデルはその作業を数時間に縮めた。
ここにこのニュースのもう一つの層がある。エクスプロイトの複雑さは長いあいだ、静かな防御として働いてきた。バグの存在は知られていても、最後まで仕上げる時間は誰にもなかった。その作業をモデルがこなせるなら、理論上のバグはもう何年も待ってはくれない。管理者は公表から攻撃までの時間が短くなり、オープンソースのプロジェクトは少ない人手でより多くの仕事を抱える。PHPチームは7月1日以降に15件のCVEを公開し、無効、重複、再現不能だった100件を超える報告を処理してきた。
どんな設定でもサーバーを完全には守れない
PHPプロジェクトは、session.upload_progressの無効化やmemory_limitの扱いの変更など、一時的な対策を挙げている。しかし、どれもインストールを安全にはしないと自ら明言している。完全な防御はアップデートだけだ。8.2より古いバージョンには、プロジェクトからの修正は出ない。それらを使う側は、ディストリビューションや長期サポート事業者のバックポートに頼るしかない。多くのサーバーが頼るボランティア運営のパッケージリポジトリには、リリース当日の時点で更新がなかった。
日本のWebサイトにとっても、要となるのはホスティング事業者だ。共用ホスティングでは利用者が自分でPHPのバージョンを変えられないことが多く、リスクは事業者の対応速度に左右される。自前のコンテナやイメージは勝手には直らない。作り直し、すべてのworkerを再起動する必要がある。
ホスティング事業者の速さが、無防備なサイトの数を決める
最初のシグナルはホスティング事業者とディストリビューションから来る。Linuxディストリビューションと長期サポート事業者は事前にパッチを受け取っており、すぐにパッケージを用意できるはずだ。対応の遅い事業者のサイトは、すでに動くエクスプロイトを持つ攻撃者にとって真っ先の標的になる。
二つ目のシグナルは長期的なものだ。PHP Foundationは、PHPに依存する企業にセキュリティ作業の資金支援を求めている。AIがバグの発見と悪用の両方をさらに速めるなら、保守のための資金は運用セキュリティの問題になる。さらにPHP 8.2は2026年12月31日にサポートが終わるため、次に同じような修正が出ても届かない。
Lilithの判定
2024年に見つかったバグは、小さなチームのメモの中で2年間眠っていたが、フロンティアモデルがそれをエクスプロイトに変えた。あとは誤って公開された動画が1本あれば十分で、攻撃者はサーバー管理者と同じ夜に走り出した。
外部リンクは最後に置いています。まずここで簡潔に解説 — 他人のサイトを探し回る必要はありません。
元の記事 ↗ ↗