PHP2Shell緊急対応ガイド──AWS・旧PHP・AI時代の脆弱性対応を整理する【CVE-2026-109618／109619】

1. 結論：修正版は公開済み。まず実際に動くPHPと、その配布元を特定する

情報確認：2026年10月21日23:55 JST（14:55 UTC）。 PHP公式の公開後情報に基づく初版。以後の変更は末尾の更新履歴に記す。

2026年10月21日、PHPは認証なしのリモートコード実行につながる2件の重大な脆弱性を修正した。識別子は CVE-2026-109618／CVE-2026-109619、深刻度はともに CVSS v4.0 9.2（Critical）。研究者がPHP2Shellと呼ぶ問題である。23時JSTは事前に告知された公開予定時刻であり、本稿の確認時点では待機する段階を過ぎている。^[1][2]

これは上流リリースの表である。OSベンダーが古い版番号へ修正を移植している場合は、そのベンダーのアドバイザリとパッケージの完全な版番号で判定する。PHP 8.2の上流セキュリティサポート期限は2026年12月31日。今回を直す作業と、次の更新先を決める作業を分けて管理したい。^[3][14]

本稿の提案は、「公開経路を狭める」「保守された修正版へ置き換える」「置き換わった証拠を残す」を並行することだ。更新できないシステムにも選択肢はある。ただし、修正を入れずに無期限で公開を続けられる万能設定はない。

最初に埋める情報は、サービス名、外部入口、SAPI（PHPの実行方式）、Web側の版、OS・配布元、実行イメージ、担当者の7つ。php -vだけでは、別のバイナリで動くPHP-FPMやApacheの状態は確定しない。サーバーが複数台あれば、代表1台の結果を全体へ広げない。

2. 何が壊れたのか：異常終了で取り残されたメモリを、後片付けや次の要求が使う

研究者は少なくともPHP 5.4まで遡る影響経路を報告している。ただし、すべての旧版が同じ条件・同じ経路で攻撃できるという意味ではない。旧版も棚卸しから外さず、対象系列の修正情報を確認する。^[7]

PHPのアプリケーションは、PHPランタイムがリクエストを受け取り、入力を解析してから実行される。今回の中心は、そのランタイム内部のメモリ管理だ。SQLインジェクションのように個々のアプリのクエリを直す問題とは、修正箇所が異なる。

CVE-2026-109618は、メモリ不足時の中断と後片付けの不整合。 内部データを初期化し終える前にOOM（out of memory）が起きると、終了処理が未完成の状態を有効なデータとして扱い得る。PHP公式は、mod_phpの通常構成で、アプリケーションが実行される前の認証不要RCEを検証したと説明している。修正ではOOM時の制御フローを変更し、安全な時点での終了と、さらに深刻な不足時のプロセス終了を組み合わせる。^[4]

CVE-2026-109619は、リクエストより長生きした参照の問題。 ある要求のメモリを解放したのに、ワーカーがその参照を保持する。次の要求が同じワーカーに入り、通常の初期化より先にその参照を使うと、解放済みメモリの使用（use-after-free）が起こり得る。致命的エラーだけでなく、終了処理中の診断が状態を再び残す経路もある。^[5]

ワーカーは同じでも、要求ごとのメモリは入れ替わる。古い参照を次の要求が使う、という寿命の食い違いを表した比喩。

業務コードが正しくても、その下の層に問題があれば影響を受ける。研究者はWordPressなど複数のアプリでRCEを実証し、RCEに到達せずプロセスメモリを読み出す影響も報告している。これらは研究環境での実証であって、その製品の全利用者が侵害されたという被害報告ではない。^[6]

CVSSの9.2は緊急性を示すが、攻撃の成功率ではない。公式のベクトルには攻撃の複雑さが高いこと、成立要件があることも含まれる。ビルド、拡張、入力の処理、ワーカーの振る舞いで条件は変わる。だからこそ、公開された一つの再現例が自分の環境で失敗しても「対象外」の証明にはならない。

3. どんなシステムが危ないか：実行方式と到達経路で優先度を決める

PHP公式は、PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeedを含む、Web要求を処理するPHP全般に更新を求めている。特に優先するのは、インターネットに公開した未修正mod_php環境だ。アプリ内ログインより手前で入力解析が動くため、アプリ側の認証を置いた事実だけでは境界にならない。^[1]

