脆弱性が見つかったときの対応手順：把握・影響判断・更新・確認・報告の進め方

重大な脆弱性への対応は、次の6つの手順で進めます。

手順	行うこと	主な判断材料
① 把握する	自社が何を、どのバージョンで使っているかを確認する	ソフトウェアの管理台帳
② 情報を集める	開発元・IPA・JPCERT/CCの発表を確認する	対象バージョン、修正版、悪用状況
③ 影響を判断する	自社が対象か、どれだけ急ぐかを決める	深刻度、外部公開の有無、悪用の有無
④ 更新する（できなければ暫定策）	修正版を適用する。難しければ緩和策・遮断を判断する	開発元の緩和策、業務への影響
⑤ 侵害の有無を確認する	修正前に攻撃されていなかったかを調べる	開発元・JPCERT/CCが示す痕跡
⑥ 報告・記録する	社内・関係先へ報告し、必要に応じて個人情報保護委員会へ報告する	漏えいの有無、報告期限

①〜③はIPAが示す「ソフトウェアの把握 → 脆弱性情報の収集 → 対策適用の判断」という流れ（IPA「脆弱性対策の効果的な進め方（ツール活用編）」）にもとづいています。④〜⑥は、2026年10月22日にIPAとJPCERT/CCが公表したPHPの脆弱性に関する注意喚起と、個人情報保護委員会のガイドラインをもとに当サイトで整理したものです。

以下、2026年10月21日に修正版が公開されたPHPの脆弱性「PHP2Shell」（CVE-2026-109618、CVE-2026-109619）を例に、手順ごとの進め方を説明します。脆弱性そのものの解説は関連記事「PHPの緊急レベルの脆弱性『PHP2Shell』の概要と、サイト運営者が行うべき対応」をご覧ください。

手順① 把握する：何を使っているかを平時から台帳にする

脆弱性の公表を知っても、自社がそのソフトウェアを使っているかどうかが分からなければ、対応を始められません。IPAは、利用しているソフトウェアの洗い出しを最初の段階に置き、「ソフトウェア脆弱性関連情報管理シート」（Excel）とその記載例を公開しています（IPA）。

台帳には、少なくとも次の項目を記録しておくことをおすすめします。

ソフトウェア名とバージョン（例：PHP 8.3.35）
動いている場所（どのサーバー、どのサービス）
インターネットから到達できるか
管理担当者と、更新を依頼する先（社内・委託先・サーバー会社）
サポート終了日

PHP2Shellで問題になった点：PHPは、WordPressなどのCMSだけでなく、ネットワーク機器の管理画面や業務パッケージの内部にも組み込まれています。IPAは今回、製品の内部でPHPが使われているかをマニュアルや開発元の情報で確認するよう求めました（IPA 2026年10月21日）。台帳に「製品名」しか記録していないと、内部のPHPの存在に気づけません。

手順② 情報を集める：一次情報を確認する

脆弱性の情報は、次の順で確認します。報道やSNSの情報は速い一方で、数値や対象範囲が誤っていることがあります。

開発元の発表（今回はPHP公式のセキュリティアドバイザリ）
国内の公的機関：IPAの「重要なセキュリティ情報」、JPCERT/CCの「注意喚起」、脆弱性データベースのJVN
海外の公的機関：米国CISAのアラート
利用中の製品の開発元・サーバー会社の告知

PHP2Shellで問題になった点：公開前に出回った情報では深刻度が「10.0」とされていましたが、PHP公式が示した値は9.2でした。一方で、公開日は情報の拡散を受けて当初予定の10月22日から21日に早まっています（PHP Foundationの説明。Tenable社の記事による引用）。IPAは事前告知の段階から「前倒しの可能性がある」と案内していました。予定日を待たず、事前告知の時点で準備を始めることが重要です。

手順③ 影響を判断する：対象かどうか、どれだけ急ぐか

集めた情報をもとに、次の3点で優先度を決めます。

