PHPの重大な脆弱性 CVE-2026-109618,CVE-2026-109619 通称「php2shell」 修正版公開-サイバー攻撃への悪用試行 Cloudflare・Akamaiなどが防御策

セキュリティニュース

投稿日時: 更新日時:

PHPに認証不要のコード実行につながる重大な脆弱性2件 CVE-2026-109618,CVE-2026-109619 通称「php2shell」 修正版公開、Cloudflare・Akamaiなどが防御策

PHP開発チームは2026年10月21日、PHP本体に存在する2件の重大な脆弱性「CVE-2026-109618」「CVE-2026-109619」を修正したセキュリティ更新を公開しました。いずれもCVSS v4.0で9.2(Critical)と評価され、認証されていない外部の攻撃者がサーバー上で不正なコードを実行するリモートコード実行(RCE)につながる可能性があります。両脆弱性は「php2shell」とも呼ばれています。

修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35です。PHP 7.4・8.0・8.1向けには例外的に限定的な修正ソースが公開され、UbuntuなどのOS提供元も修正済みパッケージを配布しています。WordPress公式も利用者にPHPの更新を呼びかけました。Cloudflare、Palo Alto Networks、Akamaiなどは攻撃を遮断するための防御策を公表していますが、WAFやIPSによる防御はPHP本体の修正を代替するものではありません。

PHPの重大脆弱性「php2shell」のサマリー

  • PHP開発チームは10月21日、重大脆弱性2件の修正版を正式公開しました。
  • 脆弱性はCVE-2026-109618とCVE-2026-109619。いずれもCVSS v4.0で9.2(Critical)です。
  • PHPのメモリ管理・リクエスト処理に関連する不具合で、認証不要のRCE、メモリ内情報の露出、サービス停止につながる恐れがあります。
  • PHP公式は、Apacheのmod_phpでアプリケーションコードの実行前に成立するRCEを実証したと説明しています。PHP-FPMやLiteSpeedなど、Webリクエストを処理する環境も更新対象です。
  • 通常のPHP修正版は8.5.12/8.4.27/8.3.36/8.2.35。サポート終了済みのPHP 7.4・8.0・8.1には例外的なソースバックポートが公開されました。
  • Palo Alto NetworksのUnit 42とCloudflareは、実際の攻撃通信を観測したと公表しています。
  • Cloudflareは無料・有料WAF利用者向けの防御を自動展開。Palo Alto NetworksとAkamaiもCVEを明示した防御シグネチャを公表しました。
  • WordPress公式は、今回の脆弱性対応にWordPress本体のアップデートは不要と説明。PHPの実行環境を更新する必要があります。サポート終了版を利用する場合は、新系列への移行を優先します。
項目 内容
公表日 2026年10月21日
対象 PHPランタイム本体。Webリクエストを処理するPHP環境
脆弱性 CVE-2026-109618/CVE-2026-109619
深刻度 2件ともCVSS v4.0 9.2(Critical)
主な危険性 認証不要のリモートコード実行、情報の露出、サービス停止
修正版 8.5.12/8.4.27/8.3.36/8.2.35
サポート終了版 PHP 7.4・8.0・8.1の限定的な修正ソースあり。通常の公式リリースはなく、OS・LTSベンダー提供のパッケージ適用可否を確認
根本対策 稼働環境のPHPを修正版に更新し、適用後の実行バージョンを確認

2件の脆弱性はPHP内部のメモリ管理に起因

CVE-2026-109618(RCE via OOM corruption) は、メモリ不足(Out of Memory:OOM)が発生した際の例外処理に問題があるものです。PHPがリクエストの処理を中断するとき、一部の内部データが初期化されていない状態のまま終了処理から参照され、メモリが不正な状態になる場合があります。PHP公式のアドバイザリでは、認証されていない外部からのリクエストによるRCEをApacheのmod_php環境で実証したと説明しています。

CVE-2026-109619(RCE via stale global state) は、前のリクエストで使用したメモリが解放された後も、その情報への参照がPHPのワーカープロセス内に残る問題です。後続のリクエストで古い参照が使われると、解放済みメモリへのアクセス(Use-After-Free)が発生する可能性があります。PHP公式は、メモリ内情報の露出とRCEを確認し、セッション処理に関係する経路についてはmod_phpとPHP-FPMでRCEを検証したとしています。

どちらもWordPressの特定プラグインだけに存在する問題ではありません。WebサーバーがPHPのリクエスト処理を行う段階で問題が発生するため、WordPress側の入力チェックやアプリケーションコードの修正だけでは対処できない場合があります。

同時期の危険性の高い脆弱性:PHP フレームワーク Laravelに認証回避の重大脆弱性、APIトークンなしで他ユーザーとしてアクセスの恐れ CVSS 9.2 CVE未割当

悪用されるとWebサーバーの権限でコードを実行される恐れ

RCEが成立した場合、攻撃者はPHPのワーカープロセスに与えられた権限で不正な処理を実行できる可能性があります。その権限やサーバーの設定次第では、サイト改ざん、不正なプログラムの設置、設定ファイルや保存情報の読み取り、サービス妨害などにつながります。ただし、脆弱性が存在することと、個別のサイトで実際に情報が流出したことは別です。

PHP開発チームは、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、PHPでWebリクエストを処理する環境に更新を求めています。特にmod_phpでは、認証不要のリクエストでアプリケーションコードの実行前に攻撃が成立する例を示しています。攻撃の再現性や成立条件は、使用するPHPのビルド、拡張機能、Webサーバー構成、メモリ管理方式などで異なります。

実際の攻撃については、Palo Alto NetworksのUnit 42が野外での悪用を観測したと発表しました。CloudflareもPHPの修正版公開前から攻撃通信を検知し、攻撃者が検知を回避するために通信内容を変化させていたと説明しています。IPAの10月21日付事前注意喚起には「IPAとして悪用を確認していない」との記載がありますが、調査主体と公表時点の違いを区別する必要があります。

修正版PHP 8.2~8.5を公開、旧系列への限定的な修正も提供

PHPプロジェクトが正式な更新版として提供しているのは次の4系列です。

PHP系列 2026年10月21日公開の修正版 対応
PHP 8.5 8.5.12 同一系列の修正版へ更新
PHP 8.4 8.4.27 同一系列の修正版へ更新
PHP 8.3 8.3.36 同一系列の修正版へ更新
PHP 8.2 8.2.35 修正版へ更新。2026年末のサポート終了も考慮
PHP 7.4・8.0・8.1 通常の公式リリースはなし PHPセキュリティチームが今回に限り最小限の修正ソースを提供。自社ビルドや提供元のバックポートを確認
PHP 7.3以前 通常の公式リリースはなし OSベンダー等のサポート状況を確認し、サポート対象系列へ移行

PHPセキュリティチームは今回の脆弱性が重大であることから、すでにサポートを終了しているPHP 7.4、8.0、8.1向けにも最小限の修正ソースを例外的に公開しました。

ただし、これらは一般利用者が管理画面から選択できる通常のPHP更新版ではなく、ソースコードをビルドする運用者や長期サポート提供事業者などを想定したものです。PHP 7.4.33と表示されているレンタルサーバーが、自動的に修正済みになったという意味ではありません。

公式のサポートが終了した系列を使い続けると、今回以外の脆弱性修正が受けられないおそれがあります。WordPressなどの公開サイトでは、PHP 8.3以上などサポート対象の系列への移行を優先し、やむを得ず旧系列を使う場合はホスティング・OS提供元による修正済みパッケージの適用を確認してください。

PHP公式は、設定変更やWAFだけで成立する完全な回避策はないと説明しています。session.upload_progress.enabled=0 などで一部の攻撃経路を制限できても、修正済みランタイムの導入が必要です。

Ubuntuが旧PHP向けにも修正パッケージを提供

Canonicalは10月21日、Ubuntuのサポート対象リリースについて今回の2件を修正したPHPパッケージを公開したと発表しました。PHPプロジェクト本体のバージョン表示が古くても、Ubuntu側が脆弱性の修正を取り込んでいる「バックポート」に該当する場合があります。

Ubuntu PHP系列 修正済みパッケージ
Ubuntu 26.04 LTS PHP 8.5 8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS PHP 8.3 8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS PHP 8.1 8.1.2-1ubuntu2.28
Ubuntu 20.04 LTS PHP 7.4 7.4.3-4ubuntu2.29+esm5(Ubuntu Pro/ESM)

Ubuntu 14.04・16.04・18.04についてもESM経由の修正パッケージが案内されています。Ubuntu 20.04 LTS以前の適用にはUbuntu Pro/ESMの利用条件が関係します。パッケージを更新した後は、PHPを利用するサービスの再起動や再デプロイまで確認する必要があります。

一方、上記のUbuntu専用パッケージがそのままロリポップなどの共有レンタルサーバーに適用されるわけではありません。利用中の提供元が公表する更新状況で判断します。

Cloudflare、Palo Alto Networks、Akamaiが仮想パッチを提供

PHPの修正版とは別に、Webアプリケーションファイアウォール(WAF)や侵入防止システム(IPS)のメーカーも、攻撃通信を遮断するためのルールを公開しています。こうした対策は「仮想パッチ」と呼ばれますが、脆弱なPHP本体が修正されるわけではありません。

メーカー・製品 2026年10月21日までに確認した対応 公式公表の状態
Cloudflare WAF php2shellに対応した防御を無料・有料WAF利用者向けに自動展開。リクエストとレスポンスを組み合わせて検査する方式も導入 専用防御の配備を公式発表
Palo Alto Networks Advanced Threat Prevention PlusのFrontier Virtual PatchingでThreat Preventionシグネチャ「543004」を提供(10月20日から) CVEを明示した防御を公式発表
Akamai App & API Protector Adaptive Security Engine「3000991 v1」(PHP Remote Code Execution Attack Detected)を提供 CVEを明示した防御を公式発表
Sophos Counter Threat Unitが緊急注意喚起。SophosLabsは脅威監視と必要に応じた検知・防御の提供を案内 専用シグネチャの配備までは確認できず
攻撃遮断くん/WafCharm WAFによる脆弱性対策機能は提供。ただし今回の2件に対応する個別の公式発表は確認できず 今回の専用対応は未確認
Check Point 脆弱性の公式解説を公表。専用IPS防御の配信完了までは確認できず 注意喚起を確認、個別シグネチャは要確認
Fortinet/Trend Micro/CiscoのIPS製品 今回のCVEに対応する具体的なシグネチャIDや配信済みの一次情報は今回の調査で特定できず 今回の専用対応は未確認

Cloudflareは10月21日の公式ブログで、php2shellを対象とした防御を一般公開の約9時間前に配備し、同日03:02 UTC(日本時間12:02)からWAF利用者にデフォルトで適用したと説明しています。リクエストだけでなくHTTPレスポンスを組み合わせて分析する「full transaction detection」と、悪意あるレスポンスを遮断する機能も導入しました。公式ブログにはPHP向けの複数のWAFルールIDが掲載されています。管理者はSecurity Analyticsのイベントを確認し、Managed Rulesetの無効化や広範囲のSkip設定によってPHP向け防御を意図せず除外していないか点検できます。

Palo Alto NetworksのUnit 42は、次世代ファイアウォール向けの防御に加え、Cortex製品による調査・検知、Cortex Xpanseによる外部公開資産の確認も案内しています。同社は自社テレメトリから、外部公開された潜在的な影響対象を2,260万件超と推計しました。これは実際の侵害件数や確定した脆弱サーバー台数ではありません。Akamaiは今回の2件のCVE番号を明記した検知ルールを公表しました。いずれの製品も契約プランや適用条件、ルールの動作設定によって実際の保護範囲が異なります。

WordPress向けセキュリティサービスのWordfenceは10月21日、php2shellへの緩和策を適用するため一部サービスを一時停止したとステータスページで案内しました。これはWordPress向けプラグインがPHP本体を修正した、またはすべてのWordPressサイトに専用防御が適用されたことを意味しません。

国内ではレンタルサーバーやWebサービスが予防的な停止・更新を実施

さくらインターネットは10月21日23時から、レンタルサーバーやマネージドサーバーなどを対象にPHPのバージョンアップ作業を実施すると公式に告知しました。一方、ロリポップは修正版公開前にユーザー専用ページ、FTP、APIなどの機能を順次停止し、必要に応じて顧客のWebサイトを制限する可能性も示しています。ロリポップの予防措置を、修正版の適用完了と混同してはいけません。

お名前.comも同日19時から翌22日10時までレンタルサーバーの緊急メンテナンスを告知していますが、当該告知での作業内容は「システムの保守作業」であり、今回のPHP脆弱性へのパッチ適用と明示されたものではありません。

PHPを利用するWebサービスでは、BASE/PAY IDやコドモンが安全確保のため緊急停止を公表しました。こうした措置は脆弱性を悪用された被害の発生を直接示すものではなく、修正や安全確認までの予防対応と区別する必要があります。

関連記事:BASE/PAY IDの緊急メンテナンス/コドモンの全サービス停止

WordPress公式は「WordPress本体の更新は不要」と説明