FPMについては区別が重要だ。要求の初期化に失敗するとワーカーが終了するため、mod_phpと同じ起動時シーケンスは成立しない。一方、通常起動後にアプリ処理が状態を残し、後続要求がそれを消費する経路が検証されている。ある攻撃経路が止まることと、ランタイム全体が修正済みであることは別の判定になる。^[5][7]

担当チームの優先順位は「外部から到達できるか × 実証された条件に近いか × 侵害後に触れるデータと権限」で決める。内部向けでも、VPN利用者、侵害された端末、他サービスから届く経路があれば対応は必要だ。外部公開の停止は強い暫定策だが、残る内部経路も台帳に書く。CERT-EUも即時修正ができない場合の公開ネットワークからの隔離を勧めている。^[8]

Log4Shellと比較して役立つのは、深く組み込まれた依存関係の所在を探し、各配布元の修正を全稼働系へ届ける運用上の難しさだ。攻撃方式や実被害規模を同一視する必要はない。本稿では今回の世界的な侵害件数を確定していない。IPAの事前注意喚起も、その時点で悪用を確認したという発表ではなかった。^[2]

4. AWSでは：PHPを直す責任と、侵害後の権限を分けて見る

以下は架空の構成による運用例で、特定企業の環境ではない。

Internet → CloudFront / AWS WAF → ALB → PHP-FPM / mod_php
                                           ├─ DB接続権限 → RDS
                                           └─ 実行ロール → S3等

EC2のゲストOSやアプリケーションは利用者側の管理範囲に含まれる。クラウド基盤が保護されていても、自分が配置したPHPの修正は別に必要になる。^[9]

• EC2／Auto Scaling：稼働インスタンスの更新に加え、AMI、起動テンプレート、初期化処理を直す。増設時に古いPHPが戻らないことを確認する。
• ECS／EKSのコンテナ：PHPを含むイメージを再ビルドし、固定したdigestで展開する。EC2ホストのパッケージ更新だけではコンテナ内は変わらない。サービス、Job、CronJob、待機系まで見る。
• Fargate：基盤の管理が減っても、アプリイメージ内のPHPは更新対象。タスクの分離は、侵害された同じタスク内のデータを守る保証ではない。
• Elastic Beanstalk／ホスティング製品：提供元の修正版プラットフォーム・対応版を確認し、環境へ適用する。自前で追加したPHPは別管理になり得る。
• Lambdaのカスタムランタイム／コンテナ：PHPを同梱しているなら、その配布元・レイヤー・イメージを確認する。関数の実行方式を調べず、全Lambdaが同じ攻撃条件だとは決めない。

ここで怖いのは、RCEがroot権限を意味しなくても、業務上の被害は十分大きいことだ。PHPの実行ユーザーが読める設定、環境変数、DB資格情報は、侵害後に読み取られる可能性がある。さらにアプリに与えたIAM権限でS3等へアクセスされる可能性もある。これはRCE成立後の一般的な脅威モデルであり、今回その被害が観測されたという意味ではない。

ECSでは、アプリが使うtask roleと、イメージ取得等に使うtask execution roleを区別する。前者を必要なAPI・リソースへ絞る。EC2上のコンテナでは同居タスクやインスタンスメタデータへのアクセス境界も確認する。AWSは、コンテナ自体をセキュリティ境界とみなさないこと、Fargateではタスクごとの分離境界を持つことを説明している。^[10]

IMDSv2の必須化は有用だが、ホスト上でコード実行を得た攻撃者への万能な遮断策ではない。IMDSv2はトークンを発行してアクセスする仕組みであり、その操作が可能な実行権限と到達性があれば悪用余地が残る、というのが本稿の脅威分析だ。使わないメタデータ経路の遮断、最小権限、DBの権限分離、外向き通信制限を合わせる。^[11]

5. 更新までの防御：入口制限を先に、設定変更は残余リスクとセットで

公開を続けるかは、サービス責任者とセキュリティ担当が、データの重要度・停止影響・修正の見込みを揃えて判断する。本稿の推奨は、修正版を用意できず、十分な入口制限もできない重要系では、PHPを通らない静的な案内へ切り替えること。アプリ内にメンテナンス画面を置くだけでは、そこへ届くまでにPHPが入力を解析してしまう。

許可IP、VPN、前段プロキシの認証は、PHPへ届く主体を絞るために使う。CloudFrontだけを制限しても、ALBの直接URLや別ホスト名から到達できれば穴が残る。オリジンへの経路、IPv6、別ポート、古い環境も確認する。

入口を守るには、正面だけでなく迂回路も閉じる。クラウド構成図と実際の到達経路を照合する。

