本ドキュメントは、2026年10月21日夜に公表されたPHPの深刻な脆弱性「PHP2Shell」の概要、技術的背景、影響範囲、および推奨される対策をまとめたものです。ぜひJFrog Platformを活用して適切なセキュリティ対策を実施してください。

詳細について、お問い合わせフォーム、もしくは本書作者Alex Wang (王 子龍)へお気軽に問い合わせいただけたら幸いです。（日本語、英語の両方に対応）

1. 概要（Executive Summary）

2026年10月20日〜21日にかけて、PHPランタイムに存在する2つのクリティカルなリモートコード実行（RCE）の脆弱性（通称：PHP2Shell）が公表されました。

• 影響を受けるバージョン： PHP 5.4.0 から 8.5系まで（広範なレガシーバージョン〜最新バージョン）
• 危険度（CVSS v4.0）： 9.2〜10.0（Critical / 最重要）
• 攻撃の影響： 認証なしでリモートから任意のコードを実行（RCE）、ファイル読み取り、メモリ情報漏洩が可能。

2. 脆弱性の詳細

これらの脆弱性により、以下の攻撃コード（エクスプロイト）を作成することが可能になります： – リモートコード実行 – 情報漏洩 なお、これら2つの脆弱性はいずれも、上記のどちらの目的を達成するためにも利用可能です。 PHPの2つの勧告は、同じ1つの欠陥を2つの異なる観点から説明しています。

CVE ID	概要と根本原因	主な攻撃ベクター
CVE-2026-109618	メモリ不足（OOM）発生時のリクエスト処理中断に伴うメモリ状態の不整合（Use-After-Free）。	セッションのアップロード進捗機能（session.upload_progress）等を悪用した未認証RCEおよびメモリ漏洩。

CVE ID	概要と根本原因	主な攻撃ベクター
CVE-2026-109619	PHPグローバル変数における解放済みメモリへの参照保持（Stale State）およびOPcacheの型混同。	致命的エラー（Fatal Error）のスタックトレースやOPcacheの利用による未認証RCEおよび任意ファイル閲覧。

3. 影響範囲

PHP のバージョン：

• PHP 8.2.x（8.2.35 以前のバージョン）
• 3.x（8.3.36 以前のバージョン）
• 4.x（8.4.27 以前のバージョン）
• 5.x（8.5.12 までのバージョン ※PHP 8.5系の場合）

設定：

• upload_progress.enabled=On（デフォルト設定）であり、マルチパート（multipart）アップロードが有効であること。

サーバー環境：

• 特定のアプリケーション実装に依存せず、リモートコード実行（RCE）のリスクが存在する環境として、Apache mod_php（および FrankenPHP の可能性あり）が挙げられます。なお、FPM（FastCGI Process Manager）を使用している場合でも、システムの稼働後に露出するステータス情報などを通じてリスクに晒される可能性があります。

4. 一般的な対策・修正方法

① 公式修正パッチの適用（最優先・必須）

修正パッチが適用された以下の安全なバージョンへ、速やかにアップグレードを実施してください。

• PHP 8.5 系： 8.5.12 以上
• PHP 8.4 系： 8.4.27 以上
• PHP 8.3 系： 8.3.36 以上
• PHP 8.2 系： 8.2.35 以上

※アップグレード後は、古いバイナリやプロセスが残らないよう、必ずPHP-FPMプロセスやWebサーバー（Apache/Nginx等）を再起動してください。

② 即座のアップグレードが困難な場合

PHP公式のセキュリティ勧告に基づき、以下の設定変更を行うことでリスクを一時的に軽減できます。

管理者設定で upload_progress.enabled=0 を指定し（PHP 8.5.x を使用している場合は fatal_error_backtraces=0の設定も必要）、設定を変更した後にすべてのワーカープロセス（worker）を再起動してください。あわせて、memory_limit=-1を設定します（※ RLIMIT_ASや RLIMIT_DATAは使用しないでください）。さらに、pm.max_requests=1を設定することで、「同一のワーカープロセスを使用しなければならない」という制限を解除できます。

なお、upload_progressを無効化しても OPcache やバックトレース（backtrace）に関連するメカニズムには影響しません。また、memory_limit=-1に設定すると、リソース枯渇に対する保護機能が解除される点にご注意ください。上記で挙げた各措置は、単独で適用した場合、あくまで部分的な軽減効果にとどまります。

5.JFrog のセキュリティ・リポジトリ機能の全体像

JFrogプラットフォームでは、リポジトリ管理とセキュリティ対策を連携させることで、安全で効率的なソフトウェア開発を実現します。

Artifactory（リポジトリ管理）

