PHPの脆弱性のニュースを聞いて「利用しているSaaSは大丈夫？」と聞かれた情シスに伝えたい経営層への報告の考え方

概要

2026年10月21日、PHP に重大な脆弱性（通称 PHP2Shell）が見つかり、高市早苗総理大臣が自身の X で「大至急のお願い」として対応を呼びかけました。PHP は Web サイトや Web アプリケーションを作るためのプログラミング言語で、WordPress をはじめ多くの Web サイトで使われています。夜のニュースでも大きく取り上げられ、普段はセキュリティの話題に関心が薄い経営層からも質問が飛んできた、という情シスの方は多いのではないでしょうか。

大前提として経営層がセキュリティに関心をもってくれる（予算もつけてくれるなら尚更！）のはとても嬉しいです。一方で、自社で運用しているのは WordPress のコーポレートサイトくらいで、業務はほぼ SaaS で回している、という会社の情シスにとっては「利用しているSaaSは大丈夫なのか？」という質問にどう答えれば良いのか、悩ましい状況でもあります。

この記事では、SaaS 利用がメインの一般企業の情シスが、脆弱性ニュースのたびに届く経営層からの質問にどう向き合えば良いのか、考え方をまとめてみました。

3行まとめ

• SaaS の基盤の脆弱性対応はベンダーが担うため、利用者側で確認・対応できる範囲は限られる
• 情シスは、自社で運用しているものの対応と、SaaS の公式発表の収集・整理に注力する
• 経営層には「影響あり・対応中／影響なし・対応済み／個別の告知を確認できず／確認中」を区別し、利用者側の対応要否も添えて報告する

はじめに：総理大臣の鶴の一声「こうかは ばつぐんだ」

こんな会話があったのではないでしょうか？

今回の PHP2Shell では、総理大臣自らが対応を呼びかけるという異例の展開になりました。10月21日 21:55、パッチ公開のおよそ1時間前に投稿されたものです。わずか2日で9000万PVという物凄い閲覧数です。

皆様に、今夜に対応して頂きたい大至急のお願いです。
多くのウェブサイトで使用されているPHPに関し、PHPのセキュリティチームが、重大な２件の脆弱性に関する注意喚起を行っています。
公開しているウェブサイトでPHPを使用しているか確認し、今夜、10月21日午後11時（日本時間）に公開される修正パッチについて、可及的速やかに適用できるよう準備をお願いします。
修正パッチを速やかに適用することが困難な場合は、例えばウェブサイト等を一時的に停止させることも、リスクを低減させるための有効策の一つと考えられます。

国家サイバー統括室のXアカウントでも関係する情報を発信していますので、そちらも参考にして下さい。
国家サイバー統括室(注意・警戒情報)（@cyber_forecast） / X

国家サイバー統括室も同様の呼びかけを行っており、報道では「経営層にもリスクが認知される」とエンジニアからも評価されています（ITmedia NEWS）。自社の Web サイトや自社サービス、自社の情報を預けている SaaS への影響を、経営層が重要事項として考えてくれるようになった、という意味でとてもうれしいことです。

高市総理「大至急、PHPパッチ適用を」Xで異例の要請　エンジニアは評価「経営層に伝わる」 首相が個別のソフトウェア脆弱性について、Xで直接対応を呼び掛けるのは異例。エンジニアからは「総理が発信したことにより、経営層にもリスクが認知される」など一定の評価が出ている。（1/2 ページ） https://www.itmedia.co.jp/news/article/2610/22/2000002483/

ここで投稿をよく読むと、呼びかけの対象は「公開しているウェブサイト」、つまり自分たちで運用しているサイトです。利用している SaaS について何かをしてほしい、とは書かれていません。とはいえ、経営層から見れば「うちのITは全部大丈夫か？」という気持ちになるのは自然なことです。

そのうえ、同じ週には Node.js や Oracle Java の脆弱性情報も出ており（IPA：Oracle Java の脆弱性対策について(2026年10月)）、脆弱性が出るたびに「利用しているSaaSは？」と聞かれる状況は、情シスにとってはこれはこれで悩ましいというお話です。

Oracle Java の脆弱性対策について(2026年10月) | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 情報処理推進機構（IPA）の「Oracle Java の脆弱性対策について(2026年10月)」に関する情報です。 https://www.ipa.go.jp/security/security-alert/2026/1021-jre.html

