PHP-FPMとFiberの共存幻想：Zend VMの限界と非同期並行処理の残酷な現実
PHPはその誕生以来、「1リクエスト＝1プロセス（または1スレッド）」という強固なShared-Nothing（共有なし）アーキテクチャを基盤に発展してきた。この設計思想こそが、C言語のようなマニュアルメモリ管理の恐怖や、Java/.NETのJVMにおける複雑なスレッド間競合・ガベージコレクションの地獄からWebアプリケーション開発者を守り抜いた最大の防壁である。
しかし、現代のWebアプリケーションが直面するI/Oバウンドなボトルネック――外部APIの叩き合い、マイクロサービス間のRPC、RDBやRedisへの無数のクエリ――の前では、伝統的な同期型リクエスト処理モデルはあまりにも非力だ。ここで救世主の如く現れたのが、PHP 8.1で導入されたFiber（ファイバー）である。
「PHPでもついに非同期並行処理ができる」――そう歓喜したエンジニアたちも少なくない。だが、Zend VMの内部構造、PHP-FPMのプロセスモデル、そしてOPcacheのメモリ管理機構の深淵を覗いた者であれば、その思想の衝突がいかに危険なものであるかを理解しているはずだ。
本稿では、PHP-FPM環境下でFiberを運用する際に直面するZend VMのコンテキストスイッチの仕組み、プロセス再利用がもたらすメモリリークリスク、そして最悪の場合にRCE（リモートコード実行）へと直結するオブジェクトインジェクションの脆弱性メカニズムについて、低レイヤの視点から徹底的に解剖する。
—
1. Zend VMにおけるFiberの正体：スタックレスからスタックフルへ
従来のPHPにおける非同期的なアプローチ（Generatorを用いた協調的マルチタスキング）は、いわゆる「スタックレス（Stackless）」な実装であった。関数が中断されるたびに呼び出し元のコンテキストを手動で巻き戻し、yieldを通じて値を外側にバトンタッチする必要があった。これはビジネスロジックを記述するにはあまりにも破綻したプログラミングモデルだった。
これに対し、Fiberは「スタックフル（Stackful）」なコルーチンである。Zend VMの実行コンテキスト（`zend_execute_data`）とコールスタックをヒープ上に独立したチャンクとして確保し、実行のポインタ（`opline`）とローカル変数の実態（`CV: Compiled Variables`）を丸ごと退避・復元する。
/
$fiber = new Fiber(functionv(): void {
echo “Fiber内: 処理開始\n”;
$value = Fiber::suspend(‘中断点からの脱出’);
echo “Fiber内: 再開された。受け取った値: {$value}\n”;
});
// Fiberの起動（Zend VMが新しい実行コンテキストを割り当てる）
$output = $fiber->start();
echo “Main側: {$output}\n”;
// Fiberの再開（中断されたoplineの位置へジャンプし、Zend VMのレジスタを復元）
$fiber->resume(‘メインからの継続信号’);
このコードが実行されるとき、Zend VMの内部では何が起きているのか。通常、関数呼び出しはCのコールスタックおよびZend VMの内部実行スタックを単方向にのみ伸長・縮小させる。しかし、Fiberは独自の `zend_fiber_context` 構造体を持ち、CPUのレジスタコンテキスト（`getcontext`/`setcontext` または Boost.Context等のアセンブリレベルのルーチン）を書き換えることで、同一スレッド内での擬似的なマルチスレッディングを実現している。
しかし、ここに致命的な罠がある。Fiberは「言語レベルのスレッド」ではない。あくまで同一プロセス・同一スレッドのイベントループ内で動作する協調的（Cooperative）な制御フローに過ぎない。
—
2. PHP-FPMとFiberの致命的なパラダイムミスマッチ
PHP-FPM（FastCGI Process Manager）は、リクエストのライフサイクルが極めて短命であることを前提に設計されている。
1. リクエスト受信：Webサーバー（Nginx等）からFCGIプロトコル経由でリクエストを受け取る。
2. プロセスフォーク / ワーカー割り当て：あらかじめ起動しているFPMチルドプロセスがリクエストを処理する。
3. 実行：Zend VMがスクリプトを読み込み、オペコード（Opcode）にコンパイルし、実行する。
4. クリーンアップと終了：スクリプト終了時、Zend VMはグローバルなシンボルテーブル、メモリプール（Zend MM）を完全に破棄し、プロセスはOSへリソースを返還（または次のリクエストのために再利用）する。
この「リクエスト終了時の完全なメモリ破棄（Shared-Nothing）」という前提があるからこそ、PHPアプリケーションはメモリリークやステート汚染から解放されていた。
しかし、PHP-FPMのプロセス内で長寿命なイベントループとFiberを組み合わせようとすると、この前提が完全に崩壊する。
FPMプロセス内でのイベントループ駆動の矛盾
非同期I/O（ReactPHPやAmp v3など）をPHP-FPM内で完結させようとした場合、次のようなコードを書きたくなる。
start();
// イベントループを回してFiberの完了を待つ
EventLoop::run();
一見、効率的に見えるこのアプローチは、PHP-FPMのプロセスモデルと激しく衝突する。
PHP-FPMのワーカプロセスは、1つのリクエストを同期的に処理し、レスポンスをクライアントに返却した後に次のリクエストを受け付ける。もしFPMのプロセス内で `EventLoop::run()` をブロックさせ、その中でFiberを協調動作させると、そのFPMプロセスは他のリクエストを一切処理できなくなる（プロセスが占有される）。
SwooleやOpenSwoole、あるいは RoadRunner のような常駐型（Long-running）プロセスアーキテクチャであれば、マスター/ワーカーモデルとイベントループが完全に統合されているためFiberは極めて強力に機能する。しかし、短命なライフサイクルを持つPHP-FPMとFiberは、構造的に水と油の関係にあるのだ。
—
3. プロセス再利用とメモリリーク・ステート汚染の恐怖
PHP-FPMが `pm = static` や `pm = dynamic` で動作している場合、1つのOSプロセスは複数のリクエストを順次処理するために使い回される（`max_requests` に達するまでプロセスは生存し続ける）。
ここで、もしアプリケーションコード内のどこかでFiberやグローバルな状態管理、あるいは不適切なクロージャのキャプチャによって静的プロパティやシングルトンにリクエスト固有のデータが残留した場合、どうなるか。
次のリクエスト（別ユーザーのコンテキスト）が同じFPMプロセスに割り当てられた瞬間、前回の残骸であるステート汚染（State Pollution）が発生する。これは重大なセキュリティインシデント（データ漏洩）に直結する。
さらに深刻なのがメモリリーク（Memory Leak）である。Fiberはその実行状態（ローカル変数、オブジェクト参照、コールスタック）をヒープ上に保持する。もしFiberの実行中に例外が発生してキャッチされなかったり、イベントループの参照サイクル（Circular Reference）が適切に切断されなかったりすると、`zend_fiber` 構造体およびそれに紐づくすべてのZend変数（`zval`）がFPMプロセスのメモリ空間に残留し続ける。
hugeData = str_repeat(‘A’, 1024 1024); // 1MBのダミーデータ
}
}
// リクエスト処理関数
function handle_request() {
$container = new LeakContainer();
// クロージャが $container をキャプチャし、さらに Fiber がクロージャを保持する
$container->fiber = new Fiber(function() use ($container) {
// 意図的な中断
Fiber::suspend();
// $container->fiber -> クロージャ -> $container という循環参照が成立
});
$container->fiber->start();
// スクリプト終了時に $container がスコープ外に出ても、
// Fiberのコンテキストが解放されない限りメモリはリークし続ける。
// FPMプロセスが再利用されるたびにメモリ消費量が右肩上がりに増加する。
}
Zendエンジンは通常のスクリプト終了時に `EG(symbol_table)` などを解放するが、孤立したFiberインスタンスや、イベントループのグローバルなタイマー・ストリームに登録されたままのクロージャは、ガベージコレクションの網をすり抜けてプロセス内に幽霊のように残り続ける。これが、FPM環境下における非同期コードの最大の脅威である。
—
4. セキュリティハック：Fiberコンテキストとオブジェクトインジェクションの交差点
低レイヤの視点において、PHPのメモリ管理とオブジェクトのライフサイクルを語る上で避けて通れないのがPHPオブジェクトインジェクション（PHP Object Injection）である。
古くから存在するこの脆弱性は、`unserialize()` に信頼し切れないユーザー入力を与えることで、任意のクラスの `__wakeup()` や `__destruct()` マジックメソッドを強制発動させ、ガジェットチェーン（Gadget Chain）を構築してリモートコード実行（RCE）を達成する攻撃手法だ。
では、このオブジェクトインジェクションが Fiberおよび非同期イベントループのコンテキスト と交わったとき、何が起きるか。攻撃者は単なる破壊的なマジックメソッドの連鎖にとどまらず、Zend VMの実行コンテキストそのものを乗っ取るという極限のハックを仕掛けることが可能になる。
ガジェットチェーンの進化：Fiberを標的としたシリアライズ攻撃
PHPの `Fiber` オブジェクト自体は、内部にCレベルのポインタや実行ステート（`zend_fiber_context`）を大量に保持しているため、原則として直接シリアライズ（`serialize()`）することは不可能であり、試みれば例外がスローされる。
しかし、アプリケーション側が「非同期タスクのキュー」や「中断されたFiberの状態を永続化（データベースやRedisへ保存）」するために、Fiber内部のクロージャや、Fiberをラップしたカスタムオブジェクトを誤ってシリアライズ対象に含めてしまった場合、扉が開く。
/
class AsyncJobQueue {
public $taskCallback;
public function __construct(callable $callback) {
$this->taskCallback = $callback;
}
public function __destruct() {
// デストラクタでタスクを実行する設計（典型的なガジェットの温床）
if (is_callable($this->taskCallback)) {
call_user_func($this->taskCallback);
}
}
}
// 攻撃者が入力を捏造し、unserialize() を実行させる脆弱性が存在すると仮定
// 攻撃ペイロードの例：
// $payload = ‘O:14:”AsyncJobQueue”:1:{s:12:”taskCallback”;s:6:”system”;s:11:”id_or_cmd”;s:10:”id; id”;}’;
もしアプリケーションが、イベントループや非同期キューの内部でシリアライズされたオブジェクトを復元し、その中でFiberやクロージャの再構築を行っている場合、攻撃者はシリアライズデータ内のプロパティを書き換えることで、Zend VMが次に評価する関数ポインタを偽装することができる。
さらに高度な攻撃では、OPcacheプリローディング（Preloading）環境の脆弱性を突く。OPcacheプリロードは、サーバー起動時にスクリプトをメモリ（SHM: Shared Memory）上に永続化し、すべてのFPMプロセスがそれを共有する。プリロードされたクラスにオブジェクトインジェクションの足場（脆弱なマジックメソッド）が存在した場合、その影響範囲は単一のリクエストやプロセスを越え、サーバー上の全プロセス、全ユーザーに波及する致命的な特権昇格・コード実行基盤と化す。
—
5. 極限の知見：PHP-FPM環境でFiberを安全に飼い慣らすための鉄則
ここまで解説した通り、PHP-FPMとFiber、そして非同期イベントループの組み合わせは、Zend VMの設計思想およびセキュリティモデルの観点から極めて爆弾を抱えたアプローチである。
それでもなお、I/O効率化のためにFiberの概念を取り入れたい、あるいはモダンなライブラリの依存関係でFiberが背後で稼働している場合、アーキテクトとして以下の防衛策を徹底しなければならない。
1. FPM環境では純粋な非同期イベントループ（`EventLoop::run()`）を回さない
PHP-FPMの文脈において、Fiberを使うべきシーンは「真の非同期サーバー（Swoole/RoadRunner）」上に限られる。FPMでこれをやろうとするとプロセスが詰まり、スケーラビリティが完全に破壊される。FPMでは素直に同期処理、またはマルチプロセス（pcntl）による並行処理を選択すべきである。
2. リクエスト終了時の完全なクリーンアップ（Destructorの強制と循環参照の排除）
もしFiberをリクエスト内で一時的に利用する場合（例：特定の並行HTTPクライアントのラップなど）、スクリプト終了時には必ずすべてのFiberインスタンスの参照を断ち切り、明示的に破棄すること。
`gc_collect_cycles()` を適切に呼び出し、Zend VMのメモリプールにゴミを残さない構造を徹底する。
3. シリアライズ境界の厳格な検証
`unserialize()` は信頼できない入力に対して絶対に実行してはならない。もしオブジェクトの永続化が必要な場合は、JSONなどの安全なデータフォーマットに変換し、クラスの自動復元（マジックメソッドの自動実行）を伴うネイティブシリアライズを完全に排除せよ。
—
結びにかえて
PHPは「手軽なスクリプト言語」から、JITコンパイラを搭載し、型システムを厳格化させた「高度なWebアプリケーションプラットフォーム」へと進化を遂げた。Zend VMの内部構造、オペコードの挙動、そしてメモリ管理のプリミティブを理解したエンジニアにとって、PHPはもはやブラックボックスではない。
しかし、言語機能のモダン化（Fiberやアトリビュートなど）に飛びつくあまり、その背後にあるPHP-FPMのプロセスモデルやShared-Nothingの哲学を無視すれば、システムは必ずやメモリリーク、ステート汚染、そして致命的なセキュリティ脆弱性という名のしっぺい返しを受けることになる。
技術の真髄を極めるとは、新しい機能を使うことではなく、その機能が低レイヤでどのような代償を払っているかを完全に掌握することに他ならない。アーキテクトよ、常にZend VMの鼓動を感じながらコードを書け。