2026年10月に公開されたPHPの重大な脆弱性（通称「PHP2Shell」：CVE-2026-109618、CVE-2026-109619）について、技術的な仕組みや対策の実効性に関して疑問に思った点を、AI（Gemini 3.8 Flash High）と対話しながら整理しました。
※免責事項・注意事項
本記事は公開されているセキュリティ情報をもとに、個人の学習・検証の過程を記録した参考情報です。セキュリティ対策の適用にあたっては、システム環境ごとの影響を十分に検証のうえ、PHP公式や各種ディストリビューションが発表する最新情報をご確認ください。
Gemini 3.8 Flash Highは、こちら↓のを使ってます。
脆弱性の概要（PHP2Shellとは）
「PHP2Shell」とは、PHPインタプリタのコア部分に存在する2つのリモートコード実行（RCE）脆弱性の総称です。CVSS v4.0の基本値は9.2（Critical）と評価されています。
- CVE-2026-109618: メモリ不足（OOM: Out-of-Memory）などの異常終了処理におけるメモリ破壊・未初期化状態に関する脆弱性
- CVE-2026-109619: セッションのアップロード進捗機能（
session.upload_progress）等に起因する、解放後メモリの参照（Use-After-Free）に関する脆弱性
これらの脆弱性を組み合わせることで、外部から細工されたHTTPリクエストを送信し、Webサーバー上で任意のコードを実行される可能性があると報告されています。
疑問①：エラー発生からコード実行に至る仕組み
「メモリ不足が起きてから復帰する際に、なぜ不正なコードが実行されるのか？ 権限チェックの不備なのか？」という疑問について確認しました。
アプリケーションの権限チェックではなく、低レイヤーのメモリ制御の問題
この問題は、Webアプリケーションのログイン認証や権限判定処理をバイパスするものではなく、PHPインタプリタ（C言語バイナリ）内部のメモリ管理に起因するものです。
- 異常終了（longjmp）の発生
細工されたマルチパートリクエスト等によりPHPの処理中にメモリ不足（OOM）が発生すると、PHP内部ではzend_bailout()（C言語のlongjmp()）が呼び出され、処理が途中で強制中断されます。 - クリーンアップの不備
この強制中断の際、確保されていたメモリ領域の解放や状態リセットが不完全なまま中断処理が行われます。 - Use-After-Free（解放後メモリの参照）
PHP-FPMなどの環境では、パフォーマンス向上のため同一のワーカープロセスが複数のリクエストを処理し続けます。リクエスト終了後にメモリが解放された後も、内部のグローバル構造体がその解放済みアドレスを指したまま残ってしまうケースがあります。 - 関数ポインタの参照による制御フローの遷移
次のリクエスト処理において、その解放済み領域へ別のデータが割り当てられた状態で古いポインタが参照されると、メモリ上の関数ポインタ（次に実行すべき関数のアドレス）が意図しない値に上書きされ、結果として攻撃者が指定した処理へ実行フローが遷移します。
疑問②：メモリ番地を事前に特定してデータを配置するのは困難ではないか？
「OSにはアドレス空間のランダム化（ASLR）などの防御機構があり、狙った番地に都合よくデータを送り込むことは難しいのではないか？」という疑問を持ちました。
攻撃成立の難易度は高いが、複数の手法を組み合わせて突破されるリスクがある
現代のOS環境では、この攻撃を成立させる難易度は非常に高いとされています。しかし、以下のような技術要素を組み合わせることで成立し得ると指摘されています。
- アロケータの規則性の利用（ヒープ状態の調整）
PHPのメモリマネージャ（Zend MM）は効率化のためにサイズごとのメモリプールを持っています。解放されたメモリブロックと同じサイズのリクエストデータを直後に送信することで、解放済みのアドレスへ狙ったデータを再割り当てさせやすくする手法が存在します。 - 事前の情報漏洩（Memory Leak）による番地の特定
ASLRによってベースアドレスがランダム化されていても、何らかの通信やエラー等からメモリ上のアドレスが一部でも漏洩した場合、相対オフセットの計算により目的のアドレスが逆算されるリスクがあります。 - ROP（Return-Oriented Programming）の利用
データ領域上のコード実行を禁止する防御（DEP/NX）が有効であっても、メモリ上（libc等）にすでに配置されている既存の関数呼び出しを連鎖させることで、保護機構を回避して処理を実行させる手法が知られています。
このように、単発で成立させるのは困難であるものの、環境や前提条件が揃った場合には成立する危険性が示されています。
疑問③：PHPを超えてサーバーOSを操作されるリスク
「ROP等によって実行される場合、PHPの処理を超えてOS自体を操作されるのか？」という点を確認しました。
PHP言語の制限を無視して、OSのシステム関数が実行される
攻撃が成立した場合、PHPスクリプトの実行を介さず、C言語レベルで system("/bin/sh") や execve などのOSシステムコールが直接呼び出される可能性があります。
- PHP設定（
disable_functions等）の無力化php.iniに記載されている関数の無効化設定や、アクセス可能ディレクトリを制限するopen_basedirはPHPスクリプトエンジン側の機構であるため、バイナリレベルでの実行制御奪取に対しては効果を持ちません。 - 影響範囲
実行される権限は、PHPプロセスが動作しているOSユーザー権限（例:www-dataやapache等）の範囲内です。直ちにroot権限になるわけではありませんが、Webサーバー内のファイル閲覧・改ざん、データベース接続情報の取得、外部との不正通信などが可能となるため、大きな影響を及ぼす可能性があります。
疑問④：公式パッチによる修正内容
PHP公式（The PHP Group）が公開した修正パッチ（PHP 8.2.35、8.3.36、8.4.27、8.5.12 等）では、主に以下の内部改修が行われています。
- 異常中断処理（bailout）の安全性向上
OOM発生時にlongjmpで無条件に処理を破棄するのではなく、内部状態の整合性を損なわない形で安全にリクエストを終了できるようにエラー処理の流れが見直されました。 - ポインタの明示的な初期化（NULLクリア）
セッションのアップロード進捗機能などにおいて、リクエスト終了時やエラー発生時に不要となったポインタを確実にNULLでクリアし、解放済み領域への参照（Dangling Pointer）が残らないよう修正されました。 - 未初期化メモリの参照防止
異常終了後のメモリ再利用時に、未初期化のまま内部構造体が扱われないようチェックと初期化が徹底されています。
DockerでWordpressのコンテナつかっているときのバージョンアップはこちらを参考にしてください。
（参考）WordPressの管理画面でPHPバージョンを確認する手順
利用しているサーバーのコントロールパネルを開かなくても、WordPressの管理画面内から現在動作しているPHPのバージョンを確認できます。
- WordPressの管理画面（ダッシュボード）にログインします。
- 左側メニューの 「ツール」 ＞ 「サイトヘルス」 をクリックします。
- 画面上部にあるタブから 「情報」 を選択します。
- 一覧にある 「サーバー」 の項目をクリックして開きます。
- 「PHP バージョン」 の行に、現在サーバーで適用されているバージョン番号（例:
8.2.34や8.3.36など）が表示されます。
疑問⑤：WAFやphp.iniの設定による対策の有効性
「WAFで検知できないのか？」「php.ini のアップロードサイズ制限などの引き下げは有効か？」という点について調べました。
WAFの役割と限界
大手WAFベンダー等から緊急ルールが提供されていますが、以下のような要因からWAFのみでの完全な防御は困難とされています。
- 通信フォーマット自体は通常のHTTPマルチパートリクエストであるため、一般的なファイル送信との判別がつきにくい。
- サーバー側でOOMが発生するかどうかはサーバーの個別設定（
memory_limit等）に依存するため、外側のネットワーク機器だけでは影響の予知が難しい。
そのため、WAFはあくまでアップデートまでの「一時的なリスク緩和策」と位置付けられています。
php.ini での暫定緩和策
公式およびセキュリティ機関より、パッチ適用が直ちに困難な環境向けに以下の設定緩和策が案内されています。
; 1. セッションアップロード進捗機能の無効化（使用していない場合は推奨）
session.upload_progress.enabled = 0
; 2. リクエストサイズの上限を業務上必要な最小限に設定
post_max_size = 8M ; アップロードが不要なら8M程度、必要なら32Mなど
upload_max_filesize = 2M ; post_max_sizeより小さい値
- 注意点:
- リクエスト受信時の初期段階で発動する問題のため、PHPスクリプト内の
ini_set()では対策できません。必ずphp.iniや PHP-FPMのプール設定（www.conf）に記述する必要があります。 - 設定変更後は、PHP-FPMやWebサーバーのプロセスを再起動して設定を反映させる必要があります。
- これらは攻撃可能な経路を狭めるための暫定措置であり、根本的なバグを解消するものではありません。
- 設定変更で通常のアプリに影響がないか注意してください。
- リクエスト受信時の初期段階で発動する問題のため、PHPスクリプト内の
php.iniの変更は、こちら↓も参考にしてください。
まとめ
今回の調査を通じて、PHP2ShellはWebアプリケーションの記述ミスではなく、PHPエンジンのメモリ管理およびエラー処理の隙を突いた低レベルの脆弱性であることが分かりました。
防御側としては、WAFや設定変更による一時的なリスク低減策を講じつつも、公式から提供されている修正済みバージョンへのアップデートを行うことが最も確実な対策とされています。運用中の環境に合わせて、影響範囲の確認と計画的なアップデートの検討をおすすめします。
この記事を書いたイチゲを応援する（質問でもokです）
Vプリカでのお支払いがおすすめです。