背景：今回なにが起きたのか

ざっくり整理しておきます。

• 脆弱性：PHP の CVE-2026-109618 と CVE-2026-109619。組み合わせて悪用されると、遠隔の第三者に任意のコードを実行される可能性がある（通称 PHP2Shell）
• 修正版：PHP 8.2.35／8.3.36／8.4.27／8.5.12。PHP 8.1 以前はサポート終了のため修正が提供されない
• IPA の対応：10月21日に事前準備のお願い、10月22日に注意喚起を公開

（出典：IPA：PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)、IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について）

PHP は多くの Web サイトで使われているため、パッチ適用まで予防的にサイトを停止する企業も相次ぎました（INTERNET Watch）。

多くのサイトが予防的に公開停止、高市総理が対応呼びかけ―「PHPの深刻な脆弱性」対応で何が起きた？　 　10月21日、スクリプト言語「PHP」の深刻な脆弱性2件が発表されるとともに、同日23時に修正プログラムの提供が予告された。CVE-2026-109618、CVE-2026-109619の2つで、CVSS 4.0のスコアはいずれも9.2。全てのPHPが影響を受け、認証なしでリモートコード実行が可能になるおそれがある。この脆弱性は「php2shell」とも呼ばれる。 https://internet.watch.impress.co.jp/docs/news/2150203.html

問題：SaaS を使って業務を行っている会社では「自社でやれること」が限られる

自社でアプリやサービスを開発している会社であれば、自社のコードやサーバーを棚卸しして、パッチを当てる作業が必要です（とても大変ですが、更新体制を整えている組織はすごいと思います）。

PHP 8.5.12の緊急リリースにpixivはどう対応したか - pixiv inside こんにちは、Platform Division Infrastructure Unitのpicopicoです。 2026年10月21日、PHPに深刻な脆弱性（通称PHP2Shell）が見つかり、緊急のセキュリティリリースが予告されました。今回の脆弱性への対応にあたられた皆さま、そして現在も対応を続けている皆さまに、心より敬意を表します。 ピクシブでは影響を受ける可能性のあるサービスを10月21日19時より事前にメンテナンスモードにし、セキュリティアップデートのリリースを待ってパッチを当てる方針を取りました。今回、pixivの稼働環境を、ベアメタルのApache HTTP ServerからKub… https://inside.pixiv.blog/2026/10/22/193321

ところが、業務の多くを SaaS で行っている会社では事情が違います。メールもファイル共有もチャットも SaaS、という場合、その裏側のサーバーやミドルウェアを管理しているのは自社ではありません。

そもそもSaaSの脆弱性は誰が対応する？

総務省のガイドラインでは、クラウドサービスは事業者と利用者が責任を分担する「責任共有モデル」で整理されています。SaaS の場合、利用者が担うのはアカウントや業務データの設定までで、アプリケーション以下の環境は事業者が担います（総務省：クラウドサービス利用・提供における適切な設定のためのガイドラインの概要）。

身近な例でいえば、賃貸マンションのようなものです。建物の配管に不具合が見つかったとき、修理するのは管理会社で、住人ができるのは管理会社からのお知らせを確認することと、自分の部屋の鍵をきちんと管理することくらいです。

SaaS 基盤への影響を利用者だけで確かめるのは難しい

SaaS の裏側でどのミドルウェアのどのバージョンが動いているかは、通常、利用者からは見えません。そのため、SaaS 基盤への脆弱性の影響や修正完了を、情シスが独立に検証することは困難です。基盤の状況については、ベンダーの公式発表やサポート回答をもとに確認・報告することになります。

一方で、利用者側の設定や、提供されている監査ログなど、自社で確認できる範囲もあります。基盤の修正状況を自力で検証することと、利用者側で必要な確認・対応を行うことは分けて考えましょう。

そして困ったことに、ベンダーが公表する情報の粒度はベンダーごとにバラバラです。

本題：ベンダーの公表・回答には「ケース」がある

今回、弊社で取り扱っている各種 SaaS について公表内容やサポートの回答を確認したところ、大きく3つのケースに分かれました。

ケース１）個別に影響状況を告知

たとえば Okta は、クラウドサービスへの影響がないことを告知しています。

Okta and Auth0 cloud service platforms are not affected by these vulnerabilities.
（Okta および Auth0 のクラウドサービス基盤は、これらの脆弱性の影響を受けません）
Okta response to PHP2Shell

