PHPの脆弱性とは　企業が確認すべき影響と対応を解説します

2026年10月21日、Webサイトを動かすために広く使われている「PHP」で、セキュリティ上の重大な問題が公表されました。国内のサービスでも、被害を防ぐための緊急メンテナンスが各webサイト運営会社から発表されました。

企業にとって、まず知りたいのは「自社にも関係するのか」「誰に何を確認すればよいのか」ではないでしょうか。社内でPHPを使った開発をしていなくても、外注した企業サイトやWordPressで作ったサイトに使われている可能性が十分あります。また、利用している外部サービスが対策のために停止し、業務に影響が出る場合もあります。

本記事では、今回の問題と企業への影響を整理し、企業の情報システム部門が進めるべき対応を解説します。

1. PHPの中に発見された脆弱性とは

企業サイトにも使われるプログラミング言語「PHP」に問題が見つかった

PHPは、Webサイトでページを表示したり、入力された情報を処理したりするために使われるプログラミング言語です。例えば、企業サイトの運営によく使われるWordPressも、PHPを利用して動いています。社員のパソコンに入っていなくても、サーバー側で使われています。

今回見つかったのは、そのPHP自体のセキュリティ上の欠陥、いわゆる「脆弱性」です。PHPの開発元によると、悪用された場合、外部の攻撃者にサーバー上で不正な処理を実行されるおそれがあります。企業としては、サイトや保管情報に影響が及ぶ可能性がある問題として、確認を進める必要があります。

ログイン画面があるから安全、とは判断できません。開発元は、利用環境によってはサイトのプログラムが動く前に攻撃が成立すると説明しています。まずは運用担当者に、今回の問題の対象かを確認します。

IPAは10月27日の更新で、2件とも米国の政府機関CISAが公開する悪用確認済みの脆弱性一覧に掲載されたと案内しました。単に攻撃の可能性が指摘されている段階ではなく、悪用が確認された問題として、未対応の環境を優先して確認する必要があります。

対策状況を保守先に確認する

PHPの開発元は、問題を修正したバージョンを公開しています。情シスは、サーバーの運用担当者や保守会社に、自社の環境への適用状況と、残っている作業を確認します。委託している場合も、完了報告を受けます。

古いPHPを使っている場合も、確認が必要です。一部の古い環境には提供元が別途修正を配布しているため、利用している環境に今回の修正が反映されているかを保守先に確認します。更新が難しいという回答の場合は、その理由と、更新までの対策・完了予定を確認します。

2. 一般の事業会社には、どのような影響があるのか

外注したサイトでも、自社の確認対象になる

WordPressの公式要件では、サーバー上での動作にPHPを使用することが示されています。WordPressで企業サイトを運営していれば、社内にPHPの開発者がいなくても、稼働環境の確認が必要です。制作会社に依頼した採用サイトや、事業部が独自に契約したサイトも、運営担当者から保守先へ確認します。

ただし、PHPを使っているという情報だけで、自社が侵害されたとはいえません。利用の有無、修正の適用状況、侵害の有無は分けて確認します。以下は確認先を整理するための例であり、すべての製品やサービスが影響を受けるという意味ではありません。

作業分担は契約やサービス仕様によって異なります。また、ファイアウォール製品への侵害成功を示唆する調査報告や、一部の製品ベンダーによる攻撃観測を紹介しました。Webサイトに加え、PHPを組み込んだ機器・製品も、メーカーの案内と照合します。PHPの更新を機器に直接適用するのではなく、製品向けの対策を確認します。

システムの侵害と、サービス停止による影響を分ける

自社管理のサイトが影響を受ける場合には、不正な処理による情報へのアクセスや改ざんなどを想定して、対策を優先します。問い合わせや申込みを受け付ける機能については、扱う情報と接続先も確認します。

一方、利用する外部サービスが予防的に停止した場合には、自社の端末や情報が侵害されていなくても、受付・販売・社内処理が止まる可能性があります。申込みフォーム停止中の代替窓口や締切への対応も決めます。停止と被害の有無は分けて判断します。

3. 緊急メンテナンスと、利用者側の対応をどう捉えるか

停止したサービスで被害が出たとは限らない

さくらインターネットは10月21日22時30分から、被害を防ぐための緊急メンテナンスを実施しました。その後、10月23日の追記で、今回の対応に伴う緊急メンテナンスはすべて終了したと発表しています。停止の実施だけで、不正アクセスや情報漏洩が発生したとは判断できません。

同社のサポート情報では、レンタルサーバー等の管理画面から選択できるPHPはすべて対応済みとしています。一方、利用者が独自にインストールしたPHPは利用者側での対応が必要です。VPS内で自ら動かすPHPも、確認が必要になります。

10月28日に追加された説明では、古いPHPの一部は修正を組み込んでもバージョン番号が変わらないとされています。「番号が古いから未対応」「提供元が対応したからすべて安全」と判断せず、自社で使うPHPが修正対象に含まれるかを確認します。

WordPressの更新とPHPの修正は別に確認する

WordPressはPHP上で動くソフトウェアであり、管理画面からWordPress本体やプラグインを更新しても、PHP本体の修正が適用されたとは限りません。保守先には、サイトの更新状況に加え、サーバー側のPHPに今回の修正が反映されているかを問い合わせます。

また、PHP開発元は、設定変更による緩和策は特定の攻撃経路を減らすもので、更新の代わりにはならないとしています。一般の事業担当者が設定例を見て独断で変更するのではなく、運用担当者が公式情報と自社構成を照合し、修正までの措置と期限を決めることが必要です。

追加の注意喚起も、対象を分けて確認する

