php2shellとは、PHP本体の未認証RCE(CVE-2026-109618とCVE-2026-109619)の影響と対策

Webサーバー側の言語として広く使われるPHPの本体に、認証なしでサーバー上のコード実行につながる脆弱性が2件見つかりました。CVE-2026-109618とCVE-2026-109619で、この2件をまとめた通称がphp2shellです。特定のCMSやフレームワークの欠陥ではなく、PHPがHTTPリクエストを受け取って解析する段階で起きるため、アプリケーションのコードが動く前に攻撃が成立しうる点が問題です。PHPプロジェクトは2026年10月21日に修正版8.5.12、8.4.27、8.3.36、8.2.35を公開し、すべての利用者に直ちに更新するよう求めています。

この記事は、PHPで動くWebサイトやアプリを運用する開発者とインフラ担当に向けて、2件の脆弱性の中身、影響を受ける版と実行形態、更新できない間の暫定策、影響確認の手順を、PHPの公式アドバイザリ、CVEレコード、NVD、CISAなどの一次情報で整理します。攻撃を再現する手順やペイロードは扱いません。事実は執筆時点(2026年10月27日)で確認できた範囲に限ります。

php2shellは2件のPHP本体の脆弱性の通称#

php2shellは単一の攻撃ツールの正式名ではなく、CVE-2026-109618とCVE-2026-109619をまとめて呼ぶ通称として使われています。オランダのNCSC-NLは、この2件の運用情報と影響製品の一覧をphp2shellという名前のGitHubリポジトリで公開しています。PHPプロジェクト自身の告知はこの通称を使わず、CVE番号とGitHub Security Advisory(GHSA)の番号で案内しています。セキュリティ企業watchTowrは、協調開示の前に詳細がネット上に流出し、その後に出回った概念実証ツールの名前がphp2shellだったと説明しています。

公開までの経緯は次のとおりです。PHPプロジェクトは10月20日に、翌21日14:00 UTCに重大な脆弱性を修正するセキュリティリリースを出すと予告しました。10月21日に修正版とアドバイザリを公開し、同日CVEレコードも公開されました。10月23日には、セッションのアップロード進捗機能について追加の注意喚起を出しています。

PHPの2026年10月21日のアドバイザリは、PHP 8.5.12、8.4.27、8.3.36、8.2.35が未認証のリモートコード実行につながる2件の重大な脆弱性を修正したとし、すべての利用者に直ちに更新するよう求めています。対象はWebリクエストを処理するすべてのインストールで、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含み、アプリケーションのコードが動く前に未認証のリクエストで攻撃が始まる実証があるmod_phpのリスクが最も高いと記載しています。

CVE-2026-109618はメモリ不足の処理で壊れた状態が残る脆弱性#

PHPは、リクエストの処理中にメモリの上限に達すると、longjmp()という仕組みで現在の処理から一気に抜け出し、そのリクエストの処理を打ち切ります。CVEレコードによれば、一部の処理はこの中断を想定しておらず、リクエスト用のメモリを初期化しないまま次のメモリ確保に進む箇所がありました。そこで処理が打ち切られると、初期化されていないメモリが残り、リクエストの後始末の処理がそのメモリを有効なデータとして読んだり、その値で処理を分岐したりします。メモリ不足を意図的に起こす方法は複数あり、この状態を安定して起こせるため、リモートコード実行につながります。

GHSAによれば、修正ではメモリ不足の際のlongjmp()をやめ、遅延して処理する軽いメモリ不足と即座に止める重いメモリ不足に分ける形へ改めています。確認された影響は、Webサーバーのワーカーのアカウント権限での未認証リモートコード実行です。実証はmod_phpに対して、PHPの既定の入力制限とメモリ上限、複数ワーカーを持つ通常のprefork構成で行われています。ワーカーの数や通信量は試行回数を変えるだけで、条件そのものはなくならないとされています。

CVE-2026-109619は前のリクエストの状態が次に残る脆弱性#

PHPには、処理の途中で一時的にリクエスト用のメモリを指す全体状態(グローバルな状態)がいくつもあります。CVEレコードによれば、場合によってはこの状態が正しくリセットされなかったり、リセットのあとに再び値が入ったりして、すでに解放されたメモリを指したまま残ります。同じワーカーが次のリクエストを処理するとき、初期化が終わる前にその古い状態を読んで処理を分岐し、リモートコード実行につながります。確認された影響には、解放後のメモリ使用とメモリ内容の漏えいも含まれます。

この脆弱性は、古い状態を作るリクエストと、それを使ってしまうリクエストが同じワーカーに届くことが条件です。GHSAは、状態を作る経路として、PHP 8.5で有効にできるfatal_error_backtraces(致命的エラー時のバックトレース)を最も強く実証された例に挙げ、既定で有効なセッションのアップロード進捗機能(session.upload_progress)の経路もmod_phpとPHP-FPMの両方でコード実行を検証しています。リクエスト初期化の前に設定を上書きする仕組み(mod_phpの.htaccessでのphp_value指定や、フロントエンドからPHP-FPMへ渡すPHP_VALUE)も、古い状態を使ってしまう入り口になりうるとしています。

影響を受ける版と修正版#

CVEレコードに記載された影響範囲と修正版は、2件とも同じです。

PHP 8.1以前について、PHPのアドバイザリは、PHPプロジェクトからの更新はもう提供されないとしたうえで、一部のディストリビューションやLTSベンダーが修正を移植(バックポート)していると案内しています。あわせて、ソースからビルドする利用者向けに、PHP 7.4、8.0、8.1への最小限のソース修正を提供したとしています。CVEレコードに影響版として載るのはサポート中の4系列だけですが、PHP 8.1以前を影響外と読むのは誤りです。watchTowrは、PHP 5を含む古い系列も影響を受けることを確認したとしています。開発中のPHP 8.6.0 RC4にも修正が入っていますが、PHPは本番環境では使わないよう明記しています。また、PHP 8.2は2026年12月31日にサポートが終わる予定です。今回8.2.35へ更新しても、年内にサポート中のブランチへ移る計画が必要です。

ディストリビューションのパッケージは、上流の版番号を上げずに修正だけを取り込む場合があります。Red HatのようにCVEごとの状況ページを持つ配布元では、版番号ではなく配布元のアドバイザリで修正済みパッケージかどうかを判定します。

実行形態ごとのリスクの違い#

同じPHPでも、Webサーバーとどうつながるか(SAPI)によって、成立の確からしさが異なります。GHSAの記載を実行形態ごとにまとめると次のとおりです。

mod_phpのリスクが最も高いのは、ApacheのワーカープロセスがPHPを組み込んだまま複数のリクエストを処理し、起動処理の失敗後も後始末が走るためです。PHP-FPMは起動処理に失敗すると子プロセスを終了させるため、CVE-2026-109618の成立はmod_phpより確認されていません。ただし、PHPはどの形態も更新の対象から外していません。実行形態の違いは更新の優先順位を考える材料であり、更新を省く理由にはなりません。

CVSSと悪用の状況#

PHPが付けたCVSS v4.0は両件とも9.2で、ベクトルはCVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:Nです。ネットワーク越しに認証も利用者の操作もなしで狙える一方、攻撃の複雑さが高く(AC:H)、成立に前提条件がある(AT:P)と評価されています。同じワーカーに要求を届ける必要があることや、PHP-FPMの経路では条件に合うアプリケーション側の処理が要ることや、ビルドや拡張機能、メモリ配置で成功率が変わることが、この評価の背景です。NVDはCVSS v3.1で独自に評価しており、CVE-2026-109618を9.8(AC:L)、CVE-2026-109619を8.1(AC:H)としています。

悪用の状況は、情報源によって表現が異なります。

• PHPのアドバイザリは、mod_phpで未認証のリクエストから攻撃が成立する実証(demonstrated exploit)があるとしていますが、実環境での悪用には触れていません
• CISAのアラート(10月21日公開、10月23日更新)は、公開時点で実環境での悪用の成功を確認していないとしたうえで、直ちに修正を適用するよう強く求めています
• 2026年10月27日に確認したCISAのKEVカタログ(カタログ版2026.10.23)には、両件とも載っていません。CVEレコードに付いたCISAのSSVC評価(10月21日時点)も、悪用はnoneです
• watchTowrは、自社のハニーポット網で10月21日から両件の悪用の試みを観測したと公表しています。ハニーポットでの観測は攻撃が来ていることを示すもので、実際の組織で侵害が成功したことの確認とは区別して扱います

公的機関による悪用の確認とKEVへの収録は、執筆時点ではありません。ただし、修正前に詳細が流出し、修正公開の当日から悪用の試みを観測したという民間の報告がある以上、KEV収録を待たずに更新するのが妥当です。KEVやEPSSを使った優先順位の付け方は、次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

すぐに更新できない場合の暫定策#

PHPのアドバイザリは、更新だけが完全な対策で、次の設定は特定の攻撃経路への露出を減らすものの、インストールを安全にするものではないと明記しています。設定は、アプリケーションから上書きできない形で入れ、変更後はすべてのワーカーを再起動します。

CVE-2026-109618向けの措置は次のとおりです。

• memory_limit=-1を、アプリケーションが上書きできない形(FPMプールやApache設定のphp_admin_valueなど)で設定します。PHPの側で起きるメモリ上限の失敗はなくなりますが、下層のメモリ確保が失敗すれば脆弱な経路に到達しうるため、これも完全な対策ではありません
• memory_limit=-1はリクエストごとのメモリ上限を外す設定なので、ホスト全体のメモリ枯渇への備えが別に要ります。PHPは、コンテナやcgroupのメモリ制限を可用性の境界として使い、できれば影響を受けたワーカーだけを止める方針にするよう案内しています。GHSAは、cgroupの制限もメモリ確保の失敗を防ぐ保証はなく、完全な対策ではないとしています
• post_max_sizeを小さく保ちます。PHPは、ファイルアップロードが不要なアプリケーションで8M、必要な場合で32Mを目安に挙げ、upload_max_filesizeをpost_max_sizeより小さくするよう案内しています
• Webサーバーやプロキシの段階で、デコード後の要求サイズ、入力項目の数、マルチパートの部品数、ヘッダーの数、入れ子の深さに上限をかけます。PHPは、有効なContent-Lengthを持たない要求にもこの上限が効くようにするよう求めています
• RLIMIT_ASやRLIMIT_DATAでメモリを制限する方法に置き換えてはいけません。脆弱なメモリ確保の失敗を自ら起こすためです
• GHSAは、max_input_nesting_levelの引き下げと、マルチパート形式を使わないアプリケーションでのフロントエンドでの遮断も挙げています

CVE-2026-109619向けの措置は次のとおりです。

• session.upload_progress.enabled=0を設定し、すべてのワーカーを再起動します。php.ini、FPMプール、サーバー設定など、リクエストの解析より前に効く場所で設定し、ini_set()やFPMの.user.iniには頼りません
• PHP 8.5では、fatal_error_backtraces=0を設定し、すべてのワーカーを再起動します。PHPは、これで塞がるのは確認済みのバックトレース経路だけだとしています
• error_reporting、display_errors、エラー抑制の@でエラー表示を隠しても効果はありません

