AI活用
読了 10分

PHP2Shell対策｜AIで進めるPHPバージョンアップと改修手順

目次
※本記事にはアフィリエイト広告(プロモーション)が含まれています。

PHP2Shell対策をどう進めるか、迷っていませんか。2026年10月21日に修正版が公開されましたが、PHP 8.1以前の環境では「更新するだけ」では済まず、コードの改修が必要になります。この記事では、対策の本命であるPHPの更新と、その改修作業をAIで効率化する手順をまとめます。結論は、更新は必須で、AIは改修コストを下げる役だという分担です。(情報は2026年10月22日時点のものです)

結論：PHP2Shell対策の本命はPHPの更新。AIは改修コストを下げる役

PHP2Shellは、PHP本体に見つかった2件のリモートコード実行(RCE)の脆弱性の総称です。対策は次の順で考えます。

  • 本命:修正版へ更新する。修正版は PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 です
  • PHP 8.1以前:公式サポートが終了しているため、サポート対象のバージョンへ移行する。7.4・8.0・8.1向けには、ソースからビルドする利用者向けの最小限のバックポート修正が出ています
  • 暫定策:WAFや設定変更は更新までのつなぎです。Cloudflareも、WAFを使っていてもPHPは更新するよう案内しています

AIが力を発揮するのは、更新後に動かなくなるコードの洗い出し、修正案の作成、テストコードの作成です。更新するかどうかの判断と、本番への反映は人間が行います。

移行先は、サポート期間で選びます。php.netの表では、PHP 8.2のセキュリティサポートは2026年12月31日まで、8.3は2027年12月31日、8.4は2028年12月31日、8.5は2029年12月31日までです。8.2は年内に期限を迎えるため、新たに移行するなら8.4か8.5が候補になります。

PHP2Shellとは何か

2026年10月21日に公開された、CVE-2026-109618とCVE-2026-109619の2件です。どちらもCVSS v4.0で9.2が付いています。

特徴は3つあります。

  1. 認証が不要:動作する攻撃コードが示されており、アプリケーションのコードが動く前の1回の未認証リクエストで発動できるとされています
  2. 原因はPHP本体:サイトのコードやプラグインを更新しただけでは直りません
  3. 対象が広い:PHP-FPM、Apache の mod_php、php-cgi、FrankenPHP、LiteSpeed が含まれ、mod_php 構成が最も危険とされています

一方で、攻撃の難易度は高いと整理されています。Impervaによると、成功にはタイミングとメモリ配置が関わり、失敗するとワーカーが落ちるだけの場合もあります。実際に悪用された事例は、各社の記事の時点では確認されていません。ただし動作する攻撃コードが出ているため、状況は変わりえます。

発見にはAIが使われました。Wizの研究チームは、AIを使って発見からエクスプロイト開発までを進めたと説明しています。攻撃側の作業がAIで速くなる以上、直す側も更新と改修の速度を上げる必要があります。

まず棚卸し：自社のPHPはどの区分か

最初に、動いているPHPのバージョンと運用形態を確認します。

現在のバージョン基本の対応改修の量
8.2〜8.5修正版(8.2.35 / 8.3.36 / 8.4.27 / 8.5.12)へ更新ほぼなし(同一マイナーの更新)
8.1以前サポート対象のバージョンへ移行あり(非推奨・削除機能の対応)

確認する項目は次のとおりです。

  • php -v でバージョンを確認する(Webサーバー用とCLI用で別のPHPが入っている場合があります)
  • ホスティング事業者がPHPを管理しているか。管理している場合は、事業者にセキュリティアップデートの適用を依頼します
  • Linuxディストリビューションやコンテナイメージの場合は、各ベンダーのアドバイザリを確認します。バージョン番号が変わらないままバックポート修正が入ることがあります
  • WordPress・Drupalなどのプラットフォームや、PHPを内部に組み込んだ製品も対象に含めます

なお、rpms.remirepo.net を使っている場合は、10月21日時点では更新が提供されない予定とされています。ディストリビューションのパッケージへ切り替えるか、ソースからビルドします。

更新までの暫定対策

