---
title: "PHP2Shell 企業サーバーのセキュリティ対策"
locale: ja
category: how_to
category_name: "ハウツー"
translation_status: reviewed
license: cc_by
author: "Injoys 編集部"
source_url: https://injoys.com/ja/articles/php2shell-enterprise-security-patch-response-guide
published_at: 2026-10-24T16:09:48+09:00
---

# PHP2Shell 企業サーバーのセキュリティ対策

> PHP2Shellへの対応は、実際のWebサービスのPHP更新と再起動から始めます。侵害が疑われる場合は、まず証拠を保全し、パッチ適用後もログの確認と認証情報の変更が必要です。

## Key Points

- 稼働中のサーバーと組み込み製品でのPHPの使用状況を確認してください。
- 侵害が疑われる場合は、サーバーを隔離し、再起動前に証拠を保全してください。
- 修正版を適用するか、更新までの間は公式の暫定措置を適用してください。
- PHPを実行するサービスを再起動した後、実際のWebサービスにパッチが反映されているか確認してください。
- 過去のログを確認し、外部にさらされたサーバーの認証情報を変更してください。

PHP2Shellへの対応は、PHPの使用状況の確認と修正版の適用から始めます。更新後は、実行サービスを再起動してください。侵害が疑われる場合は、再起動前に証拠を保全する必要があります。パッチ適用後もログの点検と認証情報の変更が必要です。

バージョンと設定は、2026年10月22日のKISAの告知と10月23日のPHPの追加告知に基づきます。

## PHP2Shellはどのような脆弱性ですか？

PHP2Shellは、認証なしでサーバー上のコードを実行できるPHPの脆弱性です。Webサーバーがリクエストを処理する過程でのメモリ管理の問題です。攻撃が成功するかどうかは、実行環境と設定によって異なります。

| 区分 | 識別番号 | 問題の性質 |
| --- | --- | --- |
| メモリ不足時の処理の問題 | CVE-2026-109618 | メモリ不足時に不完全な内部データを処理 |
| リクエスト間に残る状態の問題 | CVE-2026-109619 | 解放済みメモリを指す状態を後続のリクエストで使用 |

KISAは、2つの脆弱性の深刻度をCVSS 9.2点と案内しています。攻撃が成功すると、Webシェルの設置や顧客情報の流出が可能になります。Webシェルは、サーバーの遠隔操作に悪用されるファイルです。Webサイトの改ざんや内部ネットワークへの侵入につながる可能性もあります。