AWS WAFの「検査上限」と「拒否上限」を混同しない

AWS WAFが本文を検査できる範囲は、ALBでは8 KB固定、CloudFrontでは既定16 KB、最大64 KB。検査範囲を超えた部分が自動的に切り捨てられてPHPへ届かなくなるわけではない。許可された要求は全体が転送される。^[12][13]

超過時の処理にはContinue、Match、No matchがある。拒否が目的なら、対象ルールのアクション、超過時の扱い、先行Allowルール、例外パスを一緒に確認する。例えばBlockアクションとMatchの組合せは超過要求を拒否するが、正規のアップロードも止め得る。対象パスを把握し、実リクエストで業務影響を確認する。これは今回専用の完全防御ルールではない。

PHP公式の暫定策は、設定一つで完了しない

公式の現時点の案内には、次が含まれる。適用する際はリンク先の最新版を読み、全ワーカーへ反映して再起動する。^[1][4][5]

• OOM経路：管理者設定でmemory_limit=-1を強制すると、PHPの有限な上限を利用する既知の経路を減らせる。ただしOS側の確保失敗は残る。メモリ無制限化は可用性リスクを増やすため、入力制限、監視、適切なコンテナ／cgroup境界の設計なしに投入しない。RLIMIT_AS／RLIMIT_DATAで置き換えると、問題の確保失敗を引き起こし得る。
• セッション経路：要求解析前に有効なサーバー設定でsession.upload_progress.enabled=0。アプリのini_set()やFPMの.user.iniではタイミングが遅い。これは確認済みのセッション経路への対策で、他の変種を消さない。
• PHP 8.5：fatal_error_backtraces=0で、確認済みのバックトレース経路を減らす。これも全経路の修正ではない。
• 入力と診断：前段で本文・multipart・ヘッダー・入力の深さを制限し、不正な要求単位設定を修正する。エラーを非表示にするだけでは対策にならない。

小さいpost_max_sizeだけに頼らず、宣言された長さと実際にデコードされる量の違いも扱う。不要ならmultipartを前段で拒否する。その場合も、APIクライアントや連携処理が暗黙に使っていないか確認する。設定変更で業務を壊す場合は、例外を無制限に開けるのではなく、利用者・パス・期間を限定した代替経路に切り分ける。

6. 古いPHPを上げられない場合：保守元の修正を第一候補にする

レガシー対応で大きいのは、修正行数よりも「動作が変わっていない」と説明するための検証範囲だ。古いフレームワーク、削除されたAPI、拡張、DBドライバー、暗黙の型変換、帳票やバッチの境界条件が移行を難しくする。緊急対応と技術的負債の解消を、同じリリースへ無理に詰め込まない。

第一候補は、現在使っているディストリビューションや保守ベンダーの修正済みパッケージ。 バックポートは、新版の修正を旧系列へ移植する方法で、機能の互換性を保ちながら特定の問題を直せる場合がある。対象CVE、対応アーキテクチャ、拡張、配布チャネル、サポート契約の適用範囲まで確かめる。^[14]

今回、UbuntuのUSN-8948-1には、Ubuntu 22.04 LTS向けPHP 8.1パッケージ 8.1.2-1ubuntu2.28 が修正版として掲載されている。上流の8.1が通常サポートを終えていても、配布元から修正が届く具体例だ。他OSへこの版番号を当てはめたり、8.1.2という先頭部分だけを見て未修正と判断したりしない。^[15]

第二候補は、信頼できる延長保守の導入。 契約の有無だけで安心せず、今回の2つのCVEへの対応、提供予定、署名済み成果物、修正の検証範囲、次の問題への責任主体を確認する。保守契約は将来のすべての修正を無条件に保証するものではない。

第三候補は、管理されたソースバックポート。 PHP公式は今回、PHP 7.4／8.0／8.1向けの最小限のソースバックポートも案内している。これは通常の旧系列サポート再開を意味しない。ベンダーパッケージと、自分たちでビルド・試験・配布を引き受けるソース修正は、運用上の責任が違う。^[1]

バックポートは、既存の形を保ちながら問題箇所を直す作業。周囲との接合と、修正後の動作確認が品質を決める。

以下は本稿が提案する、自前修正を選ぶための最低条件である。

1. 原因と修正範囲：対象版に該当する経路を確認し、公式の修正コミット・後続修正・テストを対応づける。一つの再現ケースだけを塞いで完了にしない。
2. 再現可能なビルド：ソース、適用パッチ、コンパイラ、設定、拡張、依存ライブラリ、成果物ハッシュを保存する。配布物は自組織の管理経路で検証できるようにする。
3. 二種類の試験：隔離環境で「修正前は失敗し修正後は直る」を確かめるセキュリティ回帰試験と、業務の入出力を守る互換性試験を分ける。WebのSAPI、OPcache、拡張、同時要求も本番相当で試す。
4. 保守する人と期限：レビュー担当、次のCVEへの追従責任、公開継続の承認者、旧系列からの退出期限を決める。

これらが満たせない場合は、場当たり的な独自ビルドを公開するより、隔離・対象機能停止・業務代替を選ぶ。自前パッチに成功しても、旧ランタイム全体の安全証明にはならない。緊急修正の完了条件と、移行プロジェクトの完了条件を別チケットで残す。

7. 適用を完了させる：ファイル更新から、全稼働系の確認まで

パッケージが入ったことと、サービスが修正版で動いていることの間には距離がある。以下は環境に合わせて使う確認手順の例であり、一括更新コマンドではない。

# 実行したCLIについての情報。Web側の証明とは分けて記録する
php -v
php --ini

# Debian / Ubuntu系：インストール済みの完全なパッケージ版
# CVEに対応した配布元アドバイザリと照合する
dpkg-query -W 'php*' 'libapache2-mod-php*'

# RPM系の例
rpm -qa 'php*'

Web側は、既存の管理用診断やアクセスを限定した一時的な確認経路で、実際のPHP_VERSION、PHP_SAPI、読み込まれた設定、ビルドの識別情報を取得する。公開したphpinfo()ページを残さない。ディストリビューションの修正判定には、Webの版文字列だけでなくパッケージのリビジョンも要る。

推奨する展開順序は次のとおり。

1. 対象を固定：本番、管理画面、別ドメイン、バッチ、待機系を台帳化。使っていない環境は停止する。
2. 修正版を検証：ベンダー案内、署名、イメージdigestを記録。ログイン、決済、保存、アップロード、セッション、非同期処理など、そのサービスの重要経路を試す。
3. 小さく切り替える：カナリアや一部インスタンスから展開し、エラー率、遅延、メモリ、ワーカー再起動を監視する。許容値は平常時実績から決める。
4. プロセスを入れ替える：FPMやApacheを適切に再起動・置換し、古いワーカーが残っていないか確認する。ファイルが新しくても、常駐プロセスは旧コードを保持し得る。
5. 再作成を試す：新規インスタンス／タスクを起動しても修正版になることを確認。ロールバック先も修正済みにする。未修正版へ戻す必要があるなら、先に外部公開を閉じる。
6. 証跡を残す：対象ごとに、完全な版、配布元、digest、稼働確認時刻、確認者、残る例外と期限を記録する。

更新の途中でも侵害の兆候があれば、通常のパッチ作業からインシデント対応へ切り替える。ログと必要な証拠を保全し、隔離、調査、クリーンな成果物からの再構築を行う。秘密情報の失効・再発行やセッション無効化は、侵害範囲を踏まえて実施する。更新はすでに盗まれた情報や設置済みの不正コードを取り消さない。

Wizは、異常なmultipart要求、メモリ上限エラー、HTTP 500の繰り返し、異常なセッションCookie、ワーカーの不自然な入れ替わりを調査の手掛かりに挙げている。単独では攻撃の証明にならない。アプリログに到達しない経路もあるため、前段アクセスログ、OS・コンテナ、CloudTrail等の時刻を突き合わせる。^[6]

CloudTrailはPHP内部のコード実行そのものを記録する装置ではない。記録対象のAWS API活動を見るものとして扱い、S3等のデータイベントを含む必要なログが事前に有効だったか確認する。「アラートがない」と「侵害がない」を同じ完了条件にしない。^[17]

8. AIはどう見つけたのか：仮説を実験し、失敗パターンを横展開する

今回のAI関与は公表されている。WizはWiz Atlas、Gemini 4 Argon、GPT-5.6 Solの利用を説明し、OpenAIはCalifがGPT-5.6 Solを用いて重大な問題を発見したこと、Wizも独立して発見・報告したことを記している。単独のAIが自動で全部発見した、という話ではない。^[6][16]