すぐに更新できない場合のつなぎです。どれも完全な対策ではありません。

  • WAF:Cloudflareは2026年10月21日3:02(UTC)から、無料プランを含む全プランで既知の攻撃経路向けのルールを適用しています。Impervaも仮想パッチを提供しています。攻撃者は手法を変えて回避を試みるため、WAFは追加の防御層と考えます
  • PHP設定:Impervaは、テストを行ったうえで opcache.enable = 0 と session.upload_progress.enabled = 0 を検討できるとしています。ただし完全な回避策ではなく、これで保護されたとは言えないと明記されています
  • アクセス制限と権限の最小化:影響を受けるサービスへのアクセスを絞り、PHPプロセスが触れるファイルや認証情報を最小限にします
  • アップロード上限の設定:リスクは減りますが、PHPの修正の代わりにはなりません
  • 更新が難しいシステム:英国NCSCは、オフラインにすることの検討を呼びかけています

攻撃の兆候は、アプリケーションのログより、インフラ側に出やすいとされています。Wizは次の点を挙げています。

  • 不審なマルチパート(multipart)リクエストの後に出るメモリ上限エラー
  • HTTP 500の繰り返し
  • 異常に大きいPHPSESSIDのレスポンスクッキー
  • 原因不明のPHPワーカーの頻繁な入れ替わり

AIで進めるPHPバージョンアップ5ステップ

8.1以前から移行する場合の流れです。ポイントは、ツールとAIで役割を分けることです。

役割担当
機械的な書き換えRector
問題箇所の検出PHPStan、PHPCompatibility
影響調査・修正案・テスト作成・差分レビューAI
本番に入れる判断人間

1. 棚卸し：依存関係と拡張モジュールの洗い出しをAIに手伝わせる

composer.json、使用中のPHP拡張、自作コードの一覧を作ります。サードパーティ製のライブラリは、最新版の対応状況と、保守が止まっていないかを確認します。

AIには、次のように頼みます。

以下のcomposer.jsonとphp -mの出力から、PHP 8.4で動かない可能性があるものを
一覧にしてください。各ライブラリの対応バージョンが不明な場合は「要確認」と書き、
推測で断定しないでください。

AIの回答は、必ずパッケージの公式ページやリリースノートで裏を取ります。

2. Rectorの --dry-run で、機械的に直せる分を先に処理する

Rectorは、PHPコードの更新やリファクタリングを自動で行うツールです。PHP 5.3から8.5までの更新に対応しています。

composer require rector/rector --dev
vendor/bin/rector src --dry-run   # 変更内容を確認(ファイルは変更されない)
vendor/bin/rector src             # 変更を適用

設定はプロジェクト直下の rector.php に書き、ルールのまとまりは withPreparedSets() で有効にします。必ず --dry-run で差分を見てから適用してください。誤った変換や不完全な変換もあるため、慎重な検証が必要だと、PHP Conferenceの記事でも指摘されています。

3. 静的解析の指摘をAIに渡し、修正案を出させる

PHPCompatibilityは、phpcs で対象バージョンを指定して互換性の問題を検出します。ただし、ファイルをまたぐ解析や型推論はできません。PHPStanなどは型推論で、未定義変数や、インスタンスメソッドの静的呼び出しといった実行時の問題を洗い出せます。

出力されたエラーをAIに渡します。

以下はPHPStanの出力です。エラーごとに、原因・最小限の修正案・
修正で挙動が変わる可能性の有無を表にしてください。
型エラーを(int)などのキャストで黙らせる修正は提案しないでください。

キャストでエラーを隠すと、処理の流れが変わる危険があります。PHP 8.5へ上げる場合は、バッククォート演算子(shell_exec()の別名)の非推奨、boolean や integer といった非正規の型名でのキャストの非推奨、disable_classes INIディレクティブの削除などが、検出の対象になります。

4. 直す前に、現状の挙動を記録するテストをAIに書かせる

自動テストがない古いシステムでは、「旧バージョンで通る、現状の挙動を記録するテスト」(characterization test)を先に作ります。移行後にこのテストが落ちた箇所が、修正すべき箇所です。

