>
>
公開日
最終更新日
PHPの脆弱性への対応を担う情シス・管理者向けに、PHP2Shellの修正版と自社への影響確認、停止判断、侵害調査、更新できないシステムの扱いを整理します。経営が決める業務停止と予算、担当者の分担まで、今週の対応を継続的な運用につなげる判断材料を示します。情報は2026年10月22日時点です。
PHPの脆弱性とは
PHP2Shellは、2026年10月21日にPHPの開発元が修正版を公開した、PHPの重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）の呼び名です。対応では、公式情報から分かる事実と、停止・予算・担当者のように社内で決める事項を分けて進めます。
本記事のポイント
最初の24時間：IPAが示す修正版(8.5.12・8.4.27・8.3.36・8.2.35)と自社の利用版を、外部から到達できるシステムから照合します。製品・機器やSaaSも対象に含め、利用版が不明なものには調査担当と回答期限を付けます。
今週中：経営が停止可否を承認します。停止できない対象には、暫定対策・監視の担当者と更新期限を付けます。
更新後：更新完了日と侵害調査の結果を別欄に記録します。材料不足の範囲は未確認のまま残します。
対象は、情報システム部門の担当者・管理者と、システム停止や予算を判断する経営層です。PHPの脆弱性への対応では、修正作業の実施だけでなく、業務を止められるか、誰が対応を引き受けるかも判断します。PHPのセキュリティ対策を技術担当者だけの課題にせず、公式情報から分かる修正版と、自社で決める対応範囲・責任分担を整理します。
この記事で扱う情報
情報の基準日は2026年10月22日時点です。以下は、IPAの対策情報と事前準備情報に記載された内容を整理したものです。
IPAの2026年10月22日付のPHPの脆弱性対策情報は、PHP2Shellと呼ばれるCVE-2026-109618、CVE-2026-109619について、遠隔の第三者が任意のコードを実行する可能性を説明しています。任意コード実行とは、攻撃者が意図したプログラムを動かせる可能性を指します。同情報が示す修正版は、次の4系列です。表にない系列を使っている場合は対象外と決めつけず、後述のとおりPHP公式サイトのSupported Versionsで状況を確認し、修正が提供されていなければ移行計画へ進みます。
影響を受ける構成について、PHPの開発元はセキュリティアドバイザリで、Webのリクエストを処理するすべてのPHP（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeed）を挙げています。中でもmod_phpは、アプリケーションのコードが動く前に、認証なしのリクエストで攻撃が成立する実証があるとして、最もリスクが高いとしています。更新以外の緩和策は特定の攻撃経路を減らすだけで、更新だけが完全な対策だとも明記しています。JPCERT/CCの注意喚起（2026年10月22日）も、国内で広く使われていることを確認したとして、修正の適用と侵害有無の調査を速やかに行うよう求めています。
系列 | 修正版 | 自社環境の照合欄 |
|---|---|---|
8.5系 | 8.5.12 | 対象システム名・利用版・更新状況を記入 |
8.4系 | 8.4.27 | 対象システム名・利用版・更新状況を記入 |
8.3系 | 8.3.36 | 対象システム名・利用版・更新状況を記入 |
8.2系 | 8.2.35 | 対象システム名・利用版・更新状況を記入 |
一方、IPAのPHPの脆弱性対策に向けた事前準備情報は、The PHP Groupによる公開予定を2026年10月21日23時、日本時間として紹介しています。ただし公開予定の時刻であり、10月22日付対策情報の修正版とは別の情報として扱います。
対応会議では、情シスが表に利用版と更新状況を記入できるなら、更新作業の検討に進みます。利用版が分からない場合は「対象外」とせず、調査担当と回答期限を決めます。サーバー上では php -v や、OSのパッケージ管理ツールで版を調べられます。phpinfo() を表示するファイルを置いて確かめる方法もありますが、外部から見える場所に置くとそれ自体がサーバーの情報を公開することになるため、確認が済んだらすぐに削除します。ただしOS配布のパッケージは版番号が修正版より小さくても修正が取り込まれている場合があるため、その場合は配布元のセキュリティ情報と突き合わせて判定します。照合は、外部から到達できるシステムから先に進めます。照合欄は、自社開発システムだけでなく、利用製品やSaaSについて提供元から得た回答の整理にも使います。
経営側は、業務停止が必要な場合に停止時間と費用を判断します。停止できない場合は、暫定対応と監視の担当者・見直し期限を決めます。ただし、更新完了だけを理由に「侵害なし」と判断しない運用にします。更新状況と侵害確認の状況を別欄で管理すれば、修正済みでも調査が残っている対象を区別できます。次に、照合の前提となるPHP利用状況を整理します。
自社システム・製品・SaaSのPHP利用状況
確認先は3つです。自社システム、製品・機器の内部、利用中のSaaSをそれぞれ洗い出します。製品・機器とSaaSは、すべてを個別に調べ尽くす前提にせず、提供元の発表やマニュアルで影響が分かるものから整理し、分からないものは「未確認」として管理表に残す運用案です。
調査対象を自社管理のサーバーだけに限定せず、利用状況の根拠、管理権限、対応主体をひも付けます。PHPの脆弱性への対応では、「使っていない」と「利用の有無が分からない」を分ける運用にすると、調査漏れを残さず次の判断につなげられます。
自社システムの確認対象
自社システムは、管理資料と構築・保守担当への照会を基に、PHPの利用有無、バージョン、管理者、業務への影響を整理します。
管理資料がある場合は記載内容と確認日を残し、情報が古い、または記載がない場合は構築・保守担当に照会する運用にします。管理者欄には、社内の責任者と実際に変更作業を行う担当を区別して記録すると、依頼先が明確になります。
利用が判明した環境は、業務への影響と管理権限を整理して停止・更新判断へ進めます。不明な環境は対象外にせず、調査担当と回答期限を設定します。資料にPHPの記載がないことだけを理由に「利用なし」と扱うのは避けます。
製品・機器の確認対象
製品・機器は、内部のPHP利用を外見や製品分類から断定せず、製品提供元の発表を基に影響の有無を整理します。
提供元が影響ありと発表した場合は、自社の製品名や型番、バージョンが対象範囲に含まれるかを照合し、該当すれば提供元の対策に沿った実施計画へ進めます。自社で作業するのか、保守担当に依頼するのかも計画に記入します。
発表に情報がない場合は「影響なし」ではなく「未確認」として残します。問い合わせ窓口への照会担当、回答期限、発表を再確認する期限を決め、回答待ちの間も管理対象に含めます。内部構成が分からない段階で、独自にPHPを更新する計画は立てません。
SaaSの確認対象
SaaSは、提供元の発表で影響と対応状況を確認し、利用企業側に必要な対応を切り分ける対象です。
利用企業が基盤のPHPを直接更新できる前提では扱いません。提供元が対応済みと発表していれば、対象サービスや機能などの範囲を自社の利用範囲と照合し、自社側の追加対応の有無を記録します。追加対応が示されている場合は、その実施担当と期限を設定します。
発表がなければ「未確認」と記録し、照会日と再確認日を管理します。管理表では、提供元の対策状況と社内の確認状況を別欄にし、「問い合わせ済み」を「対策済み」と誤認しないようにします。
対応管理表の空欄と記入方針を以下に示します。空欄行を対象ごとに複製し、下段の方針に沿って記入します。実在する企業や対応実績を示すものではありません。
対象 | 区分 | 管理主体 | 利用状況の根拠 | 影響確認の状態 | 次の判断 | 担当 | 期限 |
|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
システム名、製品名、サービス名を記入します | 自社システム、製品・機器、SaaSから記入します | 変更権限を持つ社内担当・保守担当・提供元を記入します | 資料名、回答元、発表内容と確認日を残します | 影響あり・なし・未確認を根拠に沿って記入します | 停止・更新判断、対策計画、照会継続などを記入します | 次の判断まで進める社内担当を記入します | 回答・再確認・実施の期限を分けて記入します |
この表で対応主体と未確認事項が整理できた対象から、停止可否と更新作業の責任分担の判断へ進めます。
停止可否に応じた対応判断と責任分担
停止できる場合は停止と更新の計画を決め、停止できない場合は暫定対策・監視・更新期限に担当を付けます。
PHPの脆弱性が見つかった際は、一律に停止・継続を決めず、対象業務、外部公開の状況、停止による影響、代替運用の有無を判断材料にします。代替運用で業務を維持できるなら停止計画へ進み、停止による影響が大きいなら、継続に伴う負担と残存リスクを経営の承認事項に含めます。
経営は停止・継続と残存リスクの受容を承認し、情シスは技術調査、対策の実施、監視、更新計画を担う分担案です。業務責任者は、停止の影響と代替運用の成立条件を整理します。技術部門だけに、売上や顧客対応への影響を含む判断まで背負わせない構成にします。
区分 | 判断者 | 直近の行動 | 再判断の条件 | 期限 |
|---|---|---|---|---|
停止可能 | 業務責任者が影響を整理し、経営が承認 | 情シスが停止・更新・復旧確認の計画を作成 | 代替運用が成立しない、更新作業で問題が発生 | 停止前に作業日時と復旧判断時点を確定 |
停止困難 | 経営が継続条件と残存リスクを承認 | 情シスが公式対策の適用可否と監視体制を整理 | 異常の検知、対策の適用不可、監視体制の欠員 | 継続承認前に次回判断日時と更新期限を確定 |
影響未確認 | 経営が指名する暫定運用責任者 | 情シスが追加調査し、責任者が暫定的な運用を判断 | 影響範囲が判明、または調査期限までに未解明 | 調査着手時に報告日時を設定し、その時点で再判断 |
対象かどうかを確定できなければ、調査担当と暫定運用の責任者を分けて指名し、未解明の事項を残したまま継続するか、停止するかを承認記録に残します。表の期限は運用上の設定案であり、安全を保証する猶予期間ではありません。
IPAの対策情報と本記事の判断表の位置づけ
IPAは、PHPの脆弱性に関する対策情報で、修正バージョンとしてPHP 8.2.35、8.3.36、8.4.27、8.5.12を案内しています。本節の判断表や対応フェーズ表は自社運用向けの案であり、IPAが示す手順ではありません。
停止困難時の運用体制
停止せずに業務を続ける場合は、暫定対策と監視を別々に依頼せず、異常時の停止判断まで一体で定めます。
運用票には「暫定対策の実施担当者名／監視担当者名／異常時の連絡先／業務停止の判断者／次回判断日時／更新期限」を記入します。担当が不在になる時間帯があれば、交代担当を置けるかを継続承認の条件にします。設定変更を採用する場合は、対象環境への適用条件を確認できた公式対策に限定し、根拠のない防御効果は見込みません。
暫定対応の失敗パターン
暫定対応を続ける場合は、業務継続の利点だけでなく、監視負担・残存リスク・再判断の負担も承認対象にします。
避けたいのは、暫定対策を恒久対策として扱うこと、監視を担当者名なしで依頼すること、期限を決めず更新を先送りすることです。暫定対策は特定の攻撃経路への露出を減らすにとどまり、更新するまで脆弱性そのものは残ります。今週の対応は、次のフェーズ表に担当者名と具体的な日時を追記して運用します。
時点 | 対応と担当 | 次の判断 |
|---|---|---|
初動 | 業務責任者が停止影響を整理し、情シスが技術条件を調査 | 経営が停止・条件付き継続を承認 |
継続承認前 | 情シスが暫定対策・監視・連絡体制を確定 | 担当や対策が成立しなければ停止可否を再審議 |
今週中の指定日時 | 情シスが調査結果、監視状況、更新見通しを報告 | 経営が継続条件を見直し、更新期限を再確認 |
この判断記録を基に、更新まで運用を支える時間・予算・交代要員を具体化します。
▲ システムの停止可否に応じた対応ルートと役割分担の判断フロー
更新対応と切り分けた侵害の有無の確認
更新と侵害調査は別管理にします。管理表では、更新完了日と侵害調査の結果を別欄に記録してください。修正版を適用しても、更新前の侵害有無は別途確認が必要です。
痕跡が見つからないことだけでは、安全とは判断できません。報告では、調べた範囲で異常を認めなかったのか、判断に使える記録が足りなかったのかを区別します。調査の終了可否は、更新作業の担当者による完了報告とは切り離し、調査範囲と残る不明点を踏まえて判断者が決定する形にします。
何を確認するかについては、JPCERT/CCの注意喚起が、脆弱性の発見者が推奨する次の観点を紹介しています。
過去のHTTPレスポンスで、不自然に長い、または異常な形式の値を含むPHPSESSID Cookieが設定されていないか
不審なmultipart/form-data形式のリクエストが送られていないか。その前後に、PHPのメモリ上限に関するエラーやHTTP 500エラーが出ていないか
PHPのワーカープロセスが予期せず異常終了したり、頻繁に再起動したりした痕跡がないか
JPCERT/CCは、悪用の経路が複数あるため1つの検知ルールですべての攻撃を検出できるとは限らず、記録の状況によっては痕跡が残らない場合もあるとしています。不審なプロセスの実行や外部通信、不審なファイルの作成など、ほかの痕跡もあわせて確認します。侵害が疑われる場合は、ログなどの証拠を保全したうえで、影響範囲の調査やシステムの隔離を行います。
以下は、調査結果を混同せず報告するための運用提案です。
調査範囲と判断を残す報告様式
調査を依頼する場合は、結論だけでなく、その結論を支える範囲と記録を同じ報告に残します。報告書には、次の項目を設けると判断の前提を共有できます。
調査対象：対象システムと、調査から除外した範囲を記載します。
調査した期間：調査対象とした過去の期間と、調査の実施期間を分けて記載します。
使用できた記録：取得元と、記録が残っていた期間を記載します。
記録の不足：取得できなかった記録、その理由、判断への影響を記載します。
判断者：結果を判断した人と、追加対応・調査終了を決めた理由を記載します。
記録を取得できるなら、調査対象として保全してから確認に用います。取得できないなら、その範囲を未確認として報告し、代わりの記録を取得できるか、調査範囲を広げるかを判断します。不足を埋められない場合も、未確認の範囲を消さずに残します。
報告上の状態 | 次の判断・対応 |
|---|---|
異常あり | 対応責任者へ連絡し、該当サーバーの再起動やログの削除・ローテーションを控えて証跡を保全します。そのうえで、当該サーバーからの外部接続の制限、サーバー上に置いていたパスワードやAPIキーなどの秘密情報の変更を進めます。EDRの検知履歴、Webサーバーのアクセスログ、公開領域に置かれた見覚えのないファイル、定期実行の設定を調べ、不審な点が見つかれば追加調査の範囲を広げます。 |
確認範囲内で異常なし | 対象・期間・記録の限界を添え、調査終了の可否を判断します。 |
材料不足 | 不足の解消方法を検討し、調査の継続や追加対応を判断します。 |
侵害確認の失敗パターン
避けたい失敗は、更新完了を侵害なしの根拠にすることと、記録不足を異常なしとして報告することです。「修正版を適用したため問題なし」では、過去の状況を何で判断したのかが伝わりません。
報告する際は、「更新は完了、侵害調査は材料不足」のように状態を分けます。確認範囲内で異常なしの場合も、調査対象外まで安全と表現せず、残る不明点と次の対応を引き継ぐ形にします。
▲ 脆弱性への「更新対応」と「侵害調査」を分離して進める並行管理構造
更新できない古いシステムの作り直し・廃止・置き換え
更新できないシステムは、作り直す・廃止する・SaaSに置き換えるの3つから選びます。比べる軸は、その業務を残す必要があるかどうかです。
まず、使っている系列のサポート状況をPHP公式サイトの「Supported Versions」で確かめます。PHP 8.1以前はサポートが終わっています。今回は深刻さを考慮して、開発元が7.4・8.0・8.1向けに最小限の修正（ソースコードへのバックポート）を出しました（PHP公式のアドバイザリ）。自分でソースからビルドしている環境などに向けた措置で、サポートの再開ではありません。OSやディストリビューションの提供元が修正を配布しているかもあわせて確認し、どちらもなければ移行を前提に計画を立てます。有償の延長サポートを使う場合は、今回の脆弱性が対象に含まれるかを提供元に確かめてからにします。
更新できない理由も、保守担当や委託先と一緒に切り分けておきます。改修箇所を特定できないのか、連携先との互換性を検証できないのか、停止時間が取れないのか。どれに当たるかで打ち手が変わります。検証環境と改修の工数を確保できるなら、更新の案も残しておきます。
選択肢 | 向いている条件 | 決めておくこと | 承認する人 |
|---|---|---|---|
作り直し | 自社独自の業務を残す必要がある | 残す機能とデータ、新旧の処理結果を照合する方法、切り戻しの条件 | 業務責任者と情シスが要件を固め、予算決裁者が承認 |
廃止 | 業務そのものを終えられる | 保存するデータと削除するデータ、終了後の問い合わせ先と代替手順 | 業務責任者が終了を判断し、データ管理責任者が削除を承認 |
SaaSへの置き換え | 必要な要件を既製のサービスで満たせる | データ・権限・連携設定の移し方、障害時の連絡、データの返却・削除、脆弱性対応の責任範囲（契約） | 業務責任者・情シス・契約担当が条件を整理し、予算決裁者が承認 |
どれを選ぶにしても、「更新できない」を理由に対応を終わらせないことが前提です。今週決めるのは、恒久対応の責任者と、方針を決める期限の2つだけで足ります。移行が終わるまでは、暫定対策の内容と担当を記録し続けます。暫定対策を保てなくなったときや移行計画が遅れたときが、判断をやり直すタイミングです。
▲ 更新困難なシステムに対する恒久対策3案（作り直し・廃止・SaaS置き換え）の比較
今週の緊急対応を継続運用につなぐ時間・予算・交代要員
今回のような緊急対応は、一度で終わる前提で組まないほうが安全です。同じ種類の重大な脆弱性が年末にかけて続いても回せるよう、作業時間・予算・交代要員を先に確保しておきます。これは発生の予測ではなく、計画を立てるときの前提です。
情シスと経営の分担
情シスが受け持つのは、影響の整理、実施計画、進み具合の報告です。調査・更新・動作確認・監視にかかる時間を見積もって計画に入れ、通常業務と両立できなければ、後回しにする業務と追加で必要な支援を経営に示します。担当者の残業で埋める計画にはしません。
経営が決めるのは、停止による業務への影響、予算、ほかの業務との優先順位です。作業費だけでなく、検証・監視・引き継ぎに充てる時間も判断の対象に入ります。承認待ちの案件には判断者と回答期限を書き、情シスが期限のない案件を抱え込まないようにします。
時点 | やること | 決める人 |
|---|---|---|
対応開始時 | 対象・未確認事項・担当を一覧にする | 情シス責任者 |
今週中 | 作業時間と費用を見積もり、実施の枠と交代要員を確保する | 経営、情シス責任者 |
定期的に | 新しい脆弱性情報の確認、未確認案件と予算の見直し | 情シス責任者（予算と優先順位は経営） |
交代するときに引き継ぐこと
対象と未確認事項、それぞれの責任者
実施した対応と、記録の保管先
監視の担当と、異常時の連絡先
次に判断する日時と判断者
引き継ぎ先が見つからない作業は、情シス責任者が担当を割り振り直し、それでも足りなければ経営に上げます。更新が済んでいても、未確認事項が残る案件は完了扱いにしません。次の担当者がそのまま判断を再開できる状態が、緊急対応を通常の運用に移す条件です。
まとめ
明日の初動は、PHPの利用状況が未確認の対象と、その調査担当を明らかにすることです。対象を把握できたら、業務への影響を踏まえて停止可否を判断します。更新できた場合も、それだけで対応完了とせず、侵害の有無を別に確認します。更新できない対象が残るなら、作り直し・廃止・置き換えの判断につなげます。今週の対応で担当・判断理由・未完了事項を記録し、時間・予算・交代要員を確保する運用にすれば、PHP以外の脆弱性にも対応を引き継げます。
同じ週に対応が必要な重大な脆弱性は、関連記事「今週の重大な脆弱性まとめ」で把握できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