Califの技術解説が興味深いのは、研究者が過去のPHPの問題を踏まえ、「異常終了でどこが中断されると危険か」という問いを与えた点だ。モデルはソースをたどり、状態の公開・失敗し得る処理・初期化完了の順序に着目した。さらに、見つかった構造をSKILL.mdへ一般化して、別の箇所へ探索を広げている。^[7]

価値があるのは、もっともらしい指摘を並べることより、仮説を試し、外れた理由を使って次の探索を絞ること。

これを防御側の作業へ翻訳すると、次のような反復になる。以下は公開事例を踏まえた一般化した運用案だ。

• 読む：入力、メモリの所有者、初期化、終了処理、エラーで飛び越える箇所を結ぶ。関数名だけで危険判定しない。
• 仮説を立てる：「途中で失敗したら、誰が不完全な状態を読むか」を具体化する。
• 隔離して試す：許可されたローカル環境で最小の再現ケース、デバッガ、サニタイザー、テストを使い、実際の失敗と照合する。
• 類似箇所を探す：同じ所有権・寿命のパターンを、別の版や拡張へ展開する。
• 修正を疑う：元の再現が止まった後も、近い変種と通常動作を試す。修正レビューに反証の役割を持たせる。

AIは広いコード探索と反復を助ける。一方、疑わしいコード、クラッシュ、情報漏えい、RCEは異なる到達点である。モデルの説明だけで最終到達点へ飛躍せず、確認できた証拠を段階ごとに残す。研究者の成果から、あらゆるシステムの調査日数やコストが同じ割合で減るとは言えない。

レガシー保守でも、AIに任せる単位を成果物で区切ると使いやすい。アドバイザリ整理、旧版との差分調査、ビルド定義、回帰テスト案、デプロイ台帳の照合を分ける。各作業には参照元の版、判断の根拠、未確認事項を残し、次の担当が再取得できるようにする。パッチ採用、秘密情報の操作、本番切替は、人が証拠をレビューして判断する。

9. 次の緊急事態に備える：対応速度は、平時に残した情報で決まる

次に別のランタイムで同じことが起きたとき、「何台あるか」から調べ始める状態を減らしたい。次の5点を平時の運用へ入れることを提案する。

資産と依存関係。 サービスとSAPI、OSパッケージ、コンテナdigest、SBOM、担当者、サポート期限を結ぶ。SBOMだけでは、どの古いイメージが今も公開されているかまでは分からない。実行中の棚卸しと対応づける。

修正を受け取る経路。 上流とOSベンダーの通知先、緊急連絡先、延長保守の対象、署名検証方法を決める。新しいCVEが出たら、版番号比較だけでなく、ベンダーの修正状態を取り込む。

止め方。 PHPを通さず案内を出す経路、入口制限、管理者の緊急アクセス、代替業務を準備する。稼働を続ける例外には、責任者・理由・残余リスク・期限・次回見直し条件を必須にする。

戻し方と検証。 重要な業務フローの自動テスト、修正済みのロールバック先、秘密情報の交換、バックアップからの復旧を練習する。新規起動が未修正版へ戻らないこともテスト対象にする。

測り方。 通知から対象特定まで、対象特定から入口制限まで、修正公開から全稼働系確認までの時間を測る。「パッチを配った台数」だけでなく、「未確認の例外が何件残るか」を完了判断に使う。

今回の対応を終える最低条件は、対象資産が分かり、修正済みの実行物が全対象で動き、再作成しても戻らず、例外が期限付きで管理されていること。侵害の疑いがある資産は、別途その調査と復旧まで追う。緊急更新を、次回も再利用できる運用の記録に変えるところまでが仕事になる。

更新履歴と今後確認する項目

• 2026-10-22 初版（10月21日23:55 JST確認）：PHP公式の修正版公開、SAPI別の条件、暫定策、旧系列のバックポート、Ubuntuの対応例、AWS運用とAIによる発見を反映。
• 次の確認対象：PHP公式アドバイザリの訂正・追加修正、各OS／ホスティング／コンテナ配布元の修正状況、実悪用を示す公的機関・研究機関の観測、WAF提供元の適用範囲と回避条件、旧系列バックポートの更新。
• 現時点の未確定事項：世界的な実被害規模、各利用者環境の攻撃成立性、Amazon Linuxを含むすべての配布チャネルの修正提供状況。本稿では一律に「未提供」「安全」とは判定していない。

本稿は公開資料による技術解説であり、掲載構成は一般化した例である。個別環境での攻撃再現や各対策の実測を行った報告ではない。変更前には配布元の最新情報と自環境の検証結果を照合してほしい。