次のPHP関数の現在の挙動を記録するPHPUnitテストを書いてください。
通常の入力に加えて、空文字・null・想定外の型を渡した場合の戻り値も記録し、
期待値は「現在のコードが返す値」にしてください。

テストコードの生成は、AIが短時間で下書きを出せる作業です。ただし、期待値が本当に現状の挙動と一致しているか、旧バージョンで実行して確かめます。

5. ステージングで検証してから本番へ

ステージング環境で新しいバージョンを動かし、画面の動作とあわせてメモリ使用量などの性能も確認します。本番には、切り戻せる状態で反映します。AIには、変更差分のレビューを頼めます。

このdiffをレビューしてください。挙動が変わりうる箇所、
セキュリティ上の懸念、テストが不足している箇所を挙げてください。

AIに任せていいこと・いけないこと

任せていい人間が判断する
非推奨・削除された機能の洗い出し本番への反映と切り戻しの判断
修正案の下書き認証・決済・暗号まわりの挙動変更の承認
テストコードの下書きキャストで型エラーを隠すような修正の採否
差分レビューの指摘依存ライブラリの採用・入れ替え

もう一つ、見落としやすいのがソースコードの外部送信です。DB接続情報やAPIキーをAIに渡さないのは当然として、顧客の業務コードをクラウドのAIに送ってよいかは、契約や社内ルールの確認が必要です。

外部に出せない場合は、手元の機械でローカルLLMを動かす方法があります。GMKtecは、AMD Ryzen AI Max+ 395など最新のAIチップに対応したモデルがあり、ローカルLLMやデータ分析の用途に使えるとされるミニPCブランドです。価格帯は約23,000円から315,000円と幅があり、1年保証と7日間の返品に対応しています。



向いていないのは、クラウドのAIにコードを送れる環境の人です。その場合は購入せずに進められます。ローカルLLMの精度や速度は、選ぶモデルとメモリ容量で変わります。クラウドのAIと同じ水準になるとは限らない点に注意してください。価格や仕様は変わる可能性があるため、最新の情報は公式サイトで確認してください。

よくある質問

WAFを入れていれば、PHPを更新しなくてもよいですか

更新は必要です。WAFは追加の防御層で、Cloudflareは「WAFがあってもPHPを更新するように」と案内しています。攻撃者はペイロードを変えてWAFの回避を試みるため、ルールの更新が追いつかない時期も想定されます。

PHP 8.1のまま使い続ける場合は、どうすればよいですか

8.1は公式サポートが終了しており、公式の修正版はありません。設定による暫定策は完全ではないため、サポート対象のバージョンへの移行を計画してください。ソースからビルドしている場合に限り、最小限のバックポート修正が出ています。ディストリビューションを使っている場合は、ベンダーの対応状況を確認してください。

AIが出した修正を、そのまま本番に入れてもよいですか

おすすめしません。Rectorは --dry-run で差分を確認し、AIの修正案はテストとステージングで検証してから反映します。誤った変換が混ざる前提で、確認の工程を置いてください。

社内にPHPに詳しい人がいない場合は、どうすればよいですか

ホスティング事業者がPHPを管理しているなら、事業者にセキュリティアップデートの適用を依頼します。コードの改修が必要な場合は、保守を任せている制作会社に相談してください。

まとめ：更新を先に、改修はツールとAIで速くする

優先順位は次のとおりです。

  1. 自社のPHPのバージョンと運用形態を確認する
  2. 8.2〜8.5なら修正版へ更新する。8.1以前なら移行を計画し、それまで暫定策で時間を稼ぐ
  3. 移行の改修は、Rector・静的解析・AIで役割を分け、テストとステージングで検証する

AIに指示を出して結果を検証するには、プログラミングの基礎が必要です。学び直したい場合は、Fast campusが生成AIやPythonを使ったプログラミングなどの講座を提供しています。買い切り型の講座が中心で、現役のプロ講師が基礎から実践までを教える内容です。PHP専用の講座ではないため、受講前に講座内容を確認してください。



PHP2Shellは、更新するまで続くリスクです。まず今日、自社のPHPのバージョンを確認するところから始めてください。

出典(2026年10月22日時点)

関連記事