2026年10月21日に公開されたPHPの修正版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）は、脆弱性php2shell（CVE-2026-109618/109619）を、メモリ不足時の処理の作り直しとリクエスト間に残る内部状態の初期化で塞いでいます。修正はphp-srcの1本のコミットにまとめられ、389ファイルにわたる変更です。GitHub上では10,759行の追加・988行の削除と表示されています（調査時点: 2026年10月22日）。
変更が大きい分、修正版の公開直後から不具合の報告も出ています。それでも更新を見送る理由にはなりません。更新したうえで、エラーログと主要機能の動作を確認するのが現実的な進め方です。
脆弱性そのものの概要と、まず何をすべきかはphp2shellとは？影響範囲と今すぐやるべき対応で整理しています。本記事はその続きとして、パッチの中身と更新後の確認点を扱います。
修正の中身を3つに分けて見る
修正コミットのメッセージは、中断による状態の破損を防ぐという内容です。PHP 8.2のブランチに入り、8.3・8.4・8.5へ順にマージされています。中身は大きく3つに分かれます。
| 修正 | 何が問題だったか | どう直したか |
|---|---|---|
| メモリ不足時の処理 | メモリ確保に失敗すると、処理の途中から強制的に抜けていた。データ構造が中途半端なまま残り、次のリクエストで使われうる | 失敗を記録しておき、安全な地点まで処理を進めてから止める方式に変更。失敗しうる箇所はエラーを返して呼び出し元で処理する形に書き換え |
| リクエスト間の状態 | 起動時やリクエストの準備中に参照される内部の変数が、前のリクエストの値を引きずることがあった | 参照されうる変数を、リクエストの区切りで確実に初期化するように修正 |
| アップロード進捗のセッション処理 | ファイルアップロード中に、リクエストの準備が終わる前にセッションのデータを復元していた | 準備前の復元では、利用者が定義したクラスの読み込みや復元時の処理を実行しないように制限。初期化に失敗したら処理を打ち切る |
出典: php-src コミット 3584a98、GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp（調査時点: 2026年10月）
メモリ不足時の「強制的な中断」をやめた
1つ目の脆弱性（CVE-2026-109618）の原因は、メモリ不足が起きたときの処理です。これまでのPHPは、メモリの上限（memory_limit）を超えると、その場で処理を打ち切ってリクエストの終了処理に飛んでいました。打ち切られた時点で作りかけだったデータ構造は、中途半端な状態のまま残ります。攻撃者はこれを利用し、意図的にメモリ不足を起こしてから、続くリクエストでその残骸を使わせていました。
修正版では、メモリ不足を「起きた」と記録するだけにして、処理が安全に止められる地点まで進んでから止めるようになりました。そのために、配列や文字列、JSON、文字コード変換、正規表現など、メモリを確保する多くの箇所が「失敗したらエラーを返す」形に書き換えられています。変更が1万行を超えたのはこのためです。
新しい設定 memory_hard_limit_percent
処理を安全な地点まで続けるということは、memory_limit を超えてもしばらくはメモリを使い続けるということです。その歯止めとして、修正版には新しい設定項目 memory_hard_limit_percent が追加されました。この「ハード上限」を超えると、PHPはプロセスを即座に終了させます。
既定値は、memory_limit が1GB未満ならその200%、1GB以上なら1GBの余裕を持たせる値です（PHPのソースコード上のコメントによる）。たとえば memory_limit=256M なら、512MB前後でプロセスが終了することになります。サーバーのメモリに余裕がない環境では、ワーカー数とあわせて見直しが必要になる場合があります。
セッションのアップロード進捗を制限した
2つ目の脆弱性（CVE-2026-109619）で確認されている攻撃経路の1つが、ファイルアップロードの進捗を扱うSession Upload Progress機能です。修正版では、アップロードの開始時にセッション用の内部状態を初期化し直し、リクエストの準備が終わる前に行うセッションデータの復元では、利用者が定義したクラスを読み込まないように制限しました。
公式アドバイザリによれば、CVE-2026-109619には、このセッションの経路のほかに、PHP 8.5で致命的エラー時のバックトレース機能を使う経路も確認されています。こちらは状態の初期化の修正で塞がれています。
利用中の環境に修正を反映する手順は、php2shellのサービス別対応状況で確認できます。レンタルサーバー・クラウド・Linux・Dockerごとに、利用者が行う作業を整理しています。
修正版の公開直後に報告されている不具合
修正版の公開から1日以内に、php-srcのリポジトリには次のような不具合が報告されています（調査時点: 2026年10月22日、いずれも未解決）。
| 報告 | 対象 | 内容 |
|---|---|---|
| #24488 | 8.4.27 / 8.5.12 | SimpleXMLの処理でメモリ破損が起きる。php2shellとは別の修正が原因とされる |
| #24492 | 修正版全般 | ハード上限に達すると、通常のメモリ不足エラーではなく終了コード137でプロセスごと終了する |
| #24493 | 8.5.12 | アップロード進捗の処理が、特定の名前のプロパティを含むセッションを丸ごと破棄する |
| #24497 | 修正版全般 | memory_hard_limit_percent の既定値の表示が空になる |
8.2.35と8.3.36は今回の脆弱性の修正だけを含むリリースです。8.4.27と8.5.12には通常のバグ修正も多く含まれているため、影響を受ける範囲が少し広くなります。
更新の検証と本番反映を日頃から回す方法は、Webサービス事業者のセキュリティ対策で整理しています。
更新後に確認すること
更新作業そのものより、更新後の確認で見落としが出やすくなります。次の順で確認してください。
- Webサーバー経由のバージョン——phpinfo() や管理画面で、Webサイトを動かしているPHPが修正版になっているかを確認する。コマンドラインの
php -vだけで判断しない - ワーカーの再起動——PHP-FPMやApacheのワーカーがすべて入れ替わっているかを確認する。古いプロセスが残っていると、修正前のPHPが動き続ける
- エラーログ——メモリ関連のエラーや、終了コード137によるプロセスの異常終了が増えていないかを確認する
- 主要機能の動作——ファイルアップロード、XMLやRSSを扱う処理、ログイン状態の維持（セッション）を実際に操作して確認する
- 緩和策の扱い——更新前に入れた緩和策（
session.upload_progress.enabled=0など）を戻すかどうかを決める。アップロードの進捗表示を使っていないなら、無効のままでも困らない
更新・動作確認・委託先への連絡を誰が担当するかは、php2shellへの職種別の対応で整理しています。
当社でお手伝いできること
当社は受託開発のほか、技術顧問・SRE顧問として、インフラの構成管理やデプロイの自動化、障害対応の手順づくりを担当しています。「修正版に上げたら動かない処理がある」「どの不具合が自社に関係するか判断できない」といった段階からご相談いただけます。
更新後の確認や、今後のPHPの更新を回せる体制づくりについては、SRE顧問へのお問い合わせからご連絡ください。