chot Inc.（ちょっと株式会社）

PHPに緊急レベルの脆弱性2件（CVE-2026-109618／109619）修正版が公開 いま確認すべきこと

セキュリティ

PHP開発チームは2026年10月21日（日本時間同日23時ごろ）、認証なしのリモートコード実行につながる重大な脆弱性2件を修正したPHP 8.5.12／8.4.27／8.3.36／8.2.35を公開しました。公式アドバイザリは、完全な緩和策は存在せず更新だけが安全な選択肢だと明言しています。Webリクエストを処理しているPHPはすべて対象になり得るため、まず「どのサーバーでどのPHPが動いているか」を洗い出し、提供元の更新を当て、ワーカーを再起動するところまでを最優先で進めてください。

修正された脆弱性と深刻度

対象はCVE-2026-109618（OOM時のメモリ破壊による任意コード実行）とCVE-2026-109619（リクエスト間に残る内部状態による任意コード実行）の2件です。深刻度はいずれもCVSS v4.0で9.2（Critical）とされ、どちらも認証なしのリモートコード実行につながり得ます。通称は「php2shell」です。

前者は、メモリ確保に失敗した際にリクエストの内部データが初期化途中のまま処理が中断され、後片付け処理が不正なデータを正常なものとして扱ってしまう問題です。後者は、リクエストが使っていた内部状態が、そのメモリ解放後も残り、同じワーカーが処理する次のリクエストで使われてしまう問題です。いずれも種別はUse After Free（解放済みメモリの使用）に分類されています。

なお今回は、修正版の公開前にCVE番号などがオンライン上に流出し、PHPプロジェクトが公開日を前倒しした経緯があります。公開前後からCloudflareやwatchTowr、Hadrianなど複数のセキュリティ企業が攻撃試行の観測を報告しており、PoCコードも出回り始めています。侵害成功の確認報告は限定的ですが、「まだ悪用されていないから後日でよい」と判断できる状況ではありません。

影響を受けるのはどの環境か

公式アドバイザリは、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなどWebリクエストを処理するPHP環境すべてをリスク対象として挙げています。中でもmod_phpのリスクが最も高く、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が成立することが実証されたと説明しています。

一方で、実際の悪用難易度は構成によって差があります。Red Hatは自社の評価を「Important」とし、RHELの標準構成はmod_phpではなくPHP-FPMであること、FPMは初期化失敗時にワーカーが終了するため実際のコード実行は難しいことを示しています。ただしこれは「更新しなくてよい」という意味ではありません。CVE-2026-109619はリクエスト処理が成功した後の内部状態が原因で、アプリケーション側の挙動次第で攻撃経路が成立し得るためです。Palo Alto Networks Unit 42は、自社の計測で2,260万以上の公開インスタンスが影響を受ける可能性があるとしています。

WordPressやLaravelなどのアプリケーションを使っている場合も、修正対象はCMS本体ではなくサーバー側のPHPです。プラグインやテーマの更新では解決しません。

いま実施する手順

  1. PHPの稼働箇所を棚卸しする。 IPAも事前の棚卸しを呼びかけています。自社サーバーだけでなく、PHPを内包する製品・アプライアンス・社内ツールも対象です。静的サイトだと思っていた仮想ホストにPHPハンドラが残っているケースもあるため、Webサーバー設定からPHPへ渡している経路を確認します。
  2. CLIではなく実際に稼働しているSAPIのバージョンを確認する。 php -vの結果とPHP-FPMが使うバイナリは一致しないことがあります。系列名（8.3など）だけでは判断できず、8.3.36のようなパッチ番号まで確認します。
  3. 提供元の更新を適用する。 LinuxディストリビューションやLTSベンダーには事前にパッチが渡されているため、まず各ベンダーの更新パッケージを確認します。ディストリビューションはバックポート修正のため上流バージョン番号が変わらないことがあり、その場合はパッケージのチェンジログでCVE番号の記載を確認するのが確実です。なお公式は、有志運営のrpms.remirepo.netに依存している場合はディストリビューションのパッケージ利用かソースからのビルドへ切り替えるよう促しています。
  4. ワーカーを再起動し、旧バイナリで動き続けるプロセスが残っていないか確認する。 更新前から起動しているプロセスは古いバイナリのまま動作します。
  5. レンタルサーバーやマネージドサービスは、事業者の対応状況を確認する。 自社で更新できない環境では、事業者の告知と適用完了時刻を記録しておきます。
  6. 更新前のログを退避する。 Webサーバーとアプリケーションのログは、侵害有無の確認に必要です。ローテーションやデプロイで消える前に保全します。

サポート終了版を使っている場合

PHP 8.1以前はPHPプロジェクトのサポート対象外で、通常の修正は提供されません。ただし今回は深刻度を踏まえ、PHP 7.4／8.0／8.1向けに最小限のソースバックポートがGitHub上で提供されています。ディストリビューションやLTSベンダーが独自に修正を提供している場合もあるため、まず提供元に確認し、併せてサポート対象バージョンへの移行計画を立ててください。PHP 8.2も2026年12月31日でサポート終了が予定されており、8.2系で凌ぐ判断は短期的なものに留まります。

すぐに更新できない場合の緩和策とその限界

公式アドバイザリは、更新できない環境向けにmemory_limit=-1の管理者設定、post_max_sizeの抑制、session.upload_progress.enabled=0、PHP 8.5でのfatal_error_backtraces=0などを挙げています。ただしこれらは特定の攻撃経路への露出を減らすだけで、安全な状態にはならないと明記されています。RLIMIT_ASやRLIMIT_DATAでのメモリ制限は、かえって脆弱な処理経路を踏ませるため代替にならない点にも注意が必要です。

WAFも同様で、Cloudflareは公開前から緊急ルールを配信した一方、攻撃者がルール回避のためにペイロードを変えている様子を観測したと報告しています。WAFは時間を稼ぐ手段であり、更新の代わりにはなりません。どうしても即時更新できない場合は、該当システムをインターネットから切り離す、到達元を限定するなど、公開範囲の縮小を併せて検討してください。

更新後に確認すること

適用後は、稼働中のバージョンが修正版になっているか、アプリケーションが正常に動くかを確認します。そのうえで、10月20日以降のWebサーバー・アプリケーション・認証ログを対象に、不自然なmultipartリクエスト、予期しないプロセスやファイルの変更、想定外の外向き通信がないかを点検します。侵害の痕跡が見つかった場合は、サーバーの再構築と、PHP実行ユーザーが読める範囲の認証情報（.env、DBパスワード、APIキー、アプリケーションキー）の全面的な再発行まで想定する必要があります。

今回の件は、脆弱性情報が先に流出し、修正版の公開と攻撃試行がほぼ同時に始まった点に特徴があります。まずは修正版の適用とワーカー再起動を完了させ、その後で「PHPの更新主体は誰か」「緊急時に何時間で適用できるか」を環境ごとに整理しておくと、次の緊急リリースでの初動が変わります。

出典

この記事をシェア

最新の記事

AI最新情報

Cloudflare OS がマネージド提供へ — GitHub 接続と Gmail 連携強化で何ができるようになったか

セキュリティ

脆弱性・脅威・リスク・インシデントの違い｜Web担当者のための4つの使い分け

開発

VercelのWebSocketサポートが正式リリース　制約と設計の勘所を整理する

コラム一覧