>
>
公開日
最終更新日
PHPの重大な脆弱性「PHP2Shell」（CVE-2026-109618、CVE-2026-109619）は、修正版の公開から5日後に米国のCISAが悪用を確認し、KEV（悪用が確認された脆弱性のカタログ）に登録しました。国内でも、PHPを組み込んだファイアウォール製品が侵害された可能性をJPCERT/CCが報告しています。
外部から到達できるシステムは、当日中の更新が必要な段階です。修正版を適用した環境でも、PHPを組み込んだ機器の確認、追加で公表されたCVE-2026-115560への設定変更、更新前に侵害されていないかの調査は別に対応が必要です。本記事では、この「更新後も残る3つの対応」を中心に、一次情報をもとに手順を整理します。
本記事のポイント
修正版はPHP 8.5.12・8.4.27・8.3.36・8.2.35。アップデート以外に完全な対策はないと、PHPの開発元が明言しています
10月26日以降、悪用の観測・KEV追加・ファイアウォール製品の侵害報告が相次ぎ、「様子見」の段階は終わっています
自社サーバーだけでなく、管理画面にPHPを使うネットワーク機器やアプライアンスも対象です
10月23日公表のCVE-2026-115560は修正版を適用しても残るため、session.upload_progress.enabled=0 の設定を推奨されています
更新の完了と「侵害されていない」ことは別物です。更新前の期間について侵害調査を行います
PHP2Shellとは？2つの脆弱性と公表後の経緯
PHP2Shellは、PHP本体に見つかったリモートコード実行の脆弱性2件の呼び名で、認証なしで外部からサーバー上の任意のコードを動かされるおそれがあります。公表から2週間で、攻撃コードの公開、実際の悪用、機器の侵害と、状況は短期間で進みました。
PHPの開発元（The PHP Group）は2026年10月21日のセキュリティアドバイザリで、Webのリクエストを処理するすべてのPHPが影響を受けるとしています。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedが該当し、中でもmod_phpは、アプリケーションのコードが動く前に認証なしのリクエストで攻撃が成立する実証があるため、最もリスクが高いと位置づけられています。
CVE番号 | 内容（PHP公式の説明を要約） | 深刻度 |
|---|---|---|
CVE-2026-109618 | メモリ不足（OOM）のエラー処理で、初期化途中のリクエストデータが後片付けの処理で正しいものとして扱われ、任意コード実行に至る | CVSS v4.0で9.2 |
CVE-2026-109619 | 解放済みのメモリを指す内部状態が残り、同じワーカーが処理する次のリクエストでそれが使われて、任意コード実行に至る | CVSS v4.0で9.2 |
公表後の動きは次のとおりです。初版公開時（10月22日）から大きく変わったのは、「悪用の可能性」が「悪用の事実」になった点です。
日付 | 出来事 | 出典 |
|---|---|---|
10月20日 | PHP開発元が、翌日にセキュリティリリースを出すと予告 | PHP公式 |
10月21日 | 修正版（8.5.12・8.4.27・8.3.36・8.2.35）を公開。Palo Alto NetworksがPAN-OSへの影響を公表 | PHP公式、Palo Alto |
10月22日 | JPCERT/CCが注意喚起、IPAが対策情報を公開 | JPCERT/CC、IPA |
10月23日 | 特定の設定で起きる別の脆弱性 CVE-2026-115560 を公表 | PHP公式 |
10月26日 | JPCERT/CCが注意喚起を更新し、実証コードの多数公開と悪用を試みる通信の観測を追記。CISAが2件をKEVに追加（米国時間） | JPCERT/CC、CISA |
10月25〜29日 | Palo AltoがPAN-OSの修正版を系列ごとに順次公開 | Palo Alto |
10月28日 | CISAが（米国時間）、PHP2Shellと組み合わせて悪用されたLinuxカーネルの脆弱性 CVE-2026-46300 をKEVに追加 | CISA |
10月29日 | JPCERT/CCが、ファイアウォール製品の侵害を示唆する痕跡と、内部ネットワークへの横展開の試みを追記 | JPCERT/CC |
JPCERT/CCの注意喚起は、10月29日の更新で、エクスプロイト（攻撃コード）が製品のバージョンごとに作り込まれていた点に触れ、PHPを組み込んださまざまな製品を狙う攻撃がさらに広がる可能性があると警告しています。CISAは10月26日の告知で、KEVへの追加とともに、修正前に侵害されていないかを確認することの重要性にも触れました。
情シスとしては、「パッチを当てたか」だけを追うのではなく、どこにPHPがあるか、更新前に入り込まれていないかまでを一続きの対応として扱う必要があります。
影響を受けるバージョンと修正版
自社で使っているPHPの系列を確認し、下の表の修正版以上になっているかを確認します。8.1以前のサポート切れの系列は公式の修正版が出ないため、移行を前提に考えます。
系列 | 修正版 | 公式サポート |
|---|---|---|
8.5系 | 8.5.12 | サポート中 |
8.4系 | 8.4.27 | サポート中 |
8.3系 | 8.3.36 | サポート中 |
8.2系 | 8.2.35 | 2026年12月31日に終了 |
8.1以前 | 公式の修正版なし | 終了済み |
PHP開発元は、深刻さを考慮して7.4・8.0・8.1向けに最小限の修正をソースコードで提供しています。ただしこれは自分でビルドしている環境などへの措置で、サポートの再開ではありません。IPAの対策情報は、調査に関わったWiz社の見解として、PHP 5.4以降は少なくともどちらかの脆弱性の影響を受けると紹介しています。
注意したいのは、OSに付属するPHPです。Linuxディストリビューションや長期サポートの提供元には事前にパッチが渡されており、版番号が表の修正版より小さくても修正が取り込まれている場合があります。この場合はOSの提供元のセキュリティ情報で、該当パッケージが修正済みかを確かめます。
Windows版のPHPを使っている場合は、10月26日に再配布された8.5.12-1・8.4.27-1・8.3.36-1・8.2.35-1も確認対象です。PHP公式の告知によると、同梱の圧縮ライブラリBrotliの脆弱性（CVE-2026-111497）を修正したもので、PHP本体の版は変わりません。Brotliの脆弱性そのものは、Node.jsの脆弱性Node2Shellの解説で詳しく整理しています。
8.2系を使っている組織は、今回の更新で一段落ではありません。PHP公式は8.2.35のリリース告知で、12月31日以降は8.2系にセキュリティ修正を出さないと明記しています。年内に8.3系以降への移行計画を立てる必要があります。
修正版でも残るCVE-2026-115560
10月23日に公表されたCVE-2026-115560は、上の修正版を適用しても解消しません。この脆弱性は、セッション機能の設定とアプリケーションのコードが特定の組み合わせになったときだけ起きる脆弱性です。PHP公式の情報提供アドバイザリによると、設定で session.serialize_handler を php_binary か php_serialize にしておき、session_start() の前に ini_set() で php に切り替えるアプリケーションで、しかもアップロード進捗の機能（session upload progress）が有効なままの場合に限られます。
一般的な構成ではないため、PHPは緊急リリースを出さず、次の定期リリースで修正する方針です。それまでは session.upload_progress.enabled=0 を設定し、すべてのワーカーを再起動するよう推奨しています。この設定はCVE-2026-109619の緩和策（第4章の暫定対策）と同じなので、すでに入れている場合は追加の作業はありません。実行時にシリアライズ方式を切り替えないアプリケーションであれば、機能を有効のままにしてもよいとされています。
情シスがやることは、更新済みのサーバーについても session.upload_progress.enabled の値を確認し、0になっていなければ変更するか、アプリケーションの開発元・委託先に切り替えの有無を確認することです。設定を変えると、$_SESSION を使ったアップロード進捗の表示が動かなくなるため、該当機能があるシステムでは事前に動作を確かめます。
自社システム・製品・SaaSのPHP利用状況
PHPの所在は、自社で運用するサーバー、PHPを内部に組み込んだ機器・製品、利用中のSaaSの3つに分けて洗い出します。今回の侵害報告が示すとおり、「自社はPHPを使っていない」という認識の組織でも、ネットワーク機器の中にPHPが入っていることがあります。
自社サーバー・Webサイト
自社で管理するサーバーは、版番号と動作方式（mod_php、PHP-FPMなど）をセットで確認します。外部から到達できるもの、とくにApacheのmod_phpで動いているものが最優先です。
確認には、サーバー上で php -v を実行するか、dpkg -l | grep php（Debian・Ubuntu系）や rpm -qa | grep php（Red Hat系）でパッケージを調べます。このときの落とし穴が、コマンドラインで動くPHPとWebサーバーが使うPHPの違いです。同じサーバーに複数の版が入っていたり、コマンドライン用とPHP-FPM用で別の設定ファイルを読んでいたりするため、Webで実際に動いている版と設定を確かめます。phpinfo() を表示するファイルを置いて確かめる方法もありますが、外部から見える場所に置くとサーバーの情報を公開することになるので、確認後すぐに削除します。
WordPressなどのCMSは、CMS本体やプラグインを更新してもPHP本体は更新されません。レンタルサーバーやマネージドホスティングの場合は、提供元がPHPを更新したかを告知で確認し、PHPの版を利用者が選べるサービスなら、修正済みの版を選択しているかも見ておきます。
PHPを組み込んだ機器・製品
ファイアウォールやVPN機器、ストレージ、各種アプライアンスは、管理画面にPHPを使っていることがあります。外見や製品分類からは判断できないため、提供元の発表で影響の有無を確認します。
実例がPalo Alto Networksです。同社のセキュリティアドバイザリによると、影響を受けるのはPA-SeriesとVM-Seriesのファイアウォール、PanoramaのPAN-OSで、特別な設定がなくても対象になります。影響範囲は管理用のWebインターフェース（HTTPSのWeb UIとXML API）で、GlobalProtectのポータルやゲートウェイは対象外です。10月29日更新の時点では、インターネットに公開された管理インターフェースを狙う悪用を観測したとしています。
PAN-OSの系列 | 修正済みの版（いずれか以降） |
|---|---|
12.2 | 12.2.4-h1 |
12.1 | 12.1.4-h13、12.1.7-h11、12.1.10-h3 |
11.2 | 11.2.4-h23、11.2.7-h23、11.2.10-h16、11.2.13-h4、11.2.16-h1 |
11.1 | 11.1.4-h38、11.1.6-h40、11.1.7-h12、11.1.10-h36、11.1.13-h16、11.1.16-h4 |
10.2 | 10.2.7-h39、10.2.10-h42、10.2.13-h27、10.2.16-h12、10.2.18-h13 |
適用すべき版はマイナーバージョンごとに異なるため、実際の作業では同社の表で該当する版を確かめます。同社は、修正版が同じhotfixでBrotliの脆弱性にも対応していること（11.2.10-h16のみ例外で、11.2.10-h17が両方に対応）、CVE-2026-115560はPAN-OSに影響しないことも明らかにしています。
JPCERT/CCが10月29日に引用したDreamの報告は、PHP2ShellとLinuxカーネルの権限昇格の脆弱性（CVE-2026-46300）を組み合わせ、米国・日本・台湾・韓国にあるPalo Alto NetworksのPAN-OSファイアウォールと管理サーバー計25台でroot権限を取得した攻撃を報告しています。同社の脅威調査チームUnit 42も、インターネットに公開されたPAN-OSの管理画面への攻撃としてこの報告を取り上げています。同社製品に限らず、管理画面をインターネットに公開している機器は最優先で確認するのが今回の教訓です。
機器ごとの影響状況を一度に調べるには、オランダの国家サイバーセキュリティセンター（NCSC-NL）がGitHubで公開している製品一覧が役立ちます。JPCERT/CCも参考情報として紹介しており、ベンダーごとの「影響あり・修正済み・調査中」が随時更新されています。製品にどんな部品が含まれるかを日頃から把握する仕組みとしては、SBOM（ソフトウェア部品表）の考え方が参考になります。ネットワーク機器の更新計画の立て方は、FortiGateの脆弱性修正への対応も同じ流れで進められます。
SaaS・外部委託先
SaaSは利用企業がPHPを直接更新できないため、提供元の発表で対応状況を確認し、利用企業側に必要な作業があるかを切り分けます。発表がない場合は「影響なし」ではなく「未確認」として記録し、問い合わせ日と再確認日を決めます。
ここで手間取るのは、そもそも社内でどのSaaSを使っているかが一覧になっていないケースです。部門が独自に契約したサービスまで含めて把握できていないと、確認の対象から漏れます。SaaSの利用状況を自動で一覧化しておけば、こうした緊急時にも提供元への確認を短時間で回せます。マネーフォワード AdminaのSaaS可視化は、連携したSaaSのアカウントと利用状況を集約し、問い合わせ先の洗い出しにも使えます。
自社サイトや業務システムの運用を外部に委託している場合は、委託先に「PHPの版、更新の実施日、侵害調査の結果」の3点を文書で回答してもらいます。委託先への確認の進め方は、委託先管理のチェックリストで整理しています。
対応管理表の項目
自社システム・製品・SaaSで見つかった対象は、1つの管理表にまとめて追います。対象ごとに1行を作り、次の項目を埋めていきます。とくに「更新状況」と「侵害調査の結果」を別の欄にしておくと、修正版は適用したものの調査が終わっていない対象を見落としません。
管理表の項目 | 書く内容 |
|---|---|
対象 | システム名、製品名、サービス名 |
区分 | 自社システム、製品・機器、SaaSのいずれか |
管理主体 | 変更権限を持つ社内担当、保守担当、提供元 |
利用状況の根拠 | 資料名や回答元、提供元の発表内容と確認日 |
影響の有無 | 影響あり、影響なし、未確認（根拠に沿って記入） |
更新状況 | 未更新、暫定対策中、更新済み（更新日） |
侵害調査の結果 | 未着手、異常あり、確認した範囲で異常なし、判断材料が不足 |
次の判断 | 停止・更新の判断、照会の継続、恒久策の検討など |
担当と期限 | 次の判断まで進める社内担当と、回答・再確認・実施の期限 |
提供元に問い合わせただけの段階で「対策済み」と書かないことも大切です。提供元の対策状況と社内の確認状況は、別の事実として記録します。
停止可否に応じた対応判断と責任分担
更新の順番は、外部から到達できるかと、どの方式でPHPが動いているかで決めます。すぐに更新できない対象は、停止するか、暫定対策を入れて条件付きで続けるかを選びます。
対応の優先順位
悪用が始まっている以上、外部公開のシステムは「今週中」ではなく「今日中」の扱いです。
優先度 | 対象の例 | 対応 | 判断する人 |
|---|---|---|---|
最優先（当日中） | インターネットから到達できるPHPのWebサーバー（とくにApache＋mod_php）、管理画面を外部に公開している機器 | 修正版を適用。できなければアクセス制限や一時停止 | 適用は情シス。停止するかどうかは業務責任者と経営が承認 |
高（今週中） | 社内からのみ到達できる業務システム、委託先が運用する自社サイト、SaaSの提供元への確認 | 更新計画の確定と暫定対策、委託先・提供元からの回答の回収 | 情シス責任者。委託先の作業日程は業務責任者と調整 |
計画対応 | 8.1以前のサポート切れ系列、改修しないと更新できない古いシステム | 暫定対策を続けながら、移行・置き換え・廃止を判断 | 恒久策の方針と予算は経営が承認 |
※優先度・期限・判断者の分担は本記事の目安です。
影響があるかどうかを確定できない対象は、「対象外」にせず最優先か高の扱いに含めます。このとき、影響を調べる調査担当と、調査中の運用（継続か停止か）を決める暫定運用の責任者を分けて指名し、報告の日時を決めておきます。
CISAは、すぐに更新できない場合やサポート切れの版を使い続けている場合、PHPで動くシステムを更新まで停止するよう勧めています。IPAも、有効な暫定対策をとれないときは外部からのアクセス遮断やサービスの一時停止を判断するよう求めています。
停止は売上や顧客対応に響くため、情シスだけで決める話ではありません。情シスは影響範囲と停止しない場合のリスクを整理し、停止するか、条件付きで継続するかは業務責任者と経営が承認する、という分担にしておくと判断が速くなります。継続を選んだ場合は、暫定対策の内容、監視の担当者、次に判断し直す日時を承認の記録に残します。
▲ システムの停止可否に応じた対応ルートと役割分担の判断フロー
更新できない間の暫定対策
暫定対策は特定の攻撃経路を減らすだけで、PHPの開発元は「更新だけが完全な対策」と明言しています。PHP公式のアドバイザリが示す主な緩和策は次のとおりです。いずれも攻撃経路の一部を塞ぐだけで、サーバーを安全な状態にするものではないとされています。
対象 | 公式が示す緩和策 |
|---|---|
CVE-2026-109618 | memory_limit=-1 をアプリ側で上書きできない形（FPMのプール設定の php_admin_value など）で設定する。post_max_size を低く抑える（アップロード不要なら8M、必要でも32M） |
CVE-2026-109618 | コンテナやcgroupのメモリ上限で、影響を受けたワーカーだけを止める。RLIMIT_AS・RLIMIT_DATA は脆弱な処理を誘発するため代用しない |
CVE-2026-109619 | session.upload_progress.enabled=0 をphp.iniやFPMのプール設定で指定し、すべてのワーカーを再起動する。ini_set() や .user.ini は使わない |
CVE-2026-109619 | PHP 8.5では fatal_error_backtraces=0 を設定してワーカーを再起動する |
memory_limit=-1 はPHPのメモリ上限をなくす設定なので、それだけではサーバー全体のメモリを使い切るおそれがあります。公式がコンテナやcgroupの上限との併用を勧めているのはこのためです。
WAFについては、CISAが更新までのあいだ一定の防御になりうるとしていますが、更新の代わりにはなりません。悪用の経路が複数あり、攻撃手法も変化しているためです。暫定対策を入れた場合は、内容、実施日、担当者、更新の期限を記録し、「暫定対策を入れたので完了」と扱わないようにします。
侵害調査の進め方
修正版を適用しても、更新前に侵入されていたかどうかはわかりません。更新の完了日と侵害調査の結果は、第3章の対応管理表で別の欄に記録します。
JPCERT/CCは、脆弱性の発見者らの情報をもとに、次の点の確認を推奨しています。
過去のHTTPレスポンスで、不自然に長い、または異常な形式の値を含むPHPSESSID Cookieが設定されていないか
不審なmultipart/form-data形式のリクエストがないか。その前後に、PHPのメモリ上限に関するエラーやHTTP 500エラーが出ていないか
PHPのワーカープロセスが予期せず異常終了したり、頻繁に再起動したりしていないか
あわせて、不審なプロセスの実行、外部への通信、見覚えのないファイルの作成もほかの痕跡として確認します。CISAも、PHPのワーカープロセスがシェルを起動したり、ツールをダウンロードしたりする挙動の監視を呼びかけています。
今回の攻撃では、PHP2Shellで得た権限をLinuxカーネルの脆弱性（CVE-2026-46300）で管理者権限まで引き上げる手口が確認されています。CISAはKEVのCVE-2026-46300の項目で、両者を組み合わせるとWebシェルを設置してroot権限でコマンドを実行できると説明しています。PHPを更新したサーバーでも、カーネルの更新と再起動が済んでいるかを確かめます。機器が侵害されると、そこを足掛かりに社内ネットワークへ広がるおそれがあるため、ファイアウォールなどの機器ではログイン履歴や設定変更の履歴も確認対象に入れます。
痕跡が見つからないことだけでは、侵害されていないとは言えません。JPCERT/CCは、悪用経路が複数あるため1つの検知ルールですべての攻撃を検出できるとは限らず、ログの記録状況によっては痕跡が残らない場合もあるとしています。報告では、結果を次の3つに分けて書くと、判断者が状況を取り違えません。
報告上の状態 | 次の対応 |
|---|---|
異常あり | 対応責任者に連絡し、サーバーの再起動やログの削除・ローテーションを控えて証拠を保全する。外部通信の制限、サーバー上のパスワードやAPIキーの変更へ進む。EDRの検知履歴、Webサーバーのアクセスログ、公開領域に置かれた見覚えのないファイル、定期実行（cronなど）の設定を調べ、不審な点があれば調査範囲を広げる |
確認した範囲で異常なし | 調べた期間・記録・対象外の範囲を添えて、調査を終えるかを判断者が決める |
判断材料が不足 | 取得できなかった記録とその理由を明記し、別の記録で補えるか、調査範囲を広げるかを決める |
調査を委託先や担当者に依頼する場合は、結論だけでなく、結論を支える範囲と記録を同じ報告に残してもらいます。報告書には次の5項目を設けておくと、判断の前提を共有できます。
調査対象：対象システムと、調査から除外した範囲
調査した期間：さかのぼって調べた過去の期間と、調査を実施した期間
使用できた記録：ログなどの取得元と、記録が残っていた期間
記録の不足：取得できなかった記録、その理由、判断への影響
判断者：結果を判断した人と、追加対応または調査終了を決めた理由
「修正版を適用したため問題なし」という報告では、更新前の状況を何で判断したのかが伝わりません。「更新は完了、侵害調査は判断材料が不足」のように、状態を分けて書いてもらいます。
▲ 脆弱性への「更新対応」と「侵害調査」を分離して進める並行管理構造
侵害が疑われる場合は、証拠を保全したうえで影響範囲の調査や隔離を行います。社内で対応しきれないときの外部調査の費用感と初動は、デジタルフォレンジック調査の解説で整理しています。侵害されたサーバーから管理者の認証情報が盗まれた可能性があるときは、SaaSの管理者アカウントの棚卸しも急ぎます。手順はSaaSの特権ID管理と権限見直しで解説しています。
更新できない古いシステムの扱い
改修しないと更新できない古いシステムは、暫定対策を続けながら、作り直す・既製のサービスに置き換える・廃止するの3つから恒久策を選びます。比べる軸は、その業務を今後も残す必要があるかどうかです。
まず、更新できない理由を保守担当や委託先と切り分けます。改修箇所がわからないのか、連携先との互換性を検証できないのか、停止時間がとれないのかで打ち手が変わります。IPAは、長期間更新していないシステムでは、開発時の資料やノウハウの不足、担当者の不在、保守契約の終了で対策が難しくなっている場合があると指摘し、事業責任者や経営層も含めて、更新後の維持管理まで人員・予算・保守体制を確保できるかを検討するよう求めています。
選択肢 | 向いている条件 | 決めておくこと | 承認する人 |
|---|---|---|---|
作り直し | 自社独自の業務で、今後も残す必要がある | 残す機能とデータ、新旧の処理結果の照合方法、切り戻しの条件 | 業務責任者と情シスが要件を固め、予算決裁者が承認 |
置き換え（SaaSなど） | 必要な要件を既製のサービスで満たせる | データ・権限・連携の移し方、障害時の連絡体制、データの返却・削除、脆弱性対応の責任範囲（契約） | 業務責任者・情シス・契約担当が条件を整理し、予算決裁者が承認 |
廃止 | 業務そのものを終えられる | 保存するデータと削除するデータ、終了後の問い合わせ先と代替手段 | 業務責任者が終了を判断し、データ管理責任者が削除を承認 |
▲ 更新困難なシステムに対する恒久対策3案（作り直し・廃止・SaaS置き換え）の比較
有償の延長サポートを使う場合は、今回の脆弱性が対象に含まれるかを提供元に確認してから契約します。修正版のない系列を抱えたときの考え方は、BIND 9の脆弱性で9.18系に修正版が出ないケースも参考になります。廃止を選んだ場合は、ドメインや外部連携、契約の後始末を忘れると新たな穴になります。SaaS解約後の後始末チェックリストの観点は、自社システムの廃止にもそのまま使えます。
今週決めるのは、恒久策の責任者と方針を決める期限の2つで足ります。移行が終わるまでは暫定対策の内容と担当を記録し続け、暫定対策を保てなくなったときや移行計画が遅れたときに判断をやり直します。
継続運用に向けた情報収集と体制
PHP2Shellは、公表後も新しい脆弱性の追加、機器の修正版の公開、侵害事例の報告と、2週間で情報が何度も更新されました。初回の対応で終わらせず、どこを・どの頻度で確認するかを決めておくことが、次の重大な脆弱性への備えになります。
情シスが情報を取り入れるときは、「誰が出した情報か」と「自社のどの資産に関係するか」の2点で仕分けます。ニュースや解説記事は全体像をつかむのに役立ちますが、版番号や設定値は必ず一次情報で確かめます。今回の件で確認すべき情報源は次のとおりです。
情報源 | 確認すること |
|---|---|
PHP公式（php.net） | 修正版、緩和策、CVE-2026-115560の修正リリース |
JPCERT/CC 注意喚起 | 国内での攻撃状況、侵害調査の観点、追記の有無 |
IPA 重要なセキュリティ情報 | 更新できないシステムの判断の進め方 |
CISA KEV | 悪用が確認されたか（優先度を上げる判断材料） |
機器・製品・SaaSの提供元 | 自社が使う製品の影響有無、修正版、回避策 |
NCSC-NLの製品一覧 | 製品ごとの影響状況の横断的な確認 |
体制面では、作業時間・予算・交代要員を先に確保します。調査・更新・動作確認・監視は通常業務に上乗せされるため、担当者の残業で埋める計画にはしません。担当を交代するときは、対象と未確認事項、実施した対応と記録の保管先、監視の担当と連絡先、次に判断する日時と判断者を引き継ぎます。更新が済んでいても、未確認事項が残る案件は完了扱いにしません。
緊急時に「どの製品が、誰の契約で、どこに問い合わせればよいか」がすぐ出てこないと、確認が止まります。SaaSや保守契約を担当者・更新日とあわせて登録しておく契約管理の仕組みがあれば、提供元への確認先をその場で特定できます。対応の優先度と担当の決め方は、不正アクセス対策の担当と優先順位でも整理しています。
よくある質問（FAQ）
Q. 自社でPHPを使っている自覚がなくても、対応は必要ですか？
A. 必要です。ファイアウォールなどのネットワーク機器、アプライアンス、委託先が運用するWebサイト、利用中のSaaSの中でPHPが動いていることがあります。今回も、管理画面にPHPを使う機器が攻撃の対象になりました。機器やサービスの提供元の発表を確認し、発表がないものは「未確認」として管理します。
Q. 修正版に更新すれば、CVE-2026-115560も解消しますか？
A. 解消しません。CVE-2026-115560は次の定期リリースで修正される予定で、それまでは session.upload_progress.enabled=0 の設定が推奨されています。CVE-2026-109619の緩和策としてすでに設定していれば、追加の作業は不要です。
Q. session.upload_progress.enabled=0 にすると、業務に影響はありますか？
A. ファイルアップロードの進捗を $_SESSION 経由で表示する機能が動かなくなります。そうした機能がないシステムでは影響はほぼありません。実行時にセッションのシリアライズ方式を切り替えないアプリケーションなら、PHP公式は機能を有効のままにしてよいとしています。
Q. WAFを導入していれば、PHPを更新しなくても大丈夫ですか？
A. 更新は必要です。CISAはWAFが更新までのあいだ一定の防御になりうるとしていますが、PHPの開発元は、更新以外に完全な対策はないとしています。WAFは更新までのつなぎと位置づけ、更新の期限を決めておく必要があります。
Q. 侵害調査で痕跡が見つからなければ、攻撃されていないと考えてよいですか？
A. そうとは言えません。JPCERT/CCは、悪用経路が複数あり、ログの記録状況によっては痕跡が残らない場合もあるとしています。調べた期間・記録・対象外の範囲を明記して報告し、監視を続けることが重要です。
Q. Windows版PHPの「8.5.12-1」のような版は何が違いますか？
A. 同梱する圧縮ライブラリBrotliの脆弱性（CVE-2026-111497）を修正するために、10月26日に再配布されたものです。PHP本体の版は変わりません。PHP公式によると、脆弱な処理に到達するのはcURL拡張でHTTP応答の自動展開を有効にしている場合ですが、Windows版を使っている場合は、再配布版への入れ替えが確実です。
Q. PHP 8.2系を使っています。8.2.35に更新すれば当面は安心ですか？
A. 今回の2件は解消しますが、8.2系は2026年12月31日に公式サポートが終わります。それ以降は脆弱性が見つかっても修正版が出ないため、年内に8.3系以降への移行計画を立てる必要があります。
Q. レンタルサーバーやSaaSのPHPは、誰が更新するのですか？
A. PHP本体の更新は提供元が行います。利用企業は、提供元の告知で更新の完了を確認し、PHPの版を選べるサービスでは修正済みの版を選んでいるかを確かめます。サーバー上に設置した自社のアプリケーションやCMSの設定は、利用企業側の管理範囲です。
まとめ
PHP2Shellは、悪用の確認とKEVへの追加、PHPを組み込んだ機器の侵害報告まで進み、すぐに更新すべき段階にあります。修正版の適用は出発点で、PHPの所在の洗い出し、CVE-2026-115560の設定、更新前の侵害調査、更新できないシステムの判断までを終えて、初めて対応が完了します。
自社の対応状況は、次のチェックリストで確認できます。
PHP2Shell 対応チェックリスト
✅ 外部から到達できるPHPのサーバーを特定し、修正版を適用した（またはアクセス制限・停止の判断をした）
✅ Webで実際に動いているPHPの版と設定を確認した（コマンドライン用だけを見ていない）
✅ 管理画面にPHPを使うネットワーク機器・アプライアンスについて、提供元の発表を確認した
✅ 管理画面をインターネットに公開している機器がないかを確認した
✅ 利用中のSaaSと委託先から、対応状況の回答を得た（未回答は「未確認」として管理している）
✅ session.upload_progress.enabled の値を確認した
✅ 更新前の期間について侵害調査を行い、更新の完了とは別に結果を記録した
✅ Linuxカーネルの更新と再起動を確認した
✅ 8.1以前や8.2系のシステムについて、移行・置き換え・廃止の方針と責任者を決めた
PHP以外の点検も進めたい場合は、外部公開の範囲、アカウントと権限、ログなど、9機関の注意喚起をもとにした31項目をサイバーセキュリティチェックリストにまとめています。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
