日本時間10月21日22時34分、PHP公式より極めて深刻度の高い2件の脆弱性情報および修正パッチが公開された。共通脆弱性評価システム(CVSS)v4.0における深刻度スコアは、10点満点中9.2(Critical)を記録している。
本脆弱性の本質は、PHP内部のメモリ管理(メモリ不足時の後処理不具合、および解放後メモリの再利用)に起因するメモリ破壊である。攻撃が成功した場合、認証なし(ログイン不要)のWebリクエストを通じて、Webサーバー実行権限でのリモートコード実行(RCE)を許すリスクがある。
修正パッチの公開と同時に、攻撃コードの作成(パッチ解析による脆弱性の逆算)と、防御側(システム管理者・インフラエンジニア)によるパッチ適用作業の「タイムアタック」が開始された。
事象の背景と構造
1. タイムラインと異例の事前予告
通常、脆弱性情報は修正パッチと同時に公開されるが、今回はPHP開発チームより「10月21日に重大なセキュリティ修正版を出す」旨が事前に予告されていた。これは、PHPが世界のWebサーバー(バックエンド言語が判明しているサイト)の69.3%という圧倒的なシェアを占めているため、エコシステム全体に事前準備を促す目的があった。
公開直前には、国内の多数のWebサービス(BASE、ピクシブ、ブシロード、ニコニコなど計84以上の企業・団体)や、さくらインターネット、エックスサーバーといった大手レンタルサーバー事業者、さらには内閣サイバーセキュリティセンター(NISC)や首相官邸公式アカウントまでもが、サービスの一次停止や緊急メンテナンスの準備を呼びかける異例の事態となった。
2. 影響を受けるバージョンと修正バージョン
本脆弱性の影響を受けるバージョン、および対策済みの修正バージョンは以下の通りである。
| 系統 | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| PHP 8.5 | 8.5.12 未満 | 8.5.12 |
| PHP 8.4 | 8.4.27 未満 | 8.4.27 |
| PHP 8.3 | 8.3.36 未満 | 8.3.36 |
| PHP 8.2 | 8.2.35 未満 | 8.2.35 |
サポート終了(EOL)バージョンの扱い
- PHP 8.1 以前(8.0, 7.4 など): 公式なバイナリ/パッケージとしての更新版はリリースされない。ただし、ソースコードからビルドするユーザー向けに、最小限の修正パッチ(ソースコード修正)が提供されている。
- PHP 5系: 公式な対応や修正コードの提供は一切言及されておらず、完全にサポート対象外となっている。
![[PHP]深刻度9.2の重大な脆弱性2件が公開](https://mtoy.work/develop/wp-content/uploads/sites/3/2025/02/wordpress-logo-160x90.jpg){kind=logo}
コアとなる技術的仕組みの解説
今回公開された脆弱性は以下の2件である。
1. CVE-2026-19618：メモリ不足時の処理不具合
メモリ確保に失敗した(Out of Memoryなど)際の例外処理・後片付け処理に起因する不具合。
途中で初期化が中断され、不完全な状態のままメモリ上に残されたデータを、その後のクリーンアップ処理が「正常なデータ」として誤認して処理してしまう。この処理プロセスの不整合を突くことで、メモリ破壊や意図しないコード実行へと繋がる。
2. CVE-2026-1909619：Use-After-Free(解放後メモリの再利用)
前のWebリクエスト処理が使用し、すでに解放(Free)されたはずのメモリ領域が、適切に初期化されないまま残存する不具合。
後続の新しいWebリクエストが同じメモリ領域を割り当てられた際、残存している古いデータをそのまま参照・利用してしまう。これにより、情報の漏洩や、メモリ構造の書き換えによるプログラム制御の奪取が可能となる。
攻撃ベクトルと条件
公式アドバイザリによると、Webリクエストを受け付けるすべてのPHP実行環境が対象となり得る。特に以下の構成において懸念が示されている。
- Apacheの `mod_php`: 公式が最も危険性が高いと指摘している。認証不要の単一リクエストを送信するだけで、アプリケーション(PHPスクリプト)が起動・実行される前段階の処理において、攻撃が成立する可能性が確認されている。
- PHP-FPM: `CVE-2026-1909619` において、プロセスの乗っ取りが可能であることが実証されている。
一部のセキュリティ機関(GMOサイバーセキュリティによる事前分析など)では、初期設定で有効化されている「セッションアップロードプログレス(`session.upload_progress`)」機能がメモリ破壊のトリガー(経路)の一つになっていると指摘されていた。公式発表においても、これが2件目の脆弱性における攻撃経路の一つであることが確認されている。
![[PHP]深刻度9.2の重大な脆弱性2件が公開](https://mtoy.work/develop/wp-content/uploads/sites/3/2026/05/Nginx-logo-160x90.png){kind=logo}
今後の影響と論点
1. 「パッチ解析」による攻撃コードの迅速化
オープンソースソフトウェアの宿命として、修正パッチ(GitHubのコミット差分)が公開された瞬間、攻撃者側は「どこが修正されたか」を逆算(パッチ解析)して脆弱性の詳細を把握できる。
過去の重大な脆弱性(CVE-2024-5702など)の例では、公開から24時間以内に実際の攻撃の試みが観測されている。防御側は、OSパッケージマネージャーへのパッチ反映やステージング環境での検証、本番適用、プロセス再起動といった一連の手順を、攻撃者がエクスプロイトを完成させる前に完了させなければならない。
2. 緩和策(Workaround)の限界
「セッションアップロードプログレス機能を無効化する(`session.upload_progress.enabled = Off`)」などの設定変更は、一部の攻撃経路を塞ぐ緩和策にはなるものの、根本的な解決にはならない。
メモリ上限(`memory_limit`)の調整やアップロードサイズ制限なども同様であり、公式およびセキュリティ機関は「設定変更はパッチ適用の代替にはならず、根本解決にはPHP本体のアップデートと関連プロセスの再起動が不可欠である」と強く警鐘を鳴らしている。
3. EOLバージョン(PHP 7系・5系)の残存問題
Web上の全PHPサイトのうち、すでに公式サポートが終了しているPHP 7系が約27.0%、5系が約7.7%稼働しているとされる(合計約35%)。これらの環境には自動的なパッケージ更新が降ってこないため、パッチ未適用のままインターネット上に晒され続け、長期にわたる攻撃の標的(踏み台や情報漏洩の温床)となるリスクが極めて高い。
コメント