Okta's Response to PHP2Shell On October 21, 2026, industry-wide third-party critical PHP pre-authentication remote code execution (RCE) vulnerabilities (<a href="https://nvd.nist.gov/vul https://sec.okta.com/articles/2026/10/okta-response-to-php2shell/

Notion も、ステータスページで現時点では影響がないことを告知しています。ただし、レビューは継続中とされています。

We have found no impact to Notion from PHP2Shell. Notion’s services do not run PHP.
（PHP2Shell による Notion への影響は確認されていません。Notion のサービスは PHP を使用していません）
PHP2Shell (CVE-2026-109618, CVE-2026-109619) - Notion Status

PHP2Shell (CVE-2026-109618, CVE-2026-109619) - Notion Status Status: No impact identified; review ongoing We have found no impact to Notion from PHP2Shell. Notion's services do not run PHP. Our review is continuing, and we'll update this notice if anything changes. https://www.notion-status.com/incidents/01M5K1RNRANQ1YWEAF2W6R0N51

このケースであれば、経営層には告知のリンクを添えて「影響なし」と報告できそうです。

ケース２）対応済みとだけ回答

今回、当社がサポートへの問い合わせで得た回答の中には、「影響を受ける可能性のあるシステムで必要な措置を完了した。悪用の兆候は確認されていない。具体的なバージョンは開示しない。利用者側の対応は不要」というニュアンスの内容のものがありました。（これは回答の要旨です）

具体的なバージョンが非開示でも、回答の対象となるサービス・範囲を確かめたうえで、「対応済み」「利用者側の対応は不要」と回答を得たことを経営層に報告できます。

ケース３）個別の告知がないベンダー

情シスとして一番悩むのがこの型です。ここでは、多くの会社で使われている Microsoft 365 と Google Workspace の公開情報を見てみます。

Microsoft 365 の場合

2026年10月23日時点で、当社が確認した Microsoft Learn の公開情報と、当社が参照できる Microsoft 365 管理センターのメッセージセンター・サービス正常性の範囲では、今回の PHP 脆弱性に関する Microsoft 365 向けの個別告知は確認できませんでした。なお、これは確認した範囲での結果であり、すべてのテナントへの通知状況を示すものではありません。

ただし Microsoft は、Microsoft 365 の基盤で継続的に脆弱性スキャンと修正を行っていることを、平時の運用方針として公開しています。

Microsoft 365 routinely scans all its systems and applicable network devices for known vulnerabilities and centrally tracks their remediation in a timeframe directly related to their severity.
（Microsoft 365 は、すべてのシステムと対象のネットワーク機器を既知の脆弱性について定期的にスキャンし、深刻度に応じた期間内での修正を一元的に追跡しています）
Microsoft 365 vulnerability scanning and remediation

Microsoft 365 vulnerability scanning and remediation - Microsoft Service Assurance This article, provides an overview the routine vulnerability scanning and remediation process in Microsoft 365. https://learn.microsoft.com/en-us/compliance/assurance/assurance-microsoft-365-vulnerability-scanning-and-remediation

Microsoft service teams review the analysis from the security team and update their service components and baseline images with applicable patches within the appropriate remediation timeframe.
（Microsoft のサービスチームは、セキュリティチームの分析をレビューし、適切な修正期間内に、サービスのコンポーネントとベースラインイメージに該当するパッチを適用します）
Threat and vulnerability management

Threat and vulnerability management - Microsoft Service Assurance Learn about threat and vulnerability management in Microsoft 365 https://learn.microsoft.com/en-us/compliance/assurance/assurance-vulnerability-management

Google Workspace の場合

Google Workspace も同様で、2026年10月23日時点で Google Workspace を対象とした個別の告知は確認できませんでした。Google Workspace Status Dashboard にも、今回の脆弱性に関する掲載はありません。

Google Cloud 向けにはセキュリティ情報が出ていますが、対象として挙げられているのは Google Cloud の製品で、Google Workspace への言及はありません。「Google は影響なしと言っていた」と、Google Workspace にそのまま当てはめないよう注意が必要です。

一方で Google も、Google Workspace のセキュリティホワイトペーパーで、脆弱性管理のプロセスを公開しています。

Google’s vulnerability management process actively scans for security threats
（Google の脆弱性管理プロセスは、セキュリティ上の脅威を能動的にスキャンしています）

The team tracks each issue and follows up frequently until they can verify that it has been remediated.
（チームは各問題を追跡し、修正されたことを確認できるまで頻繁にフォローアップします）
Operational security - Google Workspace

Operational security - Google Workspace The security culture at Google extends past their dedicated security team to training for all employees, a privacy team, and internal audit specialists. https://workspace.google.com/intl/en_uk/learn-more/security/security-whitepaper/page-3

ケース３）のときの考え方

注意したいのは、Microsoft、Google ともに、これらはあくまで平時の運用体制の説明であり、今回の CVE への対応完了を示すものではない、という点です。一方で、告知が見つからないことをもって「影響あり」とも「影響なし」とも言えません。

落とし穴：同じベンダーでも「SaaS」と「自社で動かす製品」は別

Okta の告知をよく読むと、クラウドサービスは影響なしとする一方で、オンプレミス製品の Okta Access Gateway にはパッチが必要と案内されています。

On-premise software: Okta Access Gateway (OAG) requires a patch. Customers should upgrade to Okta Access Gateway version 2026.44.0.
（オンプレミス製品：Okta Access Gateway（OAG）にはパッチが必要です。利用者は Okta Access Gateway バージョン 2026.44.0 にアップグレードする必要があります）
Okta response to PHP2Shell

Okta's Response to PHP2Shell On October 21, 2026, industry-wide third-party critical PHP pre-authentication remote code execution (RCE) vulnerabilities (<a href="https://nvd.nist.gov/vul https://sec.okta.com/articles/2026/10/okta-response-to-php2shell/

同じ告知には、Auth0 および Okta の SDK 利用者向けの案内もあります。該当する SDK を使っている場合は、リンク先のナレッジベースで対応内容を確認しましょう。

「Okta のクラウドサービスは影響なし」という発表だけを見て、関連製品も含めて自社の作業が不要だと判断すると、対応漏れが起きます。SaaS 本体と、自社で動かすゲートウェイや SDK などのコンポーネントは分けて確認しましょう。

解決策：情シスがやること

大枠としては以下の通りです。

1. 自社で「運用している」ものと「使っている」ものを分ける
2. 運用しているものは自分ごととして対応する
3. 使っているもの（SaaS）は公式発表の確認を基本にし、問い合わせは優先度をつける
4. 経営層には影響・対応状況と、利用者側の対応要否を報告する

対応１：「運用している」ものと「使っている」ものを分ける

まず、情シスとして手を動かせる範囲を切り分けます。

なお、総務省のガイドラインでは、設定作業を委託した場合でも最終的な責任は利用者に残る、と整理されています（総務省：同ガイドラインの概要）。WordPress サイトを制作会社に任せている場合も「自社のもの」として扱いましょう。

対応２：運用しているものは自分ごととして対応する

ここは IPA の注意喚起のとおりです。脆弱性報告されたライブラリを使っているものを棚卸しし、修正版の適用、難しければアクセス制限や一時停止を判断します。IPA は、管理担当者だけでなく事業責任者や経営層も含めて、維持管理体制を確保できるかの検討も求めています（IPA：PHPの脆弱性対策について）。

経営層の関心が高い今こそ、PHPの事例でいえば保守体制がないまま放置されているサイトの整理（移行や公開終了を含む）を提案するチャンスです。

対応３： SaaS は公式発表の確認を基本にし、問い合わせは優先度をつける

IPA の事前準備のお願いでも、利用している製品については次のように書かれています。

PHPの利用状況が不明な製品についても、引き続き開発元・提供元からの情報をご確認ください。
（IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について）

【事前準備のお願い】PHPのセキュリティリリース公開予定について | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構 情報処理推進機構（IPA）の「【事前準備のお願い】PHPのセキュリティリリース公開予定について」に関する情報です。 https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html

つまり、SaaS については「ベンダーの情報を確認する」が基本です。利用している SaaS が数十あると、すべてに問い合わせて回答を待つだけで手一杯になってしまうので、次の順で進めるのが現実的です。

1. ベンダーのトラストセンター、セキュリティアドバイザリ、ステータスページを確認しましょう（主な確認先は記事末尾の付録をご参照ください）
2. 告知がなく、かつ業務影響の大きい SaaS（認証基盤、機密データを扱うサービスなど）を中心に問い合わせるか検討しましょう
   1. ただし、ケース３）のように脆弱性管理方針が公開されている場合は、その方針と現時点で確認できる情報をもとに報告することでよいか、まず社内で認識を合わせましょう。管理方針の公開は、個別の脆弱性について告知する基準や、今回の対応完了を示すものではありません。問い合わせても、管理方針の案内にとどまり、個別の回答を得られない場合もあります。継続的に公開情報を確認する方針で合意できるのも良いアプローチです。
3. 問い合わせる場合は CVE 番号を明示し、「影響あり／なし／調査中」と「利用者側の対応要否」を聞きましょう

対応４：経営層には影響・対応状況と、利用者側の対応要否を報告する

ここまでの3つのケースは、ベンダーの公表・回答の違いを整理したものです。経営層への報告では、「影響あり・対応中」の場合も含め、利用者側で何をする必要があるかを添えましょう。

報告の形は会社ごとにさまざまですが、例えば次のような形でまとめると、状況が伝わりやすいと思います。個別に問い合わせて回答を待っているものは「確認中」にまとめ、重複して記載しないようにします。

以下は報告の例示です。

【PHP脆弱性（CVE-2026-109618／CVE-2026-109619）の影響確認状況】10月23日時点

■ 自社で運用しているもの
・コーポレートサイト（WordPress）：委託先にてパッチ適用済み（10/22）

■ 利用しているSaaS
・影響あり・対応中：〇〇（公式告知あり。ベンダーが修正中。利用者側には設定変更の案内があり、情シス担当が10/23中に対応予定）
・影響なし／対応済み：〇〇、〇〇（告知・回答あり。利用者側の追加対応は不要との案内）
・個別の告知を確認できず：〇〇（確認した範囲では個別情報なし。今回の影響・対応状況と利用者側の対応要否は未確認。公式情報の確認を継続）
・確認中：〇〇（サポートへ問い合わせ済み、回答待ち。影響・対応状況と利用者側の対応要否を確認中）

■ 次回報告
10月26日午前中に、回答の有無にかかわらず状況をご報告します。
緊急の対応が必要とわかった場合は、その時点でご報告します。

「月曜までに」と期限を切られることもありますが、回答の時期は情シスではコントロールできません。期限の時点でわかっている範囲を報告し、残りは続報にする、という進め方を最初に伝えておくと、お互いに安心です。

補足：経営層と平時に話しておきたいこと

今回のような脆弱性ニュースは、これからも繰り返し出てきます。そのたびに一から確認方法を考えるのは大変なので、今回の件をきっかけに、次のような点を経営層とすり合わせておくと、次の脆弱性ニュースのときに慌てずに済むかもしれません。

• SaaS の基盤の脆弱性対応はベンダーが担うため、報告はベンダーの公式発表をもとに行う
• 個別の告知がないことは、ただちに「影響あり」を意味しない。
• 特定のライブラリバージョンを利用しているかを確認目的にしない。
• 報告は「影響あり・対応中／影響なし・対応済み／個別の告知を確認できず／確認中」を区別し、利用者側の対応要否を添える。対応が必要なものは担当と期限を、未確認のものは次回報告予定を示す
• 利用中の SaaS ごとに、トラストセンターやステータスページの URL を台帳にまとめておく
• 新しく SaaS を選ぶときは、脆弱性の情報をどのように公表しているかも確認しておく

あらかじめ「どう報告するか」を決めておけば、情シスも毎回悩まずに済みますね。

まとめ

• 総理の注意喚起で、経営層が自社の Web サイトや SaaS への影響を重要事項として考えてくれるようになったのはチャンスです
• ただ SaaS を使って業務を行っている会社では、基盤の脆弱性対応はベンダーが担うため、自社でやれることは限られます
• 今回のベンダーの公表・回答を踏まえると、「影響なしを告知」「対応済みとだけ回答」「個別の告知なし」の3つのケースに分かれます（毎回同じとは限らない）
• 情シスは、自社で運用しているものの対応と、SaaS の公式発表の確認・整理に注力してみましょう
• 経営層には「影響あり・対応中」も含めて状況と利用者側の対応要否を報告し、「告知がない＝影響あり」ではないことを共有しておきましょう

参考になれば幸いです。

付録：主な SaaS の公式情報の確認先

各SaaSの脆弱性や障害があればまず見に行く先の例です。自社で利用している SaaS の分を台帳にまとめておくと便利です。