観点	確認すること	PHP2Shellの場合
対象か	使っているバージョンが影響範囲に含まれるか	8.2.35未満〜8.5.12未満の全系列。8.1以前は修正版なし
深刻度	CVSSの値、認証の要否、遠隔から攻撃できるか	CVSS v4.0 9.2、認証不要、遠隔からのコード実行
緊急性	インターネットに公開しているか、悪用が確認されているか	CISAは公表時点で悪用を確認していない一方、Amazonは10月17日に攻撃の試みを観測（Tenable社による引用）

「認証不要」「遠隔からのコード実行」「インターネットに公開されたサーバーで動いている」の3つがそろう場合は、通常の更新計画とは切り分け、即日の対応を検討すべき水準です。CISAも、インターネットに面したシステムを優先して更新するよう求めています（CISA）。

悪用の有無は発表元によって異なることがあります。 今回は「悪用を確認していない」（CISA）と「21日以降、攻撃の試みが広く見られる」（Amazon）という発表が同じ日に並びました。判断が分かれる場合は、より厳しい側を前提に動くことをおすすめします。

手順④ 更新する：できなければ暫定策と遮断を判断する

修正版の適用が根本的な対策です。JPCERT/CCは、十分なテストを行ったうえで適用するよう案内しています（JPCERT/CC）。

すぐに更新できない場合について、IPAは次の順で検討するよう示しています（IPA 2026年10月22日）。

サポート状況の確認：サポートが終了した版には修正が提供されないため、サポート中の版や対策済みの製品への移行を検討する
暫定対策：利用環境に応じた暫定策やアクセス制限を行う。有効な暫定策がなければ、外部からのアクセス遮断やサービスの一時停止を判断する
システムの状況把握：役割や利用状況を確認し、ほかのシステムで代替できるかを検討する
組織としての実現性：事業責任者や経営層を含め、更新と維持管理に必要な人員・予算・保守体制を確保できるかを検討する
今後の方針：体制を確保できない場合は、保守を受けられる製品への移行、機能の縮小、公開の終了や廃止も含めて検討する
利用者への配慮：データの移行・保存や代替手段の案内を計画する

この6項目の4〜5番目は、担当者だけでは決められない内容です。「止める」判断を誰がするかを平時に決めておくことが、初動を早めるうえで最も効果があります。

暫定策の効果について：PHP2Shellでは、PHP公式がいくつかの設定変更（セッションのアップロード進捗機能の無効化など）を示しましたが、「完全な緩和策はなく、更新が唯一の安全な選択肢」と明記しています。JPCERT/CCも、緩和策は特定の攻撃経路にしか対処しないとしています。暫定策を入れた場合でも、更新の期限を決めて管理してください。

手順⑤ 侵害の有無を確認する：更新の前に攻撃されていなかったか

更新しても、それ以前に侵入されていれば被害は残ります。開発元やJPCERT/CCが示す痕跡をもとに、ログや稼働状況を確認します。

PHP2Shellで確認すべき痕跡（JPCERT/CCの注意喚起より）

不自然に長い、または異常な形式の PHPSESSID Cookie
不審な multipart/form-data のリクエストと、その前後のメモリ上限エラーや HTTP 500 エラー
PHPのワーカープロセスの予期しない異常終了や頻繁な再起動

調べる期間は、修正版の公開日ではなく、攻撃の試みが最初に観測された日から始めます。今回は、Amazonが10月17日以降を調査対象とするよう推奨しています（Tenable社による引用）。

痕跡が見つからないことは、安全の証明にはなりません。PHP公式とJPCERT/CCはいずれも、今回の攻撃では痕跡が残らない場合があるとしています。不審な点がある場合は、ログの保全を優先したうえで、JPCERT/CCのインシデント対応依頼（https://www.jpcert.or.jp/form/）や、保守委託先・セキュリティ事業者への相談を検討してください。

手順⑥ 報告・記録する：漏えいのおそれがあれば期限がある

侵害の結果、個人データの漏えい等が発生した、またはそのおそれがある場合、事業者には個人情報保護委員会への報告と本人への通知が義務づけられる場合があります。

報告の対象となる主な事態（民間事業者）

