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はWordPressなどのWebサイトや企業の業務システムでも広く使われており、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 8.1以前にはPHPプロジェクトからの公式更新はありません。
  • Palo Alto NetworksのUnit 42とCloudflareは、実際の攻撃通信を観測したと公表しています。
  • Cloudflareは無料・有料WAF利用者向けの防御を自動展開。Palo Alto NetworksとAkamaiもCVEを明示した防御シグネチャを公表しました。
  • WordPress本体やプラグインだけを更新してもPHP本体の脆弱性は修正できません。サーバーで稼働するPHPの更新が必要です。特にPHP 7.4などサポート終了版の利用者は、サポート対象の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 8.1以前はPHPプロジェクトからの修正提供対象外。OS・商用サポート提供元によるバックポートの有無は別途確認
根本対策 稼働環境の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側の入力チェックやアプリケーションコードの修正だけでは対処できない場合があります。

悪用されると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公式が案内する修正済みバージョンは次のとおりです。

PHP系列 修正済みバージョン 対応
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 8.1以前 PHPプロジェクトからの修正版なし サポート対象系列へ移行。商用サポートによるバックポートは提供元に確認

緩和策はなし8.1以前バージョンはバージョンアップ【必須】

PHP公式は、今回の2件について完全な緩和策はなく、PHP自体の更新が安全な対策であると説明しています。パッケージ管理されたLinux環境ではディストリビューションが修正をバックポートする場合があり、その際は表示上のPHPバージョン番号だけで適用状況を判断できないことがあります。利用するOSやホスティング事業者のセキュリティ告知と照合してください。

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件に対応する個別の公式発表は確認できず 今回の専用対応は未確認
Fortinet/Trend Micro/Check Point/CiscoのIPS製品 本件のCVEに対応する具体的なシグネチャIDや配信済みの一次情報は今回の調査で特定できず 今回の専用対応は未確認

Cloudflareは10月21日の公式ブログで、php2shellを対象とした防御を一般公開の約9時間前に配備し、同日03:02 UTC(日本時間12:02)からWAF利用者にデフォルトで適用したと説明しています。通常のリクエスト検査では判別しにくい攻撃に対して、HTTPレスポンスの内容も利用して検知・遮断する仕組みを新たに導入しました。同日のWAF更新履歴では、Cloudflare Managed Rulesetに4件(Block 2件、Log 2件)、Free Rulesetに2件(Block)の追加が掲載されています。

Palo Alto NetworksのUnit 42は、次世代ファイアウォール向けの防御に加え、Cortex製品による調査・検知、Cortex Xpanseによる外部公開資産の確認も案内しています。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はサーバー側でPHPを使いますが、WordPress本体やプラグインを最新版に更新しても、今回のPHP本体の脆弱性は修正されません。PHPの更新はサーバー運用者またはホスティング事業者が担当します。WAFの利用も修正版の適用を不要にするものではありません。

  1. 稼働中のPHPを確認する。 WordPress管理画面の「ツール → サイトヘルス → 情報 → サーバー」でPHPバージョンを確認します。管理画面に入れない場合はレンタルサーバー側の管理画面や事業者の案内を確認します。
  2. サポート終了版を使用している場合は、PHPのメジャーバージョンアップが必須です。 PHP 7.4や8.1など、今回の公式修正版が提供されない系列を使用しているWordPressサイトは、パッチを待つだけでは脆弱性を解消できません。PHP 8.3以上など、WordPressと互換性のあるサポート対象系列へ移行し、その系列の修正版を適用する必要があります。レンタルサーバーが同一系列内のパッチを自動適用していても、7.4から8.3などのメジャーバージョン切り替えまで自動で行うとは限りません。ロリポップなどの利用者は、サーバー管理画面で自ら切り替える操作が必要です。
  3. サポート対象系列の利用者も、修正パッチの適用を確認する。 PHP 8.2~8.5など修正版が提供される系列を利用中なら、必ずしも別のメジャー系列へ上げる必要はありません。同一系列の修正版(例:PHP 8.3.36)への更新で今回の脆弱性に対応できます。レンタルサーバー事業者が自動適用する場合もあるため、適用完了の告知と実際の稼働バージョンの両方を確認します。
  4. メジャーバージョン変更前にバックアップと動作検証を実施する。 PHP 7.4から8.3などの切り替えでは、独自テーマやプラグインの互換性問題によってサイトが正常に動作しなくなる場合があります。バックアップを確保し、ログイン、記事表示、フォーム送信、通知メール、決済、画像アップロード、予約投稿、REST APIなどをステージング環境で検証してから本番環境を更新します。
  5. 侵害の兆候を調査する。 更新前の期間に不審な通信、PHPワーカープロセスの異常終了、想定外のファイル作成・変更、管理者アカウントの追加などがないか、取得可能なログを点検します。WAFの遮断実績だけをもって侵害がなかったと判断しないでください。
  6. 更新できない場合は公開範囲を制限する。 外部アクセスの制限や一時停止を検討し、WAFやIPSは追加の防御策として利用します。今回の2件について、WAFのみで完全な対策が成立するとは開発元は説明していません。

PHPの更新にあわせてMySQLを同時にメジャーバージョンアップする必要は通常ありません。データベースの更新は、WordPress・プラグインとの互換性を考慮し、PHPの更新とは別の変更管理として実施できます。

企業の情報システム部門は、WordPressだけでなく、PHPで構築された問い合わせフォーム、社内ポータル、API、レンタルサーバー、コンテナ、業務システムなども対象に、実際に稼働するPHPの修正状況を確認する必要があります。

出典