PHP開発元は10月23日、特定の設定とプログラムの組み合わせで生じる別の問題を公表しました。通常の修正版が出るまで、該当する環境では設定変更が推奨されています。10月26日には、Windows向け配布物にも別の問題への修正が追加されました。

情シスは保守先に、最初の2件への更新だけでなく、続報の確認と追加対応の要否も問い合わせます。これらは対象条件が異なるため、すべての環境に同じ追加作業が必要という意味ではありません。

4. 情シスと事業部門が、まず確認すべきこと

対象の洗い出しと保守先への確認をまず行う

情シスは資産台帳や契約一覧を確認し、広報・採用・営業などの各部門は、自部門で管理するサイトやサービスを確認します。一覧の完成を待たず、把握できた公開サイトや重要なシステムから確認します。

確認結果は「影響なし」「修正済み」「対応中」「調査中」などに分けます。「調査中」には担当者と次の報告時刻を付け、未回答のまま放置しないようにします。影響なしという回答にも、PHPを使用していない、対象の修正を適用済みなど、判断の根拠を添えてもらいます。

保守会社やサービス提供元には、次の事項を確認すると整理しやすくなります。

• 対象範囲：どのサイト・サーバー・機能を調べたか
• 対応内容：適用した修正、実施時刻、利用者側に必要な作業
• 完了確認：修正の反映と、必要な再起動・動作確認の状況
• 残る対応：未対応の環境、暫定措置、完了予定と次の報告時刻
• 侵害調査：調べた記録、確認できた事実、確認できない範囲

更新による不具合などのリスクを含めてサービス提供の判断を行う

更新による不具合を避けるため、申込み、ログイン、決済、通知など、そのシステムで重要な機能を運用担当者と確認します。切戻しが必要な場合も、未修正の環境を再公開するリスクを含めて判断します。

すぐに修正できない場合について、IPAは、利用環境に応じた暫定対策やアクセス制限を検討し、有効な措置が難しいときは外部からのアクセス遮断やサービスの一時停止を判断するよう案内しています。事業側は、停止した場合の売上・顧客対応への影響や代替手段を整理し、運用側と対応を決めます。

修正の適用と侵害調査を、別の作業として進める

コンピュータセキュリティインシデントの対応支援を行っているJPCERT/CCは、対策の適用に加えて侵害の有無の調査を求めています。同センターが挙げる確認事項には、異常なリクエストやPHPプロセスの異常終了、不審なファイル・外部通信などがあります。ただし、痕跡が見つからなくても、攻撃を受けていないと断定できないとしています。

事業会社では、技術担当者を筆頭に調査範囲と結果をまとめましょう。侵害が疑われる場合にはログ等を保全し、情報セキュリティ・法務・事業責任者が連携して、隔離や影響調査、関係者への説明を進めます。修正済みという報告と、過去の被害が確認されていないという報告を区別します。

5. 企業の今後の対策として行うこと

システムの実態と、更新を担う責任者を記録する

企業への提言として、システムの一覧には、用途、管理部門、公開範囲、保守先、緊急連絡先、ソフトウェアの更新担当を記録することが有効です。技術構成を事業部が把握できない場合は、回答できる保守先を明確にします。

保守契約でも、コンテンツ更新、WordPressの保守、OSやPHPの保守を区別します。緊急時の調査、修正作業、動作確認、報告が契約に含まれるかを確認し、担当が空白になる部分をなくします。更新費用やテスト環境も平時から準備します。

サービス提供の判断条件を定める

脆弱性への対応は、情シスだけで完結するとは限りません。技術担当は危険性と対処方法を、事業担当は停止時の影響と代替手段を示し、責任者が対応方針を決める役割分担を設けます。夜間や休日にも判断をつなげられる連絡経路が必要です。

対応を終える条件には、対象環境への修正の反映、主要機能の動作確認、必要な侵害調査、残課題の引継ぎを含めます。すべてを同時に完了できない場合は、未完了事項・担当者・期限を明示します。保守先から「対応しました」と連絡を受けるだけでなく、対象と結果を記録して確認できる状態を目指します。

6. まとめ

PHPの脆弱性の対応で、一般の事業会社が最初に行うべきことは、自社や委託先のシステムでPHPを使っているか、誰が修正を適用するかを確認することです。自社で開発していなくなくても、Webサイトの稼働環境や利用サービスを通じて関係する可能性があります。

企業としては、修正の適用、侵害の有無、サービス提供の停止への対応を分けて整理します。そのうえで、保守先への依頼と完了確認、更新が難しい場合の暫定措置や停止判断を進めます。今回を機に、資産・委託先・判断責任・対応記録を整えることが、次の重大脆弱性にも対応できる体制づくりにつながります。

▶ [AIガバナンス支援サービスの詳細・お問い合わせはこちら] 

参考文献

• The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）。公式アドバイザリ
• IPA「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」（2026年10月22日公開、10月27日更新）。注意喚起
• JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」（2026年10月22日公開、10月29日更新）。注意喚起
• さくらインターネット「【重要】PHPの脆弱性に関する当社の対応状況について」（2026年10月22日公開、10月23日追記）。対応状況
• The PHP Group「Informational advisory: Session upload progress」（2026年10月23日）。追加アドバイザリ
• The PHP Group「Updated PHP Windows builds for Brotli security fix」（2026年10月26日）。公式発表
• さくらインターネット「PHPの脆弱性（CVE-2026-109618、CVE-2026-109619）への対応状況について」（2026年10月22日公開、10月28日更新）。サポート情報
• WordPress.org 日本語「必須要件」。公式要件