PHPのメモリ枯渇をRCEに変える、PHP2Shellの全工程を解剖する

PHP2Shell Deep Dive

PHPのメモリ枯渇をRCEに変える、PHP2Shellの全工程を解剖する

PHPのセッション処理とZend Engineのエラー処理が絡み合って生まれるstale pointerを起点に、OOMからRCEへ至るCVE-2026-109618とCVE-2026-109619の攻撃チェーンを、ヒープの基礎から4段階のパイプラインまで順に解説する。zend_stringの偽造、ASLR回避のためのコードポインタ漏洩、pDestructorのハイジャックまで、実際のHTTPリクエストとPHPソースコードを追いながら、何が起きるかにとどまらずなぜ起きるのかまで踏み込む。

PHPは攻撃者にstale pointerをわざわざ手渡したりはしない……いや、PHPはそこまで太っ腹ではない。あのポインタは、正当なPHPの機能がZend Engineのエラー処理機構と噛み合ったときに生じる、微妙な欠陥の産物なのだ。
  1. djad04

    これを書いたのは私です。最初は自分でここに投稿しようとしたのですがあまりうまくいかず、他の誰かが共有してくれてよかったです!ここに持ってきてくれてありがとう。

    また、あの特定のビルドで動く別のPoCを持っている人がいたら、ぜひ共有してほしいです。というのも、このエクスプロイトの仕組みを見ると、他のビルド向けに見つけたどのソリューションでもやっていないことをやっているんです。どのソリューションも、リサイズでスポットを保持する(キー「1050」が2回送信される)ことをせず、次のフィールド(「1999」)から中間バッファを作ってそこに落とす、ということをしていません。あのように繰り返しキーを使うアプローチは他に見たことがありません。

    他のビルド向けのソリューションのように、もっと直接的な方法があるのか気になります。もしあるなら、ターゲットにどう到達するかではなく、メモリ操作自体に基づいて異なるアプローチの信頼性を比較するのは面白いと思います。

  2. t1234s

    最も印象的だったのは、このエクスプロイトを別のLinuxエクスプロイトと連鎖させてrootアクセスを得たことです。

    歴史に残る一週間になりました。

この日のほかの記事

2026-11-10