KISAは、パッチ配布前の情報流出と攻撃の試みについて案内しました。研究チームは、AIを活用した脆弱性の発見過程を公開しました。問題はPHP自体にあり、特定のWebサイト製品だけに限られません。[KISAの企業向け対応指針](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230)、[研究チームによるPHP2Shellの説明](https://www.php2shell.com/)

## 条件別の対応順序

侵害が疑われるかどうかによって、更新と証拠保全の順序が変わります。通常のパッチ作業では、テスト後に更新と再起動を進めます。侵害が疑われるサーバーは、まず隔離してください。

| 現在の状態 | 最初にすること | 続いてすること |
| --- | --- | --- |
| 侵害の兆候がない公開サーバー | 互換性の検討と修正版の適用 | 再起動、実際のバージョン確認、ログの点検 |
| Webシェルや不審な接続を発見 | ネットワークからの隔離と通報 | 証拠保全後の復旧措置 |
| すぐに更新するのが難しいサーバー | 公式の暫定設定と前段でのリクエスト制限 | パッチ適用日程の策定と適用 |
| 暫定措置も難しいサーバー | 外部接続の遮断または一時停止を検討 | パッチ適用後に再開するか判断 |
| ホスティング事業者・メーカーが管理する環境 | 管理業者に適用状況を確認 | 実行環境への反映を示す根拠を確保 |

更新後の再起動は、修正コードを実行するための手順です。インシデント対応中に再起動を見送る理由は、証拠保全です。同じサーバーでも、侵害が疑われる状態なら後者の順序に従ってください。

## PHPの使用状況を確認する方法

資産一覧と実際に稼働しているサーバーを併せて確認してください。代表的なWebサイトだけを点検すると、管理対象から漏れたサーバーを見逃す可能性があります。PHPを含む機器やコンテナも確認対象です。

1. インターネットに公開しているWebサイトとシステムを一覧にしてください。
2. 外注で制作したサイトと古いサイトを確認してください。
3. イベント用・テスト用サーバーと管理者ページを確認してください。
4. 機器の管理画面やソリューションにPHPが含まれているか確認してください。
5. コンテナイメージと実行中のコンテナを確認してください。
6. 各環境のPHPバージョンと管理担当者を記録してください。

ホスティングを利用している場合は、業者にパッチが適用されているか確認を依頼してください。機器に含まれるPHPについては、メーカーの更新情報を確認してください。内部システムも点検しつつ、インターネット公開サーバーから対処してください。

## PHPの修正版とサポート終了の基準

PHPの公式告知に記載された8.5系の修正版は、**8.5.12**です。KISAの原文でも同じバージョンを案内しています。8.5.13を待たなければパッチを適用できないという意味ではありません。

| 使用系列 | 2つの脆弱性の修正版 | 対応基準 |
| --- | --- | --- |
| PHP 8.5 | 8.5.13以上 | 該当系列の最新セキュリティリリースを確認 |
| PHP 8.4 | 8.4.27以上 | 該当系列の最新セキュリティリリースを確認 |
| PHP 8.3 | 8.3.36以上 | 該当系列の最新セキュリティリリースを確認 |
| PHP 8.2 | 8.2.35以上 | パッチ適用と併せて上位系列への移行を準備 |
| PHP 8.1以下 | 通常のセキュリティサポートが終了 | サポート対象系列への移行またはベンダーのパッチを確認 |

表は、2026年10月21日に発表された修正版を基準にしています。ディストリビューションのパッケージでは、表示バージョンが変わらない場合があります。この場合は、変更履歴で2つのCVEが修正されているか確認してください。[PHPのセキュリティリリース告知](https://www.php.net/archive/2026.php)

PHP 8.2のセキュリティサポート終了日は、2026年12月31日です。KISAは、PHP 8.3以上への移行を推奨しています。移行前にアプリケーションの互換性をテストしてください。[PHPのサポートスケジュール](https://www.php.net/supported-versions.php)

PHP 8.1以下は、通常のセキュリティサポートが終了しています。ディストリビューションや長期サポート業者のパッチは、別途確認する必要があります。今回公開された旧バージョン向けのソースパッチも、通常のサポート再開を意味するものではありません。

## 更新と再起動の方法

インストールファイルを置き換えた後は、PHP実行サービスの再起動が必要です。既存のプロセスが、メモリに残ったコードを実行し続ける可能性があります。侵害が疑われる場合は、以下の作業より先に証拠保全を進めてください。

1. パッチが既存の機能に与える影響を検討してください。
2. テスト環境でサービスの互換性を確認してください。
3. インターネット公開サーバーから修正パッケージを適用してください。
4. PHPを実行するすべてのサービスを再起動してください。
5. コンテナ環境では、修正済みのイメージで再デプロイしてください。
6. 実際のWebリクエストを処理するPHPに修正が反映されているか確認してください。

再起動の対象には、PHP-FPMとApache mod_phpが含まれます。php-cgi、FrankenPHP、LiteSpeedも確認してください。サーバーに複数のPHP環境がある場合は、それぞれ点検する必要があります。

`php -v`は、コマンドラインで実行されるPHPのバージョンを表示します。Webサービスが使用するPHPとは異なる場合があります。コマンドラインの出力だけで更新完了と判断しないでください。

## 更新前の暫定設定の基準

暫定措置は、一部の攻撃経路を減らす手段です。脆弱性全体を解消するものではありません。設定の適用が難しい場合は、外部接続の遮断を検討してください。

### memory_limitの設定はどのように適用しますか？

今回の脆弱性に対する公式の暫定推奨設定は、`memory_limit=-1`です。この値は、PHP自体のメモリ使用量の上限を解除します。通常の運用設定として受け取らないでください。

上限を解除すると、メモリ不足を引き起こす特定の経路が減ります。実際のメモリ割り当ての失敗まで防ぐ設定ではありません。リクエストサイズの制限とリソース管理対策を併せて検討する必要があります。[PHPのメモリ不足に関する脆弱性の勧告](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

| 項目 | 公式の暫定措置 | 適用時の確認事項 |
| --- | --- | --- |
| `memory_limit` | `-1`を指定 | アプリケーションが変更できないよう管理者設定を適用 |
| `session.upload_progress.enabled` | `0`を指定 | リクエスト処理前に適用される設定箇所を使用 |
| `post_max_size` | アップロードが不要な場合は`8M`が例 | 実際のサービス要件と前段の制限を併せて検討 |
| `upload_max_filesize` | `post_max_size`より小さく指定 | ファイルアップロード機能への影響を確認 |
| `fatal_error_backtraces` | PHP 8.5で`0`を指定 | 他の系列には一括適用しないこと |

表の設定値は、2026年10月の公式対応告知に基づいています。`8M`は、アップロードが不要なサービス向けに示された例です。すべてのサービスに同じサイズを適用する基準ではありません。

1. Webアプリケーションファイアウォール・Webサーバー・プロキシでリクエストサイズを制限してください。
2. サイズ情報がないリクエストにも制限が適用されるか確認してください。
3. アップロードが不要な場合は、multipartリクエストを前段で遮断してください。
4. Webアプリケーションファイアウォールの最新の遮断ルールを確認してください。
5. `php.ini`やPHP-FPM poolなどで設定を適用してください。
6. 証拠保全が必要か確認したうえで、PHPプロセスを再起動してください。

`ini_set()`だけで暫定設定を適用しないでください。リクエスト処理前に必要な設定の適用が遅れる可能性があります。PHP-FPMの`.user.ini`にも、同じ役割を期待しないでください。[PHPの公式暫定措置](https://www.php.net/archive/2026.php)

### 10月23日の追加告知で確認する内容

PHPは追加告知で、アップロード進捗機能を無効にするよう推奨しました。一部の設定の組み合わせに残る、別の実行経路についての案内です。すでに機能を無効にしている場合は、次回の定期修正リリースまで維持するよう案内しています。

該当する条件には、実行中のセッションのシリアライズ方式の変更が含まれます。すべてのPHP環境で同じ条件が成立するわけではありません。パッチ適用後に設定を戻すかどうかは、追加告知を確認して決めてください。（確認値 session.upload_progress.enabled=0を次回の定期バグ修正リリースまで維持するよう推奨 · 出典 php.net · 2026-10-23確認）[PHP Session upload progressの追加告知](https://www.php.net/archive/2026.php)

## ログの点検と認証情報の変更方法

KISAは、少なくとも**2026年10月20日以降**の記録を点検するよう推奨しています。可能であれば、それ以前の記録も確認してください。パッチを適用しても、すでに発生した侵害や情報流出を元に戻すことはできません。

| 点検対象 | 確認する痕跡 |
| --- | --- |
| Webサーバーログ | 繰り返し発生するHTTP 500エラー |
| PHPの実行記録 | 異常終了とsegfault |
| Web・アップロード・一時フォルダー | 新規作成または変更されたPHPファイル |
| プロセスの実行記録 | Webサーバーによるsh・bash・ダウンロードツールの実行 |
| ネットワーク接続 | 見慣れない外部アドレスへの新規接続の痕跡 |
| Webサイト・管理ページ | 密かに追加された外部スクリプト |

エラーがあるという事実だけでは、侵害を断定できません。逆に、異常な記録がないからといって、安全を断定することもできません。KISAは次のように案内しています。

> 記録上の異常がなくても安全は保証されないため、更新と認証情報の変更を併せて進めてください。
>
> KISA「PHPのセキュリティ脆弱性(PHP2Shell)に関する企業向けセキュリティ対応指針」

パッチ適用前にインターネットに公開されていたサーバーでは、認証情報の変更が推奨されます。侵害の痕跡が見つかったサーバーでは、必ず変更してください。対象には、DBパスワードと管理者パスワードが含まれます。APIキーとアクセストークンも、漏えいの可能性を点検してください。

個人情報DBに接続するサービスでは、DBの記録も確認してください。大量照会や持ち出しの痕跡を点検する必要があります。phpMyAdminへのインターネットからの直接アクセスも制限してください。Webサービス用アカウントのDB権限は、必要な範囲に絞ってください。[개인정보보호위원회の予防措置の案内](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## 侵害が疑われる場合の対応順序

侵害が疑われる場合は、サーバーの電源を切ったり、すぐに再起動したりしないでください。再起動によって、メモリに残る攻撃の痕跡が消える可能性があります。ネットワークから隔離した後、証拠の確保を進めてください。

1. サーバーの外部接続をネットワークで遮断してください。
2. 韓国国内の企業は、보호나라の侵害インシデント通報メニューから通報してください。
3. ログと実行中のプログラム一覧を保全してください。
4. 現在のネットワーク接続情報も保全してください。
5. 証拠を確保した後、更新と再起動を進めてください。
6. Webシェルの除去と認証情報の変更を進めてください。

韓国国内の相談窓口は、KISA 118です。通報メニューは、보호나라 > 侵害インシデントの通報 > 通報する、です。海外で運用している場合は、その地域の通報窓口を確認してください。

## よくある誤りの比較

パッチの適用状況は、実行状態と変更履歴まで確認する必要があります。インストール完了メッセージだけでは、確認は終わりません。次の判断をチェックリストに入れておいてください。

| よくある判断 | 確認すべき内容 |
| --- | --- |
| `php -v`が変われば完了 | Webサービスが実際に使用するPHPを確認 |
| パッケージをインストールすれば完了 | PHP実行サービスの再起動を確認 |
| バージョン番号が変わらなければ未対応 | ディストリビューションの変更履歴でCVEの修正状況を確認 |
| Webアプリケーションファイアウォールがあればパッチを省略可能 | 最新ルールの確認とPHPの更新を並行して実施 |
| ログに異常がなければ流出なし | 認証情報が漏えいした可能性まで検討 |
| 外注サイトは業者が対応してくれる | サービスごとの適用を示す根拠を依頼 |

インターネットで見つけた検証コードを、本番サーバーで実行しないでください。KISAは、マルウェアを含む偽のPoCについて警告しています。PoCは、脆弱性を悪用できることを示す検証コードです。脆弱性の影響を受けるかどうかは、まずバージョンとパッチ履歴から確認してください。

## 外注・ホスティング環境の対応完了確認表

対応完了報告には、サービスごとに確認の根拠を残すとよいです。以下の表は、KISAの対応指針を業務上の確認項目としてまとめたものです。別途定められた公式の提出様式ではありません。

| 確認項目 | 業者や担当者に依頼する内容 |
| --- | --- |
| 対象の漏れの有無 | Webサイト・管理ページ・テストサーバーの点検一覧 |
| 脆弱性の修正 | 適用バージョン、または2つのCVEが記載されたパッケージの変更履歴 |
| 実行状態 | サービスの再起動またはコンテナの再デプロイ記録 |
| 実際の反映 | Webサービスで確認したPHPの実行環境 |
| 侵害の点検 | 点検したログの期間と発見事項 |
| 認証情報 | 変更対象と完了状況 |
| 残作業 | 暫定措置のみ適用されたサーバーと今後のパッチ適用計画 |

例えば、業者からパッケージのインストール完了だけが報告されたとします。この場合は、再起動とWeb実行環境の確認結果を依頼してください。ログの点検と認証情報の変更は、別項目として確認すればよいです。

## FAQ

### PHP2Shellはログインパスワードを変更すれば防げますか？
ログインなしで悪用される可能性があるため、パスワードの変更だけでは解決しません。PHPのセキュリティアップデートが必要です。認証情報の変更は、漏えいの可能性に対応するための別の措置です。

### PHP 8.5は8.5.13まで待つ必要がありますか？
PHPとKISAの原文では、2つの脆弱性の修正版を8.5.13と案内しています。8.5.13を待つ必要があるという意味ではありません。適用時には、その系列の最新の公式リリースも確認してください。

### PHP-FPMを使っていれば点検しなくてもよいですか？
PHP-FPMも点検対象です。実行方式によって攻撃条件は変わる可能性があります。環境の名前だけで安全かどうかを判断しないでください。

### php -vの結果が修正版なら、対応は完了したということですか？
コマンドラインのPHPとWebサービスのPHPは異なる場合があります。実際にWebリクエストを処理する環境を確認してください。稼働中のサービスが再起動されたかどうかも確認する必要があります。

### パッチ適用後もバージョン番号が変わらなければ、失敗したということですか？
ディストリビューションやメーカーのパッケージでは、既存のバージョンに修正が反映される場合があります。パッケージの変更履歴で、2つのCVEへの対応が反映されているか確認してください。

### memory_limit=-1は今回の対応で禁止される設定ですか？
今回の脆弱性に対する公式の暫定的な推奨事項には、この設定が含まれています。一般的な運用上の推奨事項とは区別する必要があります。リクエスト制限とリソース管理の対策も併せて検討してください。

### ファイルアップロードがないサイトも対象ですか？
アップロード機能がないという理由だけで対象から除外することはできません。PHP自体の脆弱性なので、使用しているバージョンとパッチの適用状況を確認してください。不要なmultipartリクエストの遮断は暫定措置です。

### PHP 8.1以下にベンダーのパッチがあれば、使い続けてもよいですか？
ベンダーのパッチは、通常サポートの終了とは別に確認する必要があります。そのパッチを暫定的に適用する場合でも、サポート対象バージョンへの移行計画を立ててください。

### ログに異常がなければ、認証情報はそのままでもよいですか？
ログだけで情報漏えいがなかったと判断することはできません。KISAは、パッチ適用前にインターネットに公開されていたサーバーの認証情報の変更を推奨しています。侵害の痕跡があれば、必ず変更してください。

### 侵害が疑われる場合、先にアップデートすべきですか？
まずネットワークから隔離してください。通報と証拠の確保を済ませてからアップデートしてください。再起動すると、メモリに残っている攻撃の痕跡が消える可能性があります。

### ホスティング利用者は何を確認すべきですか？
事業者に、サービスごとのパッチ適用の根拠を求めてください。再起動と実際のWeb実行環境の確認結果も求めてください。ログの点検と認証情報の変更の有無は、別途確認してください。

### パッチ適用後、アップロード進捗の設定を再び有効にしてもよいですか？
PHPの2026年10月23日の追加告知を確認してください。一部の設定の組み合わせに追加の問題があるため、機能を無効のままにしておくことが推奨されています。設定を元に戻すかどうかは、その後の修正内容を確認してから判断してください。

## Sources

- [KISA 보호나라: PHPのセキュリティ脆弱性（PHP2Shell）に関する企業向けセキュリティ対応指針、2026年10月22日](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230)
- [PHP 2026年のお知らせ: 10月21日のセキュリティアップデートと10月23日のSession upload progressに関する追加案内](https://www.php.net/archive/2026.php)
- [PHPのセキュリティ勧告: RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
- [PHPのセキュリティ勧告: RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [PHP Supported Versions: 公式サポート期間](https://www.php.net/supported-versions.php)
- [PHP2Shell: 研究チームによる脆弱性の説明と影響範囲](https://www.php2shell.com/)
- [개인정보보호위원회: PHPのセキュリティ脆弱性に関する個人情報漏えい防止措置の呼びかけ、2026年10月22日](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## Images

![サーバールームで、女性がラックサーバーのネットワークポートの前に青いLANケーブルのコネクターを持っている。](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp)
![工場で、開いたネットワーク機器盤の横にあるタブレットの状態画面を確認する年配の技術者](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp)