2026年10月21日、Webサーバーなどで広く利用されているプログラミング言語「PHP」に、認証なしで任意のコードを実行される可能性がある2件の深刻な脆弱性（CVE-2026-109618、CVE-2026-109619）が公表されました。JPCERT/CCが注意喚起を発表し、その後、悪用を主張する実証コードの公開や、悪用を試みる通信の観測が相次いで報告されています。自社が直接管理しているサーバーだけでなく、業務システムや外部委託先が運用する環境など、思いがけないところで影響を受ける可能性がある点で、企業にとって決して他人事ではありません。
しかし、脆弱性が公表されるたびに対象を調査し、対応方法を一から検討していては、攻撃への対処が後手に回りかねません。そこで重要になるのが、日ごろからIT資産を把握し、脆弱性の情報収集から対応完了の確認までを継続的に行う「脆弱性管理」です。本記事では、今回のPHP脆弱性を題材に、脆弱性管理の基本的な考え方と、企業が見直すべき5つの対策を解説します。
この記事の要点
- 脆弱性管理とは、自社のIT資産に存在するセキュリティ上の弱点を把握し、リスクに応じて優先順位を付け、修正・緩和・確認を継続的に行う取り組みです。
- 2026年10月のPHP脆弱性では、修正版の公表直後から悪用を試みる通信が観測されました。また、サポートが終了したバージョン（EOL）には修正版が提供されず、サポート終了製品を使い続けるリスクも明らかになりました。
- 企業が見直すべき対策は、①資産の可視化、②情報収集、③優先度の判断、④修正・緩和とEOL対策、⑤侵害調査と体制づくり、の5つです。
1. 脆弱性管理とは
脆弱性管理とは、ソフトウェアや機器に存在するセキュリティ上の弱点を継続的に把握し、そのリスクを評価したうえで、修正や緩和などの対策を実施する一連のプロセスです。単にソフトウェアを最新版に更新することではなく、自社がどのようなIT資産を利用しているかを把握し、影響を確認して優先順位を決め、実際に対策が完了したかを確かめるところまでを含みます。
そもそも脆弱性（ぜいじゃくせい）とは、プログラムの不具合や設計上の欠陥のうち、攻撃者に悪用されることで情報漏洩や不正操作につながる可能性がある弱点を指します。公表された脆弱性には、CVE（共通脆弱性識別子）という世界共通の番号が付けられます。この番号を手がかりにすることで、異なる情報源で公表された情報を照合し、同じ問題についての情報を整理しやすくなります。
脆弱性管理は、一般に次の5つの工程を繰り返して運用します。
- 把握：自社が利用しているOS、ミドルウェア、アプリケーションとそのバージョンを洗い出し、管理対象を明確にする
- 収集：ベンダーや公的機関が公表する脆弱性情報を継続的に収集し、自社に関係する情報を確認する
- 評価：脆弱性の深刻度や自社への影響、攻撃の可能性を踏まえて対応の優先順位を判断する
- 対応：アップデートの適用、設定変更による緩和策、必要に応じた利用停止などを実施する
- 確認：対策が完了したことを確かめるとともに、脆弱性を悪用された痕跡がないかを調査する
重要なのは、この工程を一度実施して終わりにしないことです。企業のIT環境は、新しいシステムの導入やソフトウェアの更新、端末の入れ替えによって常に変化しており、現在は問題なく使えている製品にも将来新たな脆弱性が見つかる可能性があります。そのため、情報収集と対策を継続的に繰り返し、環境の変化に追随できる仕組みを整えることが求められます。
2. 2026年10月のPHP脆弱性で何が起きたのか
2026年10月に公表されたPHPの脆弱性は、広く利用される基盤ソフトウェアに深刻な欠陥が見つかり、公表から数日のうちに注意喚起、追加の脆弱性公表、悪用を試みる通信の観測が立て続けに起きた事例です。PHPはWebサイトやWebアプリケーションで幅広く使われているため、PHP自体に脆弱性が見つかると、さまざまなシステムやサービスに影響が及ぶ可能性があります。
PHPの開発元は2026年10月21日、CVE-2026-109618とCVE-2026-109619の2件の脆弱性を公表し、修正版を公開しました。JPCERT/CCの注意喚起によると、これらが悪用された場合、攻撃者がPHPの実行プロセスの権限で任意のコードを実行できる可能性があります。具体的には、Webサイトに悪意のあるコードを仕込まれて改ざんされたり、顧客の重要な情報を窃取されたりするおそれがあります。また、侵害されたサーバーが別のシステムへの攻撃の踏み台として悪用されるおそれもあります。JPCERT/CCは、対象製品が国内でも広く利用されていることを確認しています。
| 項目 | 内容 |
|---|---|
| 影響を受けるバージョン | PHP 8.5.12、8.4.27、8.3.36、8.2.35より前の各系列 |
| PHP 8.1以前 | PHP開発元からは修正版が提供されない（7.4、8.0、8.1には最小限の緩和策のみ提供）。ただし、有償サポート付きのLinuxディストリビューションでは、提供元が独自に修正パッケージを提供している場合がある |
| 悪用状況 | 悪用を主張する実証コードの公開、悪用を試みる通信の観測が相次ぐ |
| 根本対策 | 修正済みバージョンへのアップデート |
10月23日には、特定の設定とアプリケーションコードの組み合わせで発生する別の脆弱性（CVE-2026-115560）も公表されました。開発元は通常のリリースサイクルで修正する方針で、JPCERT/CCは修正版が出るまでの間、設定変更による緩和策の適用を推奨しています。米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）は、10月26日（米国時間）に先の2件を「悪用が確認された脆弱性カタログ（KEV）」へ追加し、同日にはJPCERT/CCも、実証コードの公開や悪用を試みる通信の観測について注意喚起を更新しています。
このように、公表から1週間足らずで状況は大きく変わりました。最初の注意喚起だけを見て判断するのではなく、続報を追い続ける体制が必要であることも、今回の事例が示した教訓です。
3. なぜ脆弱性を悪用した攻撃は減らないのか
脆弱性を悪用した攻撃が減らない背景には、公表から攻撃が始まるまでの時間が短くなっている一方で、企業側の対策には一定の時間がかかるという構造的な問題があります。
IPAの「情報セキュリティ10大脅威 2026」では、組織向けの第4位に「システムの脆弱性を悪用した攻撃」が挙げられています。第1位は「ランサム攻撃による被害」ですが、脆弱性の悪用はランサム攻撃にもつながり得る侵入経路の一つです。つまり脆弱性管理は、特定の攻撃だけでなく、企業が直面するさまざまな脅威に備える基本的な対策といえます。
攻撃者は、脆弱性が公表されると修正版の内容などから問題箇所を分析し、インターネット上に公開されているサーバーを機械的に探索して脆弱なシステムを探します。今回のPHP脆弱性でも、修正版の公表後まもなく悪用を試みる通信が観測されています。一方、企業側では、自社のどのシステムでPHPが使われているかをすぐに特定できない、アップデートの前に業務システムへの影響をテストする必要がある、外部委託先や製品ベンダーとの調整が必要になる、サポートが終了したバージョンを使っていて修正版がない、といった理由から、すぐに対策を実施できるとは限りません。
こうした対応を脆弱性の公表後に初めて検討していては、その間に攻撃を受けるリスクが高まります。平時から影響確認や更新作業を進められる体制を整えておくことが重要です。
4. 「パッチを当てるだけ」の運用の限界
脆弱性対策をパッチの適用だけで考えると、管理対象の把握漏れ、対応の遅れ、サポート終了製品への対処といった問題を解決できません。重大な脆弱性が公表されるたびに担当者が個別にアップデートする運用は一見合理的ですが、IT環境が複雑になるほど、次の3つの限界が表れます。
1つ目は、資産の把握漏れです。 脆弱性情報を入手しても、その製品を自社のどこで使っているか分からなければ対応できません。管理台帳に登録されていないサーバー、部門が独自に契約したクラウドサービス、退職者が構築したまま放置されたWebサイトなどは対象から漏れやすく、把握しているシステムだけに対策しても脆弱な環境が残るおそれがあります。
2つ目は、対応の優先順位を付けられないことです。 公表される脆弱性は年間数万件に上り、すべてに同じ速さで対応するのは現実的ではありません。深刻度の数値だけで判断すると、自社への影響が大きいものと限定的なものを区別しにくくなります。
3つ目は、サポート終了（EOL）製品への対応です。 EOLとは、製品やソフトウェアのサポートが終了することを指します。今回、PHP 8.1以前のバージョンにはPHP開発元から通常の修正版が提供されませんでした。ただし、RHELなどの有償サポート付きLinuxディストリビューションでは、開発元のサポート終了後も提供元が独自に修正を提供する場合があります。ただし、それに頼れるかどうかは提供元の対応状況次第です。EOL製品は脆弱性が見つかっても修正されない場合があるため、期限前に後継バージョンへの移行を計画しておく必要があります。
これらの限界を補うのが、次章から解説する5つの対策です。
5. 対策①：IT資産とソフトウェア構成を可視化する
脆弱性管理の第一歩は、自社が利用しているIT資産と、その中で動作しているソフトウェアの構成を正確に把握することです。サーバー、PC、スマートフォン、ネットワーク機器、クラウドサービスなどを対象に、OSやミドルウェアの種類とバージョン、管理者、インターネットへの公開有無を台帳に整理します。
ポイントは、機器の名称を並べるだけでなく、脆弱性が公表された際に影響の有無を判断できる情報まで管理することです。今回のPHP脆弱性はOSを問わず影響する可能性があり、LinuxだけでなくWindows Server上で動作するPHPも確認対象です。また、脆弱性によっては特定のOS環境でのみ発生する場合もあるため、OSとPHPのバージョンの組み合わせを台帳に記録し、影響を確認できるようにしておく必要があります。自社のWebサイトだけでなく、業務システム、複合機などの組み込み機器、外部委託先が運用するサーバーまで、PHPが使われている可能性がある場所ごとに、どこに何を確認すればよいかを整理しておくと、公表時の調査を短時間で進められます。
台帳は一度作れば終わりではありません。導入・変更・廃棄の申請フローと台帳の更新を結び付け、実際の利用状況と一致させ続けることが効果的です。さらに、自社で開発・管理するソフトウェアについては、使用しているライブラリなどの構成部品も把握しておくことが重要です。構成部品の一覧であるSBOM（ソフトウェア部品表）を活用すれば、基盤ソフトウェアに脆弱性が公表された際に、影響を受ける部品やシステムの特定を支援できます。
6. 対策②③：情報収集の経路を決め、リスクに応じて優先順位を付ける
脆弱性情報の見落としを防ぎ、限られた人員で効果的に対応するには、信頼できる情報源から継続的に情報を集め、悪用状況や利用環境を踏まえて優先順位を判断する仕組みが必要です。
情報収集の経路を決める
企業が利用できる主な情報源には、JPCERT/CCの注意喚起、JVN（Japan Vulnerability Notes）と脆弱性対策情報データベースJVN iPedia、利用している製品ベンダーのセキュリティアドバイザリ、CISAのKEVカタログ（悪用が確認された脆弱性の一覧）があります。担当者が個人的にニュースを追うだけの運用では、不在や異動で情報収集が途切れるおそれがあるため、メール配信やRSSを活用し、確認の担当者と頻度を決めておくことが大切です。集めた情報は資産台帳と照合し、対応が必要なシステムが実際に存在するかを確かめます。
リスクに応じて優先順位を付ける
深刻度を評価する指標としてCVSS（共通脆弱性評価システム）がありますが、同じ脆弱性でも利用環境によって実際のリスクは異なります。そのため、悪用の状況（KEVへの登録、実証コードや攻撃の観測報告の有無）、露出度（インターネットから直接アクセスできるか）、資産の重要度（個人情報や機密情報を扱うか、停止すると業務に影響するか）、認証の要否（認証なしで悪用できるか）を組み合わせて判断します。
今回のPHP脆弱性をこの4つの観点で評価すると、悪用の状況（KEVへの追加、実証コードの公開、悪用を試みる通信の観測）と認証の要否（認証なしで任意のコードを実行されるおそれ）は、いずれも最も重い条件に当たります。残る露出度と資産の重要度は自社の環境によって変わるため、インターネットに公開されたWebサーバーや、個人情報を扱うシステムで影響を受けるバージョンを使っている場合は、最優先で対応すべきケースだったといえます。
こうした判断を毎回一から行うのではなく、「悪用が確認され、インターネットに公開されているシステムは何日以内に対応する」といった基準をあらかじめ決めておけば、関係者間で判断が分かれることを防ぎ、対応開始までの時間を短縮できます。
7. 対策④⑤：修正・緩和とEOL移行を計画し、侵害調査の体制を整える
脆弱性への根本的な対策は修正済みバージョンへのアップデートであり、あわせてサポート期限を見据えた移行計画と、すでに侵入されていないかを確かめる体制を整えることが重要です。
修正版の適用と緩和策、EOL製品の移行
業務システムでは、更新によって既存機能や外部連携に影響が出る可能性があるため、事前のテストが必要になる場合があります。すぐに更新できないときは、設定変更による緩和策、アクセス制限、一時停止などを組み合わせてリスクを低減します。今回のPHP脆弱性でも、JPCERT/CCは設定変更による緩和策を案内していますが、特定の攻撃経路にしか対処しないため、根本対策は修正済みバージョンへのアップデートのみとしています。緩和策は、修正版を適用するまでの暫定的な対応と位置付けることが重要です。
加えて、WAF（Web Application Firewall）の活用も有効です。WAFは、Webサーバーへのリクエストに含まれる不審な文字列やパラメーターなどを検知し、設定されたルールに基づいて攻撃と疑われる通信を遮断する仕組みです。今回の脆弱性についても、特定のCookieやパラメーターを含むリクエストを遮断するルール例が公開されています。サービスによっては脆弱性に対応した検知ルールが自動更新されるため、適切なルールが適用されているか確認するとよいでしょう。ただし、WAFですべての攻撃を防げるわけではなく、修正版の適用に代わるものではありません。
PHPは、各系列が初回リリースから2年間の通常サポートと、その後2年間のセキュリティ修正のみのサポートを受ける仕組みです。8.2系のセキュリティサポートは2026年12月31日に終了する予定で、利用中の企業は後継バージョンへの移行を速やかに計画する必要があります。一方、RHELなどの有償サポート付きLinuxディストリビューションでは、提供ベンダーが独自にセキュリティパッチを提供する場合があり、今回もRHEL 8向けのPHP 7.4に修正パッケージ（RHSA-2026:87080）が提供されているため、利用環境に応じて提供元の対応状況を確認することが重要です。系列ごとの修正版とサポート期限を把握しておけば、どのシステムをいつまでに移行すべきかを判断しやすくなります。
今後は資産台帳にサポート期限を記録し、テストや関係部門との調整に必要な時間も見込んで、原則として期限の1年前から移行準備を進める運用が望まれます。
侵害調査と対応体制
修正前に攻撃者が侵入していた場合、アップデート後もその影響が残っている可能性があります。そのため、「新たな悪用を防ぐ対策」と「過去の侵害を調べる対応」は区別して考える必要があります。JPCERT/CCは今回、修正版への更新とあわせて侵害の有無を調査するよう推奨しています。痕跡が見つからなくても、攻撃を受けていないことの証明にはならない点にも注意が必要です。
Webサーバーのアクセスログやエラーログを一定期間保存し、過去の通信やシステムの状態を確認できるようにしておくことが重要です。システムの運用を外部委託している場合は、脆弱性公表時に誰が影響調査を行い、どこまで対応するのか、報告期限や対応範囲を契約やSLA（サービス品質の合意）で取り決めておくと、連絡や調整を進めやすくなります。
8. 重大な脆弱性が公表されたときの初動
重大な脆弱性が公表された場合は、影響確認、優先度判断、応急対応、恒久対応、侵害調査、記録と振り返りの順に進めることが重要です。今回のPHP脆弱性に当てはめると、各段階で行う作業は具体的に次のようになります。
- 影響確認：資産台帳をもとに、PHPを使っているシステムとそのバージョンを特定します。サーバー上では
php -vなどのコマンドでバージョンを確認でき、委託先や製品ベンダーにも影響の有無を問い合わせます。 - 優先度判断：インターネットに公開されているか、悪用が確認されているかなどを踏まえ、対応の緊急度を判断します。
- 応急対応：修正版をすぐに適用できない場合、JPCERT/CCはCVE-2026-115560の修正版が出るまで
session.upload_progress.enabled=0を設定し、すべてのワーカーを再起動することを推奨しています。この設定はCVE-2026-109619の緩和策としても案内されています。また、WAFを利用している場合は、今回の脆弱性を狙う不審なリクエストを遮断するルールの適用も検討します。 - 恒久対応：テストを行ったうえで、8.5.12、8.4.27、8.3.36、8.2.35以降の修正済みバージョンを適用します。8.1以前を使っている場合は、サポートされている系列へ移行します。
- 侵害調査：JPCERT/CCが挙げる手掛かり（異常に長いPHPSESSID Cookie、不審なmultipart/form-data形式のリクエスト、PHPのメモリ上限エラーやHTTP 500エラー、ワーカープロセスの異常終了や頻繁な再起動）を中心にログを確認します。侵害が疑われる場合は、証拠保全、影響範囲の調査、システムの隔離などのインシデント対応へ移行します。
- 記録と振り返り：対応に要した時間や課題を記録し、資産台帳や対応手順の改善につなげます。
なお、個人情報を扱うシステムで不正アクセスによる漏洩が発生した場合や、そのおそれがある場合は、個人情報保護法に基づき、個人情報保護委員会への報告と本人への通知が必要になることがあります。技術的な対策だけでなく、侵害が疑われる際の調査や報告の体制も整えておくことが重要です。
9. OPTiM Bizで端末のOS・アプリのバージョンを把握し、アップデートを制御する
社員が使うPCやスマートフォンの脆弱性管理は、MDM（モバイルデバイス管理）で端末ごとのOS・アプリのバージョンを把握し、OSアップデートの適用時期を制御することで効率化できます。端末のOS、Webブラウザ、業務アプリケーションにも毎月のように脆弱性が公表されており、台数が多く社外にも持ち出される端末は、サーバー以上に更新状況の把握が難しい領域です。
OPTiM Biz は、スマートフォン・タブレット・Windows/Mac PCに対応するMDMです。管理画面から端末ごとのOSバージョンや、インストールされているアプリケーションの名前・バージョンを一覧で確認できるため、脆弱性が公表された際に、影響を受けるバージョンを使っている端末を素早く洗い出せます。これは、対策①で解説した資産の可視化を端末の領域で実現する取り組みです。
さらに、OSアップデートの適用タイミングも管理画面から制御できます。たとえば、監視対象のiOS/iPadOS端末ではOSのリリース日から1〜90日の範囲で更新を延期でき、Windowsでは機能更新プログラムを0〜365日の範囲で延期したり、品質更新プログラムの延期日数を設定したりできます。Androidでは、更新が利用可能になった時点での強制インストールや、指定した時刻でのインストールを設定できます。業務アプリへの影響を確認する期間を確保しつつ、確認が済んだら全社に確実に更新を行き渡らせるといった、計画的なアップデート運用につなげられます。
ただし、ツールを導入しただけで脆弱性管理が完結するわけではありません。脆弱性情報の収集、影響の評価、優先順位付け、更新の判断、侵害の有無の調査といった運用は、企業側で継続して実施する必要があります。
10. まとめ
今回のPHP脆弱性は、修正版の公表から数日で攻撃が試みられ、サポートが終了したバージョンには修正版すら届きませんでした。日々の業務を抱えながら、公表のたびに「自社は影響を受けるのか」を一から調べるのは、情報システム担当者にとって大きな負担です。だからこそ、すべてを一度に整えようとせず、今週・年内・その後と時期を区切って、次に同じことが起きたときに慌てずに済む準備を進めていきましょう。
まず今週中に取り組みたいのは、自社でPHPが動いている場所の確認です。LinuxだけでなくWindows Server上のPHPも対象となるため、自社のWebサイトや業務システムはOSとPHPのバージョンを確認し、 php -v などで8.5.12、8.4.27、8.3.36、8.2.35より前であれば、テストの段取りを決めて更新を進めてください。有償サポート付きディストリビューションを利用している場合は、提供元によるセキュリティパッチの対応状況も確認します。すぐに更新できない場合は、JPCERT/CCが案内する緩和策を適用し、WAFを利用していれば対応する検知・遮断ルールの適用状況も確認したうえで、ログに侵害の痕跡がないかもあわせて調査します。外部委託先や製品ベンダーが管理しているシステムは、影響の有無と対応予定を問い合わせ、回答を記録しておきましょう。
次に、年内に済ませておきたいのが、8.2系を使っているシステムの移行計画づくりです。8.2系のセキュリティサポートは2026年12月31日に終了するため、残された時間は多くありません。あわせて、今回の調査で分かったPHPの利用箇所やバージョン、管理者、サポート期限を資産台帳に書き込んでおけば、次の脆弱性が公表されたときの影響確認を短時間で済ませられます。
そのうえで、JPCERT/CCやJVN、利用製品のベンダー情報を誰が、どの頻度で確認するのかを決め、「悪用が確認されていて、インターネットに公開されているシステムは最優先で対応する」といった判断基準を社内で共有しておくと、脆弱性管理は個人の頑張りに頼らない仕組みに変わっていきます。サーバーだけでなく、社員が毎日使うPCやスマートフォンについても、OSやアプリケーションのバージョンを一覧で把握できる状態にしておくことが、次の脆弱性に備える確かな一歩になります。