• Remote Repository（リモートリポジトリ）: パブリックリポジトリ（npm, PyPI, Maven等）のキャッシュ・プロキシとして機能し、外部からのパッケージ取得を中間管理します。
• Local Repository（ローカルリポジトリ）: 自社でビルドした成果物（アーティファクト）や内部共有パッケージを安全に保管・管理します。

JFrog Curation（事前ブロック / 水際対策）

• オープンソースソフトウェア（OSS）が社内の開発環境やRemote Repositoryに「入る前」に、悪意のあるパッケージやリスクの高いコンポーネントを自動で検知・プロックするソリューションです。
• 従来のセキュリティ対策が「入ってきたものをスキャンする」のに対し、Curationは「玄関口（ゲート）で門前払いする」役割を担います。

JFrog Xray（継続的スキャン・脆弱性・ライセンス管理）

• Artifactory内に格納されたパッケージやビルド成果物を「入った後」に継続的にスキャンします。
• 既知の脆弱性（CVE）の検知や、ライセンス違反のチェックを行い、依存関係の可視化やSBOM（ソフトウェア部品表）の生成を支援します。

JFrog Advanced Security（JAS：高度なセキュリティ機能）

• Xrayの機能をさらに拡張し、ソースコードやコンテナイメージに潜む「コンテキストに応じたリスク」を深層分析します。
• 主な機能:
  • Contextual Analysis（文脈解析）: 脆弱性が実際に実行可能コードとして利用されているかを判定し、修正の優先度を最適化。
  • Secret Detection（機密情報検知）: コードやイメージ内に埋もれたAPIキーやトークン等の漏洩を防止。
  • IaC Security（インフラ構成コード検証）: TerraformやKubernetes設定ファイルのセキュリティリスクを自動検知。
  • Malicious Package Detection（悪意あるパッケージ検知）: 未知の悪意あるコードやバックドアの検知。

6. JFrogを活用した対策・修正方法

① JFrog XrayのImpact Search機能で影響範囲を検索する

検索結果として、該当するCVEを含む成果物（アーティファクト）の一覧が表示されます。

② JFrog Advanced Securityでリスクを特定する

①の手順で該当するCVEが含まれるファイルは特定できますが、さらにJFrog Advanced SecurityのContextual Analysis機能を使用することで、対象の脆弱性メソッドが実際に呼び出されているか（「Applicable」と表示されるか）を確認できます。「Applicable」と判定された場合は、優先的に修復を実施してください。

③ 外部からのさらなる流入をブロックする

リモートリポジトリ（プロキシリポジトリ）経由で外部から該当CVEを含むパッケージが新たにキャッシュされるのを防ぐため、JFrog Curationのポリシーを設定します。

Curation ＞ Policy にてポリシー名や適用スコープを設定後、新規条件（Condition）を作成します。

「Package is vulnerable to CVE」を選択し、対象のCVE番号を直接指定します。

ポリシーを保存（Save）することで、ブロック設定が有効になります。

④ 組織内での二次拡散をブロックする

すでにリモートリポジトリにキャッシュされている該当CVEが組織内で使用されるのを防ぐため、以下の設定を行います。

Admin ＞ Curation Settings ＞ 「Enable Curation for Cached Packages」および「Enable Curation On-Demand for On-Demand Package in the JFrog Catalog」を有効（On）にしてください。

ローカルリポジトリに保存されている該当CVEを含むファイルが使用されないよう、JFrog XrayでWatchおよびPolicyを作成します。

対象のCVE番号を直接指定し、「ビルドのブロック（Block Build）」や「ダウンロードのブロック（Block Download）」のアクションを設定します。

最後に作成したPolicyをWatchに関連付け、すべてのリポジトリへ適用します。

7. まとめ

PHP2Shell脆弱性は公表から攻撃コードの出現・悪用までの期間が非常に短く、すでに野生環境（In the wild）での攻撃が確認されています。PHPを使用しているすべてのWebアプリケーション環境において、至急バージョンの確認およびアップデート、または適切なブロック措置を実施することを強く推奨します。

8. この記事の著者について

Alex Wang (王 子龍)　JFrog Japan

戦略コンサル時代、IT、自動車、製造などの業界に対して、アジャイル、DevOpsのコーチとして開発環境構築、CICD構築などのプロジェクトをリードしてきました。現在、DevSecOps、MLOpsや海外最新のソフトウエア開発セキュリティ対策を日本への展開・普及を行っています。

Linked-in: https://www.linkedin.com/in/alex-wang-662290150/
EXIN DevOps Professional
PMI Project management Professional
Aoyama Gakuin University MBA holder

---