どうやら世の中全貌が見えて来たようだ。見ものだとか言ってる場合じゃないｗ
テレビでも朝から大騒ぎになってるな。
予定されていた昨夜11時より前に修正コードも示されているが、アドバイザリにはこうある。
RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
影響を考慮してか「やんわり」とした表現になってはいるが、アウト・オブ・メモリーによって「部分的にしか初期化されていない状態」のままで処理が中断され、その後のエラーハンドリングにおいて無効なデータが有効なものとして扱われてしまうという話だ。一つ目のやつ、まずはこれがミソだな。
で、二つ目の方は、リクエストの内部状態がメモリ解放（Free）後に残存してしまう（Use After Free）バグがあるということ。
要は multipartデータのUploadなどがトリガーになって out of memory状態を作り出せる状況になるのが最もヤバい展開だと思われるが、それ以外でも、クライアント側からの強制切断など zend_bailout() を通る処理は条件によってはヤバそうだ。
最大の懸念である multipart/form-data のアップロードを、リクエスト処理以前にコアモジュールで引き受けてしまうところがPHPのアレな所なんだよな。だから素人が使うっぽいって…（以下自粛）
世界７割と言われるゆえんは代表的なCMSであるWordPressがまさにPHPで作られているからだ。知り合いの会社でもWebデザイン企業に発注した自社HPがWordPressで出来てると言ってて、今回速攻停止しようとしたんだけどOCNホスティングなんで、既に昨夜10時頃から顧客に有無を言わさず（笑）止められてたそうだ。
尚、一部言われていたphp.iniでのsession.upload_progress.enabledの無効化は微細な効力しか持たないと判明。何らかの理由で旧いバージョンを上げられず「速攻パッチ適用」も難しい場合は、upload_progress無効に加え memory_limit = -1 および fatal_error_backtraces = 0 でとりあえず逃げる。しかし根本的解決にはならんので注意な。