PHPは10月23日に、セッションのアップロード進捗機能について追加の注意喚起を出し、修正版へ更新したあとも、次の定例のバグ修正リリースまでsession.upload_progress.enabled=0にするよう勧めています。php2shellの2件とは別の、コード実行につながる経路(CVE-2026-115560)が残っているためで、次のリリースで詳しく公表するとしています。PHPによれば、この経路は、設定でsession.serialize_handlerをphp_binaryかphp_serializeにしたアプリケーションが、session_start()の前にini_set()でphpへ切り替え、かつアップロード進捗機能が有効なままという、まれな設定とコードの組み合わせでのみ成立します。実行時にシリアライズ方式を切り替えないアプリケーションは機能を有効のままにできるとしています。GHSAも、機能が不要なら更新後も無効のままにしておくのが賢明だとしています。

WAFで防げる範囲と防げない範囲は、次の記事で整理しています。

あわせて読みたい

WAFの役割と限界、正しい使い方。シグネチャと振る舞い、回避される前提、根本対策との補完

運用側がとる初動#

公開しているWebサーバーでPHPを動かしている場合、更新と影響確認を並行して進めます。次の順序で手を付けます。

更新の前に設定やファイルを変えると、調査に使う材料が消える場合があります。侵害を疑う材料があるときは、ログと設定ファイル、不審なファイルを先に保全します。初動の全体像は次の記事で整理しています。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

影響確認と検知のポイント#

この2件には、アプリケーションのコードが動く前の段階で到達する経路があるため、アプリケーションのログだけでは検知できません。GHSAも、ログに異常がないことは安全の証明にならないとしています。次の観点を組み合わせて確認します。

• PHPのワーカープロセスがシェルを起動したり、ツールをダウンロードしたりしていないか。CISAはこれを監視対象に挙げ、10月23日の更新でSIGMAの検知ルールを追加しています
• PHPのワーカーが異常終了していないか、メモリ上限に達したエラーが急に増えていないか
• 極端に大きい、または深く入れ子になったマルチパート形式のリクエストが届いていないか
• Webの公開ディレクトリに見覚えのないPHPファイル(Webシェル)が置かれていないか、cronや新しいアカウントなど永続化の仕込みがないか
• PHPのプロセスから説明のつかない外部への通信が出ていないか

コード実行の権限はWebサーバーのワーカーのアカウントです。ワーカーのアカウントが書き込める範囲を絞り、公開ディレクトリでのスクリプト実行を制限しておくと、侵入された場合の被害を小さくできます。Webシェルを置かせないための保存の設計は次の記事で、サーバー側の堅牢化は続く記事で整理しています。

あわせて読みたい

ファイルアップロード機能の脆弱性と対策。Webシェルを置かせないための検証と保存の設計

あわせて読みたい

サーバーのハードニング基礎。最小化・最小権限・更新・設定堅牢化をCISベンチマークから学ぶ

確認チェックリスト#

対応の抜けを防ぐための確認項目を整理します。

まとめ#

php2shellは、PHP本体のCVE-2026-109618とCVE-2026-109619の通称です。前者はメモリ不足でリクエストの処理が中断されたあと、初期化されていないメモリを後始末の処理が使ってしまう欠陥で、後者はリクエストのメモリを指したままの全体状態が解放後に次のリクエストで使われる欠陥です。どちらもアプリケーションのコードが動く前に成立しうる未認証のリモートコード実行で、影響は8.2から8.5の各系列の修正版より前の版、修正版は8.5.12、8.4.27、8.3.36、8.2.35です。執筆時点でCISAは悪用の成功を確認しておらずKEVにも未収録ですが、修正前の流出と民間からの悪用の試みの観測報告を踏まえ、更新とワーカーの再起動を最優先にし、更新前の侵害を前提にした点検を合わせて行う判断が妥当です。脆弱性の検証は、許可された自組織の資産に対してのみ行います。第三者のシステムを対象にする場合は、所有者や運用者からの明示的な事前許可を得たうえで、不正アクセス禁止法などの適用法令やホスティング事業者の利用規約を守って実施します。