PHPの重大脆弱性「PHP2Shell」の影響と対策｜ARTEX×GLMによるアプリのRCE検証

PHP2Shellとは、PHP本体のリクエスト処理に見つかった、認証前のリモートコード実行（RCE）につながる2件の重大脆弱性の総称です。2026年10月21日、CVE-2026-109618とCVE-2026-109619に対応する緊急修正版が公開されました。PHPを使うWebシステムの運用者には、利用環境の確認と速やかな修正適用が求められています。PHP公式の発表

一方、PHPアプリには、入力処理やアップロード機能の不備からRCEに至る問題もあります。当社はARTEXとGLMを使い、自作のPHPアプリでコマンド注入とアップロード経由のRCEを検証しました。タスク作成から検出結果の登録までは、DB実測で104秒と305秒でした。

今回のARTEX検証は、アプリ側に用意した弱点を対象にしたものです。PHP2Shell自体の再現は含めていません。PHP本体の緊急更新とアプリ側の修正を、それぞれの原因に合わせて進める必要があります。

PHP2Shellの2件の脆弱性は、PHP内部のメモリ管理とリクエスト処理に関わります。認証前のHTTPリクエストからコード実行に至る経路が確認され、CVSS v4.0の深刻度はいずれも9.2（Critical）です。

2件の主な違いは、不正な状態が生じる場面にあります。

ワーカーは、サーバー側でリクエストを処理するプロセスです。後者は、一つのプロセスが複数のリクエストを順に受け持つ際の状態管理に関係します。どちらも単独でRCEにつながる問題として報告されています。

とくにApacheのmod_phpでは、アプリの処理が始まる前のリクエスト解析も攻撃の入口になります。PHP-FPMも影響を受け、古い内部状態が残る問題ではFPMでのRCE経路も公式に実証されています。PHP公式の影響範囲

影響はWebリクエストを処理するPHP環境に及び、CGIや製品に組み込まれたランタイムも含みます。実際の攻撃の成立条件は、PHPの版、設定、ワーカーの動作などで変わりますが、mod_php以外の構成でも対応が必要です。CERT-EUの勧告

IPAも10月21日付で、利用システムの把握と修正版の速やかな適用準備を要請しました。IPAの事前告知

優先するのは、実際にサービスが使っているPHPへの修正適用です。AIによる検証結果を待たず、利用しているOS、ホスティング、製品の修正情報を確認してください。

PHP公式が10月21日に公開した修正版は、次の4系列です。利用中の系列に対応する修正版、または修正を含む後続版へ更新します。

配布元が既存の版へ修正を取り込むバックポートもあります。版番号だけで判断せず、配布元の修正済みパッケージ情報を確認します。コンテナや製品に同梱されたPHPは、ホスト側のPHPを更新するだけでは置き換わらないため、個別に対応が必要です。NCSC-NLの対応情報

PHP 8.1以前は通常の公式サポートが終了していますが、今回PHPのセキュリティチームは7.4・8.0・8.1向けの限定的なソース修正も提供しました。通常サポートの再開ではないため、配布元の対応を確認しつつ、サポート中の系列への移行を進めます。PHP公式の旧系列向け案内

暫定策として挙がる session.upload_progress.enabled=Off は、確認されている一部の攻撃経路を抑える設定です。リクエスト解析前に有効になる設定箇所で変更し、全ワーカーを再起動する必要があります。ただし、2件の脆弱性全体を解消するものではありません。

恒久対策は修正の適用です。すぐに適用できない場合は、サービス提供者と相談し、公開範囲の縮小や一時停止も含めて暫定対応を判断します。CERT-EUの緩和策と制約

当社の検証では、アプリ側に既知の弱点を組み込んだPHP教材を使い、2種類のRCEでサーバー側の実行を確認しました。検出結果であるfindingは、それぞれ1件登録されています。

RCEとは、外部からの操作によって、サーバー上で本来認めていないコードやコマンドを実行できてしまう状態です。PHP2Shellと今回の教材では、結果として生じるRCEは共通していても、原因となる層が異なります。PHP本体の問題にはランタイムの更新、教材の問題にはアプリの実装やサーバー設定の修正が必要です。

2つの教材では、指定した情報と、AIが探索する範囲を変えました。

所要時間は各教材で1回ずつの成功例を測った値です。

ARTEXは、LLMを使うエージェントがツールを操作し、対象を調べ、結果を報告するペネトレーションテストの基盤です。今回はGLMを組み合わせた検証用の構成で、HTTPリクエストと応答をもとにアプリの動作を調べました。対象アプリの内部コードを読むことは前提にしていません。

最初の教材は、利用者の入力をOSコマンドへ安全に渡していない診断機能です。2つ目は、画像アップロードや画像一覧などの画面を持ち、ファイルの種類の制限と保存先の実行設定に弱点を持つPHPアプリです。単一の入力を変える試験から、複数の操作をつなぐ試験へ進めました。

対象は当社が管理するローカルの検証環境に限定しています。ARTEXと対象アプリをローカルに置くことと、推論モデルへの通信を含めて完全にオフラインにすることは、別の設定・確認事項です。