要配慮個人情報が含まれる漏えい等
クレジットカード番号など、財産的被害が生じるおそれがある漏えい等
不正アクセスなど、不正の目的をもって行われたおそれがある行為による漏えい等
本人の数が1,000人を超える漏えい等

いずれも「発生したおそれがある」段階で対象になります。脆弱性を突いた不正アクセスは3つ目に該当しうるため、件数が少なくても報告の要否を検討する必要があります。

報告の期限

種類	期限
速報	発覚後速やかに（目安は発覚日から3〜5日以内）
確報	発覚日から30日以内。不正の目的によるおそれがある場合は60日以内
本人への通知	当該事態の状況に応じて速やかに

出典：個人情報保護委員会「漏えい等の対応とお役立ち資料」、個人情報の保護に関する法律についてのガイドライン（通則編）3-5

同ガイドラインは、漏えい等が発覚した場合に講ずべき措置として、①事業者内部での報告と被害の拡大防止、②事実関係の調査と原因の究明、③影響範囲の特定、④再発防止策の検討と実施、⑤委員会への報告と本人への通知、を挙げています。手順⑤で集めたログや確認の記録は、②と③の根拠資料になります。

漏えいがなかった場合でも、「いつ公表を知り、いつ対象を特定し、いつ更新したか」を記録に残しておくことをおすすめします。次に同じ種類の脆弱性が出たとき、どの手順に時間がかかったかを振り返る材料になります。

平時に準備しておくこと

公表されてから準備を始めると、手順①と④で時間を失います。JPCERT/CCは2026年10月の注意喚起で、国内組織への不正アクセスが相次いでいることを受け、次のような平時の点検を求めています（JPCERT/CC 2026年10月8日公開・9日更新）。

既知の脆弱性がある版を、修正済みのバージョンに更新する
業務上不要な管理機能などのインターネット公開を停止する
不正アクセスの検知体制と初動対応を点検する
Webサーバー等が侵害された際に、ほかのシステムへ被害が広がらないかを見直す
保存期間を過ぎたデータや、利用目的を終えたデータを残さない
漏えい時を想定し、顧客への二次被害防止の呼びかけを平時から準備する

同じ注意喚起では、一般利用者向けのサービスだけでなく、BIツールや従業員向けの管理システムなど、不特定多数の利用を想定していないシステムからも情報が漏えいしていると指摘されています。「社内向けだから対象外」とせず、台帳には内部向けのシステムも含めてください。

準備状況の確認表

確認項目	対応する手順
ソフトウェアの台帳があり、バージョンまで記録している	①
製品の内部で使われているソフトウェア（PHP等）も把握している	①
IPA・JPCERT/CC・利用製品の開発元の発表を受け取る仕組みがある	②
「即日対応」とする基準を決めている	③
サービスの停止や公開の終了を判断する責任者を決めている	④
ログの保存期間が、調査に必要な期間を満たしている	⑤
個人情報保護委員会への報告の担当者と手順を決めている	⑥

よくある質問

Q. 開発や運用を外部に委託している場合も、自社で対応が必要ですか。 A. 更新作業は委託先が行う場合でも、手順③の「止めるかどうか」や手順⑥の報告は、サービスを提供する事業者自身の判断になります。委託先と、重大な脆弱性が出たときの連絡方法や対応期限を事前に取り決めておくことをおすすめします。

Q. 更新によってサイトが動かなくなるのが心配です。 A. JPCERT/CCも、十分なテストのうえで更新するよう案内しています。本番と同じ構成の検証環境があれば、そこで動作を確認してから本番に反映します。検証環境がなく、かつ深刻度と緊急性が高い場合は、手順④のとおり一時的な遮断と組み合わせて判断します。

Q. 脆弱性の情報はどこで受け取れますか。 A. IPAとJPCERT/CCはWebサイトで注意喚起を公開しており、JPCERT/CCはメーリングリストでも配信しています。利用中の製品については、開発元のセキュリティ情報の配信に登録しておくと確実です。

※本記事は2026年10月22日時点の公開情報にもとづく一般的な解説です。個別のシステムや事案への対応は、開発元・保守委託先・専門家にご相談ください。