「PHP2Shell」と呼ばれる一連の脆弱性が公開されました。PHPは、WordPress、Joomla、DrupalなどのCMSに広く使用されているプログラミング言語であり、世界中のWebサイトの約70%で使用されています。
PHP2Shellは、リモートコード実行（RCE: Remote Code Execution）の脆弱性であるCVE-2026-109618とCVE-2026-109619の総称です。この脆弱性は認証なしで悪用が可能であり、PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境全般に影響を及ぼします。
PHP開発チームはCVSS v4.0基準で9.2点（Critical）と評価しており、PHP 8.5.12、8.4.27、8.3.36、および8.2.35に対してセキュリティパッチを配布しています。旧バージョンに関しては、公式サポートが終了しているためパッチの対象外ですが、今回は影響範囲が広いため、ベンダーへ問い合わせるか、サポートされているバージョンにアップグレードするなどの方法が案内されています。
しかし、実際の企業環境では、運用中の多数のサーバーやシステム、バックポート（移植）のスケジュールなどを考慮すると、すべてのサーバーをわずか1日でアップデートすることは困難です。
この隙間を埋める方法が、Webアプリケーションファイアウォール（WAF）を活用したルールの追加です。ペンタセキュリティは、ハードウェア型WAF「WAPPLES」においてPHP脆弱性に対応するカスタムルールと設定ガイドを配布し、クラウド型WAFである「Cloudbric WAF+」にも同様に追加しました。PHP2Shellは、改ざんされたHTTPリクエストによってPHPを異常終了に追い込む攻撃であるため、リクエストがサーバーに到達する前に遮断することで、サーバーに実際のパッチを適用するまでの対応時間を確保できます。
PHP2Shell 脆弱性分析：CVE-2026-109618・CVE-2026-109619
PHP2Shellの2つの脆弱性は、いずれもリクエストが異常終了する過程でメモリ状態が適切にクリーンアップされない問題によって発生します。
PHPは、メモリ上限（memory_limit）を超えるなどの致命的なエラーが発生すると、「ベイルアウト（bailout）」という内部処理で対応します。ベイルアウトは、進行中の処理を直ちに中断する一種の非常脱出方式です。しかし、データ処理が完了する前にベイルアウトが発生すると、その後のクリーンアップ過程で未完成のデータを正常なデータとみなして処理してしまう可能性があります。
前述のリクエストで使用した状態情報が適切に初期化されない場合、同じプロセスが処理する次のリクエストでその情報がそのまま再利用される可能性があり、この過程で攻撃者がメモリ状態を悪用してコード実行へつなげることができます。
2つの脆弱性の比較は以下の通りです。
| 区分 | CVE-2026-109618 | CVE-2026-109619 |
| タイプ | メモリ不足（OOM）によるメモリ損傷 | 解放済みグローバル状態（Stale Global State）の再利用 |
| 発生原理 | メモリ割り当てに失敗し、リクエストデータが完全に生成されていない状態で処理が中断。その後のクリーンアップ処理でこれを正常データとして処理してしまう。 | リクエストが終了してメモリが解放された後もグローバル状態情報が残り、同じワーカーが処理する次のリクエストでこれを再度参照してしまう。 |
| 主な発生箇所 | マルチパートパース（$_POST, $_FILES）など、リクエスト処理の初期段階 | エラー・バックトレース、セッション、シリアライズなど、グローバル状態を使用する処理過程 |
| 結果 | Webワーカー権限でのリモートコード実行（RCE）が可能 | ヒープUAF（Use-After-Free）、メモリ露呈、リモートコード実行（RCE）が可能 |
ひとつめの脆弱性（CVE-2026-109618）は、マルチパートデータを $_POST / $_FILES でパースするなどのリクエスト処理初期段階において、メモリ割り当てが失敗した場合に完全に初期化されていないメモリへアクセスできてしまう点が重要です。
2つめの脆弱性（CVE-2026-109619）は、エラーによって初期化が省略されたり、クリーンアップ後に診断メッセージが状態情報を再充填したりする過程で、既に解放されたメモリを指すポインタが残ってしまう問題です。
PHP2Shell 脆弱性が危険な4つの理由
同じリモートコード実行（RCE）脆弱性であっても、PHP2Shellがより深刻視される理由は大きく4つあります。
- アプリケーションコードの実行前から攻撃可能
PHPセキュリティチームは、mod_php 環境において、認証されていないリクエストひとつだけでアプリケーションコードが実行される前に脆弱性を悪用できることが確認されたとし、この環境のリスクを最も高く評価しました。つまり、アプリケーションコード自体を修正するだけでは対応が困難です。 - AIによって発見された脆弱性
長年存在していたPHPの欠陥が、AIを活用した分析過程で発見されました。Wizの研究者によると、欠陥自体は昔から存在していたものの、実際に攻撃を成功させる手順が非常に複雑だったため、悪用が難しいとされていました。しかし、最新のAIを活用したことで、解析と攻撃手順の作成が容易になり、深刻な脅威として表面化しました。 - 公開前の攻撃試行
PHP側は脆弱性公開の翌日に緊急パッチをリリースしました。しかし、正式公開の前から、外部のセキュリティ機関によって実際の攻撃試行が観測されていたという報告も出ており、非常に緊急性が高い状況です。 - 露出規模の大きさ
VirusTotaによると、インターネット上に露出しているPHPサーバーが510万台以上あると推定しています。英国国家サイバーセキュリティセンター（NCSC）は、PHPを使用しているシステムをすぐにアップデートするよう呼びかけており、直ちに対応できない場合WAFなどによる一時的な緩和措置やサービス停止を含めたリスク回避策を求めています。
PHP2Shellへの対応 1：PHPセキュリティパッチの適用
第一に、PHPをアップデートする必要があります。脆弱性は PHP 8.5.12、8.4.27、8.3.36、8.2.35 で修正されています。詳細はPHPセキュリティリリースおよびGitHubセキュリティアドバイザリで確認できます。
- CVE-2026-109618：セキュリティアドバイザリ詳細
- CVE-2026-109619：セキュリティアドバイザリ詳細
PHPセキュリティチームは事態の深刻さを考慮し、ソースコードを直接ビルドして使用している環境向けに、PHP 7.4、8.0、8.1用の最小限のバックポートを別途公開しました。ただし、PHP 8.1以下はすでに公式サポートが終了しているバージョンです。旧バージョンを使用している場合は、バックポートパッチを提供するディストリビューションやLTSベンダーに問い合わせるか、公式サポート対象バージョンへアップグレードする必要があります。
PHP2Shellへの対応 2：即時パッチが難しい場合の緩和設定
運用中のサービスは、互換性の検証なしに即座にバージョンアップすることが困難なため、PHPセキュリティチームはパッチ適用前に実施できる応急的な設定を案内しています。
CVE-2026-109618 対策
- メモリ制限の解除
- memory_limit=-1 に設定
- FPMプールやApache設定の php_admin_value のように、アプリケーション側から変更できない方式で適用することを推奨
- リクエストサイズ制限
- post_max_size を、ファイルアップロードがないサービスは 8M、アップロードが必要なサービスは 32M に設定
- リソース制限の分離
- コンテナや cgroup を活用してリソース制限を設定し、異常が発生したワーカーのみが終了するように構成
CVE-2026-109619 対策
- セッションアップロード進捗機能をオフ
- session.upload_progress.enabled=0 に設定し、すべてのワーカーを再起動
- 致命的エラーのバックトレースをオフ
- PHP 8.5の場合、fatal_error_backtraces=0 に設定してワーカーを再起動（※ただし、この設定は現在確認されている特定のバックトレース経路ひとつのみを遮断します）
- 診断メッセージ設定の整理
- error_reporting、display_errors、@ 演算子でメッセージを非表示にするだけでは不十分です。初期化前に警告を発生させる誤った設定や、非推奨・サポート終了した設定を削除してください。
- エラー経路の点検
- コールバック、アップロード・インポート処理、クリーンアップ過程などで攻撃者が誘発する致命的エラーや、実行時間超過の処理方式を点検
PHP2Shellへの対応 3：WAFを活用したルール追加
PHPサーバーのパッチおよびアップデート完了までのリスクを緩和する手段のひとつが、WAFを活用したルールの追加です。ペンタセキュリティは、ハードウェア型WAF「WAPPLES」およびクラウド型WAF「Cloudbric WAF+」において、PHP脆弱性用のカスタムルールと設定ガイドを配布しました。
PHP2Shellは、悪意のあるHTTPリクエストを介してPHPの異常終了を誘発する形で悪用されます。したがって、悪意のあるリクエストがサーバーに到達する前に遮断できれば、実際のパッチを適用するまでに必要な対応時間を稼ぐことができます。
PHP2Shell対応の要点：PHPパッチとWAFの併用
PHP2Shellは、アプリケーションコードだけでなく、それを実行するPHPランタイム環境自体も攻撃にさらされる可能性があることを示しています。AIが脆弱性の分析と発見のスピードを早めたことで、脆弱性の公開から実際の攻撃までのタイムラグはますます短くなっています。企業には迅速なパッチ適用体制とともに、パッチを適用するまでのリスクを軽減できる補完手段が必要です。
今回のPHP2ShellはPHP自体のメモリ欠陥です。根本的な解決にはPHPをアップデートして脆弱性そのものを除去する必要があります。しかし、今すぐのPHPパッチ適用が難しい場合は、ペンタセキュリティのようなセキュリティ企業のソリューションを利用してリスクを緩和し、安全なビジネス環境を構築する必要があります。