人は事前にアプリと環境を用意し、意図した弱点が成立することを手動で確認しました。2つ目の教材では、手動確認に使った検証ファイルを削除し、既存ファイルがAIの結果に影響しない状態に戻してから、対象と検証目標を指定しています。

ARTEXが担当したのは、Webアプリの調査、候補となる操作の試行、応答と実行結果の確認、findingの登録です。2つ目では、アップロード機能の場所や具体的な回避方法を知らせずに進めました。

最初の教材では、診断機能への入力を変更すると、通常の応答に加えてOSコマンドの出力が返りました。 指定した入力箇所から、アプリに本来ないコマンド実行が成立した結果です。

通常の入力では、アプリが想定する通信確認の結果だけが返りました。入力を変えると、サーバー上で動いた処理のユーザー情報が応答に現れました。記録上、応答サイズも251バイトから305バイトへ変化しています。

成立を示す証拠は、54バイトの増加そのものではなく、確認コマンドに対応する出力が追加されたことです。応答サイズやHTTPステータスだけでは、エラー表示や入力文字列の反映との区別がつきません。

AIの報告は、正常時と検証時のリクエスト・応答を照合して評価します。検証者による事前の手動確認と合わせて、入力の変化とサーバー側の出力を対応づけられることが、この教材での実証を支えています。

返ってきたユーザー情報は、Webアプリを動かすユーザーの権限でコマンドが実行されたことを示します。管理者権限の取得や、コンテナの外への侵害までを確認した結果ではありません。

OSコマンドインジェクションは、外部入力によって実行するコマンドの意味が変わる問題です。影響は、そのプロセスの権限やアクセスできる情報によって変わります。CWE-78

実サービスで評価する際は、実行権限に加えて、参照可能なデータや操作可能な機能を確認します。今回の教材で得られた結果も、実行できた処理とその権限を基準に捉える必要があります。

2つ目では、ARTEXがアップロード機能を見つけ、ファイル制限の不備と保存先の実行設定を組み合わせてRCEを確認しました。 具体的な脆弱箇所を知らせない状態から、複数の操作をつないで実行確認へ進んでいます。

教材には、トップページ、アップロード、画像一覧、案内ページなど複数の入口を用意しました。ARTEXに伝えたのは対象ホストとRCEを調べる目標で、脆弱な機能の場所や制限の回避方法は伏せています。

ARTEXはサイトを調べ、アップロード機能に到達しました。その後、ファイルの種類を変えて受理・拒否の違いを確認し、保存後のファイルにもアクセスしています。特定の拡張子が拒否されると別の名前や拡張子の扱いを調べ、実行へ至る経路を探索しました。

具体的な弱点を教えずに進んだ点が、この教材での成果です。ただし、対象とRCEという目標は指定しており、アプリ全体からあらゆる種類の問題を自由に探した試験ではありません。

教材では、一部の拡張子を拒否する制限に対し、別の名前のファイルが保存される状態でした。さらに、その保存先ではWebサーバーがファイルをPHPのコードとして処理する設定になっていました。この2つの条件がつながり、アップロードから実行へ至っています。

ファイルを受け付けることと、その内容をコードとして実行することは別の段階です。受理される名前や実行される形式は、サーバー設定と配置先に依存します。今回の教材の動作を、そのまますべてのPHP環境に当てはめることはできません。

CWE-434も、危険な種類のファイルがアップロードされ、環境側で処理される問題を扱っています。制限を入力欄だけで完結させず、保存・配信・実行までの経路として確認する必要があります。

ARTEXは、アップロードした検証用コードにアクセスし、実行ユーザーなどを返すコマンドの出力を確認しました。通常の画像をアップロードした場合には同じ出力が得られないことも比較しています。

この記録によって、ファイルの受理、保存先へのアクセス、サーバー側でのコード実行という流れをたどれます。「ファイルが保存された」という段階にとどまらず、保存後にどう処理されたかまで確かめた結果です。

報告には再現条件、影響、対策も記載されています。レビューでは、報告の記述に対応する通信と出力があるかを確認し、原因となる設定や実装の修正へつなげます。

2つの教材では短時間でfindingが登録されました。実用性を評価するには、所要時間に加えて、書き込みを伴う操作や審査処理の記録も確認する必要があります。

実行確認に使ったのは、実行ユーザーや環境の情報を表示するコマンドです。データの削除やサービス停止を目的とする操作は、今回の確認には必要ありませんでした。

一方、アップロード経由の試験では、検証用コードを対象へ保存しています。確認コマンドは参照用途でも、試験全体にはファイルの書き込みが含まれます。

同様の検証を行う場合は、配置してよい場所とファイル、終了後の削除・初期化まで決めます。前回の検証ファイルが残っていると、次の試行で新たに弱点を見つけたのか、既存のファイルを使ったのかが分からなくなります。

最初の試験は、ブロック0件、却下0件でした。2つ目では、操作を判定するモデルの応答形式に不備があり、審査がタイムアウトした記録が1件あります。

これは、危険な操作と判断して却下した記録とは異なりますが、判定処理が正常に完了しなかった事象です。検証記録上はルールを緩和せずに実行確認へ進んだものの、2つの試験をまとめて「審査上の問題はゼロ」とは評価できません。