WordPress.orgは10月21日、「Critical PHP Security Release」と題する注意喚起を公開しました。今回の2件はPHP本体に存在する脆弱性であり、今回の対応を目的としたWordPress本体の更新は不要で、予定もないと説明しています。WordPress本体やプラグインを最新版にしても、PHPの脆弱性は解消できません。

PHPバージョンはWordPress管理画面の「ツール → サイトヘルス → 情報 → サーバー」で確認できます。レンタルサーバー側でパッチ更新が行われる場合もありますが、利用者自身によるPHPの系列変更が必要な事業者もあります。

PHP 7.4などの利用者はメジャーバージョンアップを優先

PHP 7.4や8.1などのサポート終了版を利用している場合、原則としてサポート対象のPHP系列へのメジャーバージョンアップが必要です。今回に限って例外的な修正ソースやUbuntu等のバックポートが提供されても、PHP本体の通常のセキュリティサポートが再開したわけではありません。

レンタルサーバーがPHP 8.3.35から8.3.36へのパッチ更新を自動適用していても、PHP 7.4から8.3への系列変更まで自動で実施するとは限りません。管理画面で対応可能なPHPを確認し、運用中のWordPress・テーマ・プラグインとの互換性を検証して切り替えます。一方、Ubuntu Proなどの提供元が修正をバックポートした環境では、当該パッケージを適用することでも今回の2件の対策となるため、バージョン番号だけで一律に未修正と判断しないでください。

サイト管理者が確認する項目

  1. PHPの実行環境を確認する。 WordPressのサイトヘルス、ホスティング管理画面、コンテナ・OSのパッケージ情報を照合します。CLIのPHPとWebリクエストを処理するPHPは異なる場合があります。
  2. 修正版の適用を確かめる。 PHP 8.2~8.5を使用中なら、各系列の修正版を適用します。旧PHPの場合はホスティング事業者のバックポート有無を確認し、原則としてサポート対象系列へ移行します。
  3. バックアップと互換性テストを行う。 メジャーバージョン変更時には独自テーマ、プラグイン、管理画面、フォーム、通知メール、決済、画像アップロード、REST API、予約投稿などをステージングで確認します。
  4. 既存の侵害を調査する。 PHPワーカーの異常終了だけでなく、大量のフォーム送信、リクエスト初期化時のメモリ不足、Webサーバー権限で起動された予期しないプロセス、不審ファイルの作成などを点検します。
  5. 更新できないシステムは公開を制限する。 WordPress公式は自主管理サーバーを速やかに更新できない場合、一時的にオフラインにすることも検討するよう案内しています。WAFやIPSは更新までの追加防御として利用します。

PHPのメジャーバージョンを変更するために、MySQLを同時にメジャーアップグレードする必要は通常ありません。データベースの変更は互換性と運用計画を確認し、別の作業として管理できます。

Datadog、攻撃の再現と検知時の注意点を公表

Datadog Security Labsは10月21日、今回のPHP脆弱性を独自に再現し、アプリケーション側の認証処理が始まる前に攻撃が成立するケースを確認したと発表しました。session.upload_progress.enabled=0 の設定だけでは今回の脆弱性を解消できず、脆弱なPHP実行環境を修正する必要があるとしています。

また、攻撃が成立してもPHPワーカープロセスが必ず異常終了するわけではないと指摘しています。企業のCSIRTやサーバー管理者は、メモリ不足・大量のフォーム送信に関連するログに加え、PHPプロセスからの予期しないシェル起動などを調査する必要があります。クラッシュログが見つからないことだけで安全性を判断することはできません。

Google Cloudも製品別の更新方法を公表

Google Cloudは10月21日、PHPの修正状況と利用者が実施する作業をサービス別に案内しました。PHPを組み込んだ独自コンテナや自社管理のランタイムを使用する場合、基盤クラウド側の更新だけで脆弱性が修正されるわけではありません。

Google Cloudのサービス 修正の適用方法
App Engine Standard(PHP 8.2以降のサポート対象ランタイム) 修正版ランタイムに自動更新
App Engine Flexible 利用者がPHPを更新して再デプロイ
Cloud Run/Cloud Run functions 自動ベースイメージ更新が有効なら自動対応。独自イメージや自動更新無効の場合は再ビルド・再デプロイ
Google Kubernetes Engine(GKE) PHP入りのコンテナイメージを更新し、Podを再デプロイ

情報システム部門はWordPressだけでなく、PHPを使用する問い合わせフォーム、社内ポータル、API、委託先が提供するWebアプリケーション、コンテナイメージまで対象として修正版の適用を確認してください。

出典