運用時は、判定に失敗した際にどの操作が停止・継続したかも確認します。脆弱性を発見できたことと、操作審査が正常に機能したことは、それぞれの記録から判断する必要があります。

DB上のタスク作成時刻からfinding登録時刻までを測ると、コマンド注入の教材は104秒、アップロード経由の教材は305秒でした。アプリの作成、環境設定、手動確認、初期化の時間は含みません。各教材で1回ずつの成功例を測った値です。

具体的な弱点を知らせずに進めた2つ目も、約5分で探索から実行確認と登録へ到達しています。検証者からは、以前のように処理が止まって見えるアイドル状態もなく、探索が進んだと報告されています。CPUやGPUの使用率を測定した結果ではありません。

過去の別の実行では、最初のfindingまで約34分かかった記録があります。ただし、対象、指示、設定、計測開始点をそろえた比較ではないため、GLMの性能改善率やARTEXの高速化倍率は算出できません。今回の結果は、対象への接続と目標を整えた条件で、短時間に実証を得られた事例です。

次の比較では、同じ初期状態と指示で試行を重ね、成功率と所要時間のばらつきを測ることが有効です。最初の実証と最終報告の時刻、人による準備・レビューの時間も分けて残すと、AIの処理時間と業務全体の工数を評価できます。

今回の教材で確認した弱点には、OSコマンドへ外部入力を渡す処理と、アップロードしたファイルの実行設定の修正が必要です。 PHP本体の更新と合わせて、アプリ側の経路も点検します。

まず、OSコマンドを呼ばずに同じ処理を実装できるか確認します。OWASPの防御指針も、ライブラリやAPIで代替できる場合は、直接のコマンド呼び出しを避けることを優先しています。

必要な場合は、入力を文字列としてつなぐ設計を見直し、実行するプログラムと引数を分離する仕組みを使います。利用者が指定できる値も用途に合わせて制限し、意図しない引数として解釈されないか確認します。

修正後は、問題を再現した入力で不正な処理が起きないことと、通常の機能が使えることを確かめます。実行権限を必要最小限にすることも被害の限定に役立ちますが、入力処理の修正と併せて行います。

アップロードでは、業務で必要な形式だけを許可し、拡張子と内容を確認します。利用者が送るContent-Typeだけを信用せず、保存する名前をアプリ側で生成することも基本です。OWASPのアップロード指針

保存先でスクリプトを実行させない設定も必要です。可能ならWeb公開領域の外に保存し、配信方法を含めて設計します。今回の教材のように保存後の実行が成立する構成では、単一の拡張子を拒否するだけでは対策になりません。

修正後には、危険な形式を受け付けないことに加え、想定外のファイルが置かれてもコードとして実行されないことを確認します。通常の画像表示など、必要な機能が使えることも試します。今回の検証記録には、修正後の比較試験は含まれていません。

PHP本体の修正適用と、今回のアプリ検証で混同しやすい点を整理します。

PHP2Shellへの修正は、PHP本体の2件の問題に対応するものです。今回の教材のようなOSコマンドへの危険な入力や、アップロード先でのコード実行まで自動で直すものではありません。PHPを更新したうえで、アプリの実装とサーバー設定も修正する必要があります。

今回実証したのは、コマンド注入とアップロード経由のRCEです。104秒と305秒も、この2つの教材に対する記録であり、CVE-2026-109618／CVE-2026-109619の再現時間ではありません。

PHP2Shellへの対応能力を評価するには、該当CVEの影響条件を満たす隔離環境で別の検証が必要です。原因を特定できる証拠と、修正版では成立しない比較結果をそろえて評価します。

PHP2Shellへの対応では、利用中のPHPと配布元の修正情報を確認し、修正済みのランタイムやパッケージを速やかに適用することが優先です。アプリの検査結果を待つ必要はありません。

ARTEXとGLMを使った今回の教材では、アプリ側のコマンド注入とアップロード経由のRCEを確認し、タスク作成からfinding登録まで104秒・305秒でした。具体的な脆弱箇所を知らせない複数段階の検証も進められた点が成果です。正常系との比較や操作記録をもとに実証を評価し、PHP本体の更新とアプリ側の修正をそれぞれ進めてください。

参考資料（確認日：2026年10月22日）

• 当社による自作PHP教材の検証記録と、タスク作成からfinding登録までのDB実測値。各方式の成功例、所要時間、操作審査の結果はこれらの記録に基づきます。
• PHP公式：2026年10月21日の緊急修正とセキュリティ勧告
• PHP公式：CVE-2026-109618の技術情報
• PHP公式：CVE-2026-109619の技術情報
• IPA：PHPの脆弱性に関する事前準備のお願い
• CERT-EU：PHPの重大脆弱性に関する勧告
• オランダNCSC：PHP2Shell対応情報
• CWE-78：OSコマンドインジェクション
• CWE-434：危険な種類のファイルのアップロード
• OWASP：OSコマンドインジェクションへの対策
• OWASP：ファイルアップロードへの対策