PHPの脆弱性を狙うサイバー攻撃とは?AIを悪用した攻撃と情報漏洩対策

2026年10月21日夜、高市早苗首相が、PHPの重大な脆弱性への緊急対応を呼びかけました。
首相は自身の公式Xアカウントで、PHPを利用しているWebサイトの管理者に対し、修正プログラムをできる限り速やかに適用できるよう準備することを要請。適用が難しい場合には、Webサイトを一時的に停止することも、サイバー攻撃のリスクを低減する有効な手段だと説明しました。

今回問題となったのは、PHPに見つかった2件の重大な脆弱性です。悪用された場合、外部の第三者がサーバー上で不正なコードを実行し、Webサイトの改ざんや情報漏洩、システムの乗っ取りなどを引き起こすおそれがあります。翌22日には、官公庁や企業などでも緊急点検やサービスの一時停止が相次ぎ、対策が広がりました。

なぜ、首相自らが緊急の注意喚起を行うほど、今回の脆弱性は重大なのでしょうか。
PHPの脆弱性がサイバー攻撃につながる仕組みや、AIによる脆弱性発見・攻撃の高度化、企業が取るべき緊急対応と再発防止策について、実際の公表情報を交えながら解説します。


目次

PHPの脆弱性問題とは?企業が注意すべきサイバー攻撃のリスク

企業のWebサイトや業務システムを狙うサイバー攻撃では、ソフトウェアに存在する「脆弱性」が侵入の足掛かりになることがあります。PHP(ピーエイチピー)も、こうした攻撃の対象となるソフトウェアの一つです。

PHPは、WebサイトやWebアプリケーションを動かすために広く利用されているプログラミング言語です。企業のコーポレートサイト、問い合わせフォーム、会員向けサービス、ECサイトなどにも使われています。
2026年10月には、PHPにおいて、認証されていない第三者が条件次第で遠隔から任意のコードを実行できる重大な脆弱性が公表されました。脆弱性を悪用されると、Webサイトの改ざんやサーバーの不正操作、情報漏洩などにつながるおそれがあります。

同年10月21日には財務省が、PHPの脆弱性への対応に伴い、Webサイトの一部コンテンツやサービスを一時停止すると発表しました。影響を受ける可能性があるシステムを特定し、修正プログラムを適用するとともに、不正アクセスの有無を調査することが重要です。



1. PHPの脆弱性とは何か

PHPはWebサイトや業務システムを動かすプログラミング言語

PHPは、Webサーバー側で動作するプログラミング言語です。利用者がWebサイトを閲覧した際に、入力された情報を処理したり、データベースから必要な情報を取得したりして、画面に表示する内容を生成します。
企業のWebサイトにある問い合わせフォームでは、利用者が入力した氏名やメールアドレス、問い合わせ内容を受け取り、処理する仕組みにPHPが使われている場合があります。
WordPressなどのコンテンツ管理システム(CMS)にもPHPが使われています。CMSとは、専門的なプログラミング知識がなくても、Webサイトの記事や画像などを管理できる仕組みです。

PHPは、企業の情報発信や顧客対応を支える重要な技術の一つですが、PHPそのものや、PHPを利用するアプリケーションに問題があると、Webサイトの運営だけでなく、企業の情報資産にも影響が及ぶ可能性があります。


脆弱性とは、攻撃者に悪用される可能性がある弱点

脆弱性とは、ソフトウェアやシステムに存在する、セキュリティー上の弱点を指します。
プログラムの設計や実装に不備があると、本来は許可されていない操作を第三者が実行できる場合があります。こうした弱点が攻撃に利用されることで、不正アクセスや情報漏洩などの被害が発生します。
PHPの脆弱性の場合、例えば次のようなリスクが考えられます。

  • 不正なコードの実行: 攻撃者がサーバー上で意図しないプログラムを実行する。
  • Webサイトの改ざん: 正規のページを変更し、偽の情報や不正なリンクを表示する。
  • 情報漏洩: サーバーやアプリケーションが扱う顧客情報、業務データなどが外部に流出する。
  • システムへの侵入: Webサーバーを足掛かりとして、社内ネットワークや関連システムへの侵入を試みる。
  • サービス停止: サーバーの異常動作や攻撃への緊急対応によって、Webサービスが利用できなくなる。

これらは脆弱性を悪用された場合に起こり得る被害です。すべての脆弱性で、必ずすべての被害が発生するわけではありません。重要なのは、脆弱性が存在するかどうかだけでなく、対象のシステムが外部からアクセスできる状態にあるか、どのような情報を扱っているか、侵入後にどこまで操作できるかを把握することです。


PHPの脆弱性が企業にとって重大な理由

PHPの脆弱性が企業にとって重大なのは、Webサイトが単なる情報発信の場ではなく、顧客や取引先との接点になっているためです。問い合わせフォームが攻撃を受けた場合、フォーム自体の停止にとどまらず、関連するデータベースやメール送信機能などにも影響が及ぶ可能性があります。
さらに、Webサーバーと社内システムのネットワークが適切に分離されていなければ、Webサイトへの侵入を起点として被害が広がることも考えられます。
被害が発生した場合、企業には次のような影響が生じる可能性があります。

  • 顧客情報や取引先情報の漏洩による信用の低下
  • Webサイトやオンラインサービスの停止による売上・業務への影響
  • 原因調査、システム復旧、外部専門家への依頼に伴う費用
  • 顧客や取引先への説明、問い合わせ対応などの業務負担
  • 法令や契約に基づく報告・通知などへの対応

PHPの脆弱性問題は、情報システム部門だけの技術的な課題ではありません。事業継続、顧客対応、経営上のリスク管理にも関わる問題です。

あわせて読みたい
AIによるサイバー攻撃の高度化、自動化で何が変わる?2026年の情報漏洩事例から考える企業の緊急対策 2026年、企業の情報漏洩は「どこまで被害が広がるか」 2026年、企業の情報漏洩をめぐる状況は深刻さを増しています。攻撃者がAI(人工知能)を活用することで、攻撃対象...

2. 2026年10月に公表されたPHPの重大な脆弱性

CVE-2026-109618、CVE-2026-109619とは

2026年10月21日、PHPの開発チームは、重大な脆弱性2件に対応するセキュリティー更新を公開しました。対象となる脆弱性には、次の識別番号が付けられています。

  • CVE-2026-109618: メモリ不足時の処理に起因するメモリ破損を通じて、任意のコード実行につながる可能性がある脆弱性
  • CVE-2026-109619: 解放済みのメモリに関連する古い内部状態が残る問題を通じて、任意のコード実行につながる可能性がある脆弱性

CVE(Common Vulnerabilities and Exposures)とは、公開された脆弱性に一意の識別番号を付ける仕組みです。脆弱性情報を製品や組織の間で正確に共有するために使われます。Google CloudとWizの調査報告によると、これらの脆弱性はCVSS v4.0でいずれも9.2と評価されました。CVSSは、脆弱性の深刻度を数値化する指標です。

今回の問題では、条件次第で、利用者の認証を必要とせずに遠隔からコードを実行される可能性があります。認証とは、利用者が正当な権限を持つ本人であることを確認する仕組みで、通常、業務システムではログインやアクセス権限によって操作できる範囲を制限します。しかし、認証前の処理に重大な欠陥がある場合、ログイン画面を突破することなく攻撃が成立する可能性があります。
この点が、企業のセキュリティー担当者にとって重要な注意点です。

参照:Google Cloud「Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619」

脆弱性の仕組みをわかりやすく解説

今回の脆弱性を理解するには、PHPがサーバー上でプログラムを実行する際に、メモリを使って処理を進めることを知っておくと役立ちます。
メモリとは、コンピューターが処理中の情報を一時的に保存する領域です。CVE-2026-109618では、メモリが不足した際の処理が問題になります。メモリ不足が発生すると、プログラムは処理を中断したり、使用していた情報を整理したりします。しかし、その途中で内部データの状態が不整合になると、本来とは異なる処理が実行される可能性があります。
CVE-2026-109619では、解放されたメモリに関連する内部状態が残り、後続の処理で誤って利用されることが問題となります。これらの問題を攻撃者が悪用すると、PHPの実行プロセスに不正な処理を行わせる可能性があります。任意のコード実行とは、攻撃者が意図した命令を対象システム上で実行させることです。

サーバー上でコード実行が成立した場合、実行権限やシステム構成によっては、ファイルの読み取りや変更、不正なプログラムの設置、外部への通信などにつながるおそれがあります。
コード実行が可能になったからといって、直ちにサーバー全体やすべての顧客情報が侵害されるわけではありません。実際の被害範囲は、サーバーの権限設定、ネットワーク分離、保存データへのアクセス制御などに左右されます。

影響を受けるPHPのバージョン

2026年10月22日付のJPCERT/CCの注意喚起では、今回の脆弱性について、次の修正済みバージョンが案内されています。

PHPの系列修正済みバージョン
PHP 8.5系8.5.12以降
PHP 8.4系8.4.27以降
PHP 8.3系8.3.36以降
PHP 8.2系8.2.35以降

上記のバージョンより前のPHP 8.2~8.5系が対象となります。また、PHP 8.1以前についても影響を受ける可能性がありますが、サポート終了により通常の修正更新が提供されない系列があります。
サポート終了とは、ソフトウェアの開発元が通常の保守やセキュリティー修正を提供しなくなる状態です。古いPHPを使い続けている場合、今回の脆弱性だけでなく、今後発見される別の脆弱性にも対応できなくなるおそれがあります。

なお、PHPを直接インストールしていなくても、CMSや業務ソフトウェア、サーバー製品などの内部でPHPが使われている場合があります。自社でPHPの利用を把握できていない場合は、製品の提供元にも確認する必要があります。

参照:JPCERT/CC「PHPにおける複数の脆弱性(CVE-2026-109618、CVE-2026-109619)に関する注意喚起」


政府がホワイトハッカーの専門チームを設置へ AIを活用した模擬攻撃で企業の防御力強化を目指す

2026年10月23日、経済産業省は、サイバー攻撃への対応力を高めるため、ホワイトハッカーらで構成する専門チームを11月中に情報処理推進機構(IPA)に設置する方針を明らかにしました。日テレNEWS NNNの報道(ライブドアニュース掲載)によると、攻撃者の視点を取り入れながらシステムの弱点を発見し、企業のセキュリティー対策を支援することを目指しています。

ホワイトハッカーとは、サイバーセキュリティーの専門知識を持ち、システムの脆弱性を発見して改善につなげる技術者です。今回の構想では、高性能なAIを活用して模擬的なサイバー攻撃を実施し、企業のシステムに潜む弱点を事前に把握する取り組みが検討されています。攻撃者が脆弱性を悪用する前に問題を発見し、防御策を講じることが狙いです。Reutersの報道(2026年10月23日)でも、AIを活用した攻撃シミュレーションによってシステムの弱点を特定する政府の方針が伝えられています。

PHPは多くのWebサイトや業務システムで利用されているプログラミング言語で、脆弱性を悪用されると、不正アクセスや情報漏洩などの被害につながるおそれがあります。今回の問題では、政府機関や民間企業がWebサイトや一部サービスを予防的に停止するなど、影響を抑えるための対応を進めました。

AIは脆弱性の発見や攻撃の自動化を効率化する一方、防御側にとっても、攻撃を想定した検証や対策の優先順位付けを支援する技術となります。政府の専門チーム設置により、企業、とりわけセキュリティー人材や対策予算が限られる中小企業の防御力向上につながるかが注目されます。

あわせて読みたい
サイバー攻撃の高度化――セキュリティー対策、企業は何をすればいい? セキュリティー対策、万全ですか? セキュリティー対策、結局のところ企業は何をすればいい? 近年、サイバー攻撃は急速に高度化、巧妙化しています。「サイバー攻撃対...




3. PHPの脆弱性を突いたサイバー攻撃の特徴

特徴1:インターネットから直接攻撃される可能性がある

企業のWebサイトやWebアプリケーションは、利用者がアクセスできるよう、インターネットに公開されていることが一般的です。そのため、攻撃者は社内ネットワークに直接接続できなくても、外部から公開サーバーにアクセスし、脆弱性が存在するかどうかを調べることができます。

こうした攻撃では、攻撃者が対象企業を一社ずつ調査するとは限りません。自動化されたプログラムで多数のサーバーを調べ、条件に合うシステムを探す手法もあります。企業の知名度や規模にかかわらず、脆弱性を放置したサーバーが攻撃対象になる可能性があります。

特徴2:修正プログラムが公開された後も攻撃される

脆弱性が発見されると、開発元は問題を修正したプログラムを公開します。こうした修正プログラムは、一般にパッチと呼ばれます。しかし、パッチの公開によって攻撃の危険が直ちになくなるわけではありません。
攻撃者も公開された情報を確認し、どのバージョンに問題があるのか、どのような条件で脆弱性が悪用できるのかを調査することがあります。

修正済みバージョンと脆弱なバージョンの違いを調べ、攻撃に利用する手法を分析することを、リバースエンジニアリングと呼びます。攻撃者が脆弱性の仕組みを理解すれば、インターネット上から該当するバージョンのサーバーを探し、攻撃を試みる可能性があります。
修正プログラムが公開された際には、影響を受けるシステムを特定し、優先順位を付けて速やかに適用することが重要です。

特徴3:侵入後に別の攻撃へ発展することがある

PHPの脆弱性を悪用した攻撃では、Webサーバーへの侵入が最終目的とは限りません。
侵入後にWebシェルと呼ばれる不正なプログラムを設置されると、攻撃者がサーバーに対して追加の命令を送れる状態になる場合があります。
Webシェルとは、Web経由でサーバーの操作を可能にするプログラムです。正規の管理機能とは異なり、攻撃者が不正に設置したWebシェルは、侵入後の操作や不正アクセスの継続に使われることがあります。
さらに、侵入したサーバーを別の攻撃の中継地点として利用される可能性もあります。これを踏み台として悪用する、と表現します。

こうした状況では、Webサイトを修正しただけでは十分ではありません。不正なファイルが残っていないか、見慣れないプロセスが実行されていないか、外部との不審な通信が発生していないかなども調査する必要があります。

参照:IPA「PHPの脆弱性(CVE-2024-4577)を狙う攻撃について」


4. AIはPHPの脆弱性問題にどう関わるのか

2026年のPHPの脆弱性問題で注目された点の一つが、AIを活用した脆弱性の発見です。
Google CloudとWizの2026年10月21日の報告では、Wizの調査においてAIモデルが脆弱性の発見や攻撃手法の検証、検知方法の検討、修正内容の検証に貢献したと説明されています。
AIは、サイバー攻撃を防ぐためにも使われていますが、攻撃者が悪用できる技術を調査する際にも利用される可能性があります。
ここでは、AIがどのように関わるのかを整理します。

AIによって脆弱性の発見が効率化される

従来、ソフトウェアの脆弱性を見つけるには、プログラムの構造や処理の流れを詳しく分析し、問題が起こる条件を検証する必要がありました。AIを活用すると、ソースコードの分析や、異常な動作が発生する条件の洗い出し、テストケースの作成などを支援できます。
ソースコードとは、プログラムの動作を記述した命令文です。AIはその内容を分析し、処理の不整合や、想定外の入力に対する弱点を発見する手掛かりを提示できます。もちろん、AIが指摘した問題がすべて実際の脆弱性とは限りません。誤検知が発生する場合もあるため、専門家による検証が必要です。
それでも、これまで人手で時間をかけていた分析を効率化できれば、脆弱性の発見や修正のスピードが上がる可能性があります。

AIが攻撃の準備や自動化に利用される可能性

AIの活用は、防御側だけに限られません。攻撃者がAIを利用すると、公開された脆弱性情報の整理、攻撃対象の選定、プログラムの分析などを効率化できる可能性があります。公開情報から影響を受けるソフトウェアのバージョンを整理し、調査対象を絞り込む作業をAIで支援することが考えられます。

また、攻撃の準備に必要な作業を自動化することで、少ない人数でも多数のシステムを調査できる可能性があります。AIを使ったからといって、すべての攻撃が成功するわけではありません。攻撃の成立には、脆弱性の条件、サーバーの設定、アクセス制御などが影響します。
重要なのは、AIによって攻撃に必要な調査や分析の負担が軽減され、攻撃の準備が効率化する可能性を踏まえ、企業側も対応を迅速化することです。

AIが防御側にもたらすメリット

AIは、企業のセキュリティー対策にも役立ちます。例えば、次のような用途が考えられます。

  • 大量のログから不審なアクセスの傾向を見つける
  • 脆弱性情報と自社のソフトウェア資産を照合する
  • 不審なプログラムや通信の特徴を分析する
  • インシデント発生時に調査すべき項目を整理する
  • セキュリティー担当者向けの報告書や対応手順の作成を支援する

ログとは、システムやアプリケーションの操作、アクセス、エラーなどの記録です。大量のログを人手だけで確認するには時間がかかるため、AIを使った分析は調査の補助として有効な場合があります。
AIの判断だけで攻撃の有無を確定したり、システムの復旧を判断したりするのは適切ではありません。誤った判定や見落としが発生する可能性があるため、最終的には担当者が確認する必要があります。

また、顧客情報や社内の機密データを外部のAIサービスに入力する場合は、情報管理上のリスクにも注意が必要です。利用するサービスの契約条件、データの保存方針、アクセス権限などを確認しなければなりません。
AIを導入すること自体を目的にするのではなく、資産管理、脆弱性の修正、ログ監視、インシデント対応といった基本的な対策を支える手段として活用することが重要です。

参照:Google Cloud「Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619」


5. PHPの脆弱性に関連する事例と企業の対応

PHPの脆弱性問題を理解するには、実際にどのような対応が行われたのかを確認することが役立ちます。
ここでは、2024年に国内組織への被害が確認された事例と、2026年に公表された重大な脆弱性への対応を紹介します。なお、Webサイトの一時停止や不正プログラムの設置が確認されたことと、顧客情報の漏洩が確認されたことは区別する必要があります。

事例1:2024年7月5日、IPAが国内複数組織での脆弱性悪用事例を公表

2024年7月5日、独立行政法人情報処理推進機構(IPA)は、PHPの脆弱性「CVE-2024-4577」を悪用した攻撃について注意喚起を公表しました。この脆弱性は、特定の条件下でWindows上のPHP-CGIに影響し、攻撃者がサーバー上で任意のコードを実行できる可能性があるものでした。
PHP-CGIとは、Webサーバーからの要求に応じてPHPのプログラムを実行する方式の一つです。特定のWindows環境で文字の扱いに問題があり、細工された入力によって本来とは異なるコマンド処理が行われる可能性がありました。IPAの公表では、国内の複数組織において、この脆弱性が悪用され、対象のWebサービスにWebシェルが設置されていたとの指摘が紹介されています。
これは、脆弱性が理論上の問題にとどまらず、実際の攻撃に利用されていたことを示す事例です。

一方、IPAの当該公表資料では、被害組織の企業名や、個人情報の漏洩件数などは具体的に明らかにされていません。そのため、この事例を根拠に、特定企業から顧客情報が漏洩したと断定することはできません。この事例から学べるのは、修正プログラムを適用するだけでなく、すでに侵入されていないかを調査する必要があるという点です。
IPAは、PHPの更新に加え、通信ログなどを確認し、攻撃被害の有無を調査するよう呼びかけています。

参照:IPA「PHPの脆弱性(CVE-2024-4577)を狙う攻撃について」

事例2:2026年10月21日、財務省がWebサイトの一部を一時停止

2026年10月21日、財務省は、PHPの重大な脆弱性への対応に伴い、Webサイトの一部コンテンツやサービスを一時停止していると発表しました。公表内容によると、財務省はセキュリティー確保と情報資産の保護を目的として、管理下のWebサーバーや関連システムの緊急点検、修正プログラムの適用を進めました。また、対象となる可能性のあるコンテンツとして、PHPで動作するWebコンテンツを挙げています。

この対応は、脆弱性を悪用されたことが確認されてから被害を復旧するのではなく、危険性を踏まえてシステムの点検や修正を進める予防的な対応として理解できます。企業にとっても、脆弱性が公表された段階で、サービスを通常どおり稼働させ続けるべきかを判断することは重要です。
修正プログラムをすぐに適用できず、外部からの攻撃を防ぐ手段も十分に確保できない場合には、対象サービスの一時停止やネットワークからの隔離を検討する必要があります。
ただし、財務省の当該発表は、脆弱性対応のために一部コンテンツなどを停止したことを説明するものであり、この発表だけで財務省から情報が漏洩したと判断することはできません。

参照:財務省「PHPの脆弱性対応に伴うWebサイト・一部コンテンツの一時停止のお知らせ」

事例3:2026年10月21日、AIを活用した脆弱性の発見と緊急更新

2026年10月21日には、PHPの開発チームが重大な脆弱性2件を修正する更新を公開しました。Google CloudとWizは、AIを活用した調査が今回の脆弱性の発見や検証に貢献したと説明しています。
脆弱性の詳細が公開されると、修正されていないシステムを攻撃者が調査する可能性もあります。実際に、Amazonのセキュリティー部門は、10月17日に自社の囮(おとり)システムで今回の脆弱性を悪用しようとする試みを検知したと報告しています。
囮システムとは、攻撃者の活動を観察するために設置する、実際の業務システムとは区別された仕組みです。Amazonが検知したのは囮システムへの攻撃の試みで、これをもってAmazonの顧客情報が漏洩したと判断することはできません。また、この試みが実際のWebサイトに対して成功していたかどうかについても、同報告では明確に確認されていません。

この事例は、脆弱性の公表前後から攻撃の試みが発生する可能性を示しています。企業は、脆弱性が公表されてから対応手順を検討するのではなく、平時からソフトウェア資産の把握、更新作業の手順、緊急時の判断体制を整えておく必要があります。

参照:The PHP Group「PHP security release information」、Google Cloudの技術解説


あわせて読みたい
業務の「リスク管理」「BCP対策」は万全ですか?企業が備えておきたいリスクと対策を解説 企業における「リスク管理」「BCP対策」とは 「災害が起きたとき、業務を継続できるだろうか」「システムや通信が止まった場合、誰がどのように対応するのか決まってい...




6. 現状の被害状況と、企業が理解しておくべきこと

PHPの脆弱性に関する報道では、攻撃の試み、脆弱性を悪用された疑い、実際の侵入、情報漏洩など、異なる段階の情報が扱われます。
企業が状況を判断する際には、それぞれを区別することが重要です。

状況意味企業が確認すべきこと
脆弱性が公表されたソフトウェアに弱点があると判明した自社の対象バージョンや利用製品
攻撃の試みが観測された攻撃者が脆弱性の悪用などを試みた自社へのアクセス履歴や攻撃の痕跡
不正アクセスが確認された第三者による不正な操作や侵入が確認された侵入経路、権限、影響範囲
情報漏洩が確認された情報が外部へ流出したことが確認された対象データ、件数、通知・報告の要否

2026年10月のPHPの重大な脆弱性については、修正プログラムが公開され、国内でも公的機関による注意喚起やWebサイトの一時停止などの対応が行われています。
紹介した財務省の公表は予防的なシステム対応についてのものであり、IPAが2024年に公表した事例についても、具体的な企業名や情報漏洩件数は明らかにされていません。したがって、公開情報から確認できる事実と、可能性として指摘されているリスクを分けて理解する必要があります。

また、自社のサーバーが攻撃を受けていないことを、単に目立った障害がないという理由だけで判断するのは危険です。攻撃者が不正なファイルを設置していたり、目立たない形で情報を取得していたりする可能性もあるためです。
PHPの更新とあわせて、アクセスログ、サーバー上のファイル、実行中のプロセス、外部通信などを確認し、侵害の有無を調査することが重要です。


7. 企業が実施すべきPHPの脆弱性対策

PHPの脆弱性による被害を防ぐには、脆弱性情報を把握し、修正プログラムを適用するだけでなく、攻撃を受けた場合の影響を抑える仕組みを整える必要があります。
ここでは、企業が取り組むべき対策を具体的に紹介します。

対策1:PHPを利用しているシステムを把握する

最初に取り組むべきなのは、自社でPHPを利用しているシステムを洗い出すことです。対象は、社内で開発したシステムだけではありません。外部の制作会社に構築を依頼したWebサイト、レンタルサーバー上のCMS、クラウドサービス、業務ソフトウェアなども含まれます。
特に注意したいのは、担当者がPHPを使っていることを把握していないシステムです。Webサイトの制作を外部企業に委託している場合、運用担当者がPHPのバージョンを知らないことがあります。また、サーバーの管理をホスティング事業者に任せている場合、自社側で直接更新できないこともあります。
まずは、次の情報を整理しましょう。

  • WebサイトやWebアプリケーションの一覧
  • PHPのバージョンと実行環境
  • サーバーの管理者と保守委託先
  • 外部公開の有無
  • 問い合わせ情報や顧客情報など、扱っているデータ
  • 更新作業の担当者と連絡先

すべての情報を一度に把握できなくても、外部公開されているシステムから優先的に確認することが重要です。

対策2:修正プログラムを速やかに適用する

脆弱性の影響を受けるPHPを利用している場合は、開発元が案内する修正済みバージョンへの更新を進めます。
2026年10月の脆弱性については、JPCERT/CCなどの注意喚起と、PHPの公式情報を確認し、対象バージョンや修正内容を把握する必要があります。
更新の際には、次の点に注意します。

  1. 利用中のPHPのバージョンを確認する。
  2. サーバーやCMSなどの構成を確認する。
  3. 修正済みバージョンへの更新計画を立てる。
  4. 可能な範囲でテスト環境を使い、動作への影響を確認する。
  5. 更新後に、Webサイトや業務機能が正常に動作するか確認する。

ただし、深刻な脆弱性では、通常の更新計画だけでは対応が遅れることがあります。緊急性を踏まえ、テストと適用の優先順位を判断する必要があります。
また、PHP 8.1以前などのサポートが終了したバージョンを利用している場合は、単に古いバージョンのまま使い続けるのではなく、サポートされている系列への移行を検討しましょう。

対策3:更新できない場合は公開範囲を制限する

業務システムの都合で、修正プログラムをすぐに適用できない場合もあります。古いシステムとの互換性や、更新による業務停止への懸念から、更新に時間がかかるケースです。しかし、深刻な脆弱性を抱えた状態で、外部公開を続けることにはリスクがあります。
すぐに更新できない場合は、次のような対応を検討します。

  • 対象のWebサイトやサービスを一時停止する
  • インターネットからのアクセスを制限する
  • 必要な利用者や接続元だけにアクセスを限定する
  • Webサーバーを社内ネットワークから分離する
  • ベンダーが案内する緩和策を適用する

緩和策とは、脆弱性そのものを修正できない場合に、攻撃が成立しにくい状態にするための暫定的な対策です。
緩和策は修正プログラムの適用と同じではありません。今回のPHPの脆弱性についても、JPCERT/CCは修正済みバージョンへの更新を推奨しています。
事業への影響を理由に対策を先送りするのではなく、セキュリティー上の危険性と業務への影響を比較し、経営層を含めて判断することが重要です。

対策4:侵入の痕跡を調査する

修正プログラムを適用しても、過去に侵入されていた場合、不正なファイルや設定が残っている可能性があります。そのため、脆弱性への対応では、更新作業と侵害調査を並行して進める必要があります。
具体的には、次のような点を確認します。

  • Webサーバーへのアクセスログに不審な要求がないか
  • 見覚えのないPHPファイルや実行ファイルが設置されていないか
  • 不審なプロセスやスケジュールされた処理が存在しないか
  • サーバーから未知の外部接続先への通信が発生していないか
  • 不正なアカウントやアクセス権限の変更がないか
  • データベースへの不自然なアクセスやデータの持ち出しがないか

調査で不審な点が見つかった場合は、証拠となるログやファイルの情報を保全し、必要に応じて専門家に調査を依頼します。侵入が疑われる場合、安易にファイルを削除したり、サーバーを初期化したりすると、原因究明に必要な証拠を失う可能性があります。復旧作業を始める前に、証拠保全と調査の進め方を検討しましょう。

対策5:サーバーの権限とネットワークを見直す

脆弱性を完全になくすことは難しいため、仮に侵入されたとしても被害を広げない仕組みが必要です。Webサーバーが必要以上に強い権限を持っていると、攻撃者がその権限を利用して、重要なファイルやデータベースにアクセスできる可能性があります。
こうしたリスクを抑えるために、次のような対策を実施します。

  • Webサーバーの実行権限を必要最小限にする
  • 顧客情報を保存するデータベースへのアクセスを制限する
  • Webサーバーと社内ネットワークを適切に分離する
  • 管理画面へのアクセスを制限する
  • 多要素認証などを利用して管理者アカウントを保護する
  • バックアップを定期的に取得し、復旧できることを確認する

多要素認証とは、パスワードだけでなく、スマートフォンでの認証など、複数の方法を組み合わせて本人確認を行う仕組みです。
これらの対策はPHPだけでなく、他のソフトウェアの脆弱性を悪用した攻撃にも役立ちます。

対策6:緊急時の対応体制を整える

脆弱性が公表された際、誰が影響を確認し、誰が更新を判断し、誰が顧客や取引先への説明を担当するのかが不明確だと、対応が遅れる原因になります。企業では、平時から次の役割を整理しておくことが重要です。

  • 情報システム部門:対象システムの特定、更新、技術調査
  • システム運用担当者:サービスの稼働状況確認、ログ保全
  • 経営層・管理職:業務停止や復旧に関する重要な判断
  • 総務・法務など:社内外への連絡、報告義務の確認
  • 営業・顧客対応部門:顧客や取引先からの問い合わせへの対応
  • 外部の保守会社:サーバーやアプリケーションの調査・修正支援

役割分担を決めるだけでなく、連絡先、判断基準、緊急時の作業手順も整備しておきましょう。
情報漏洩の疑いがある場合には、個人情報保護法上の報告・本人通知などが必要になるケースもあります。具体的な義務は、漏洩した情報の種類や状況などによって異なるため、個人情報保護委員会の公表資料や専門家の助言を確認することが重要です。

参照:個人情報保護委員会


8. 自社の場合はどうすべきか?確認したいチェックリスト

PHPの脆弱性への対応では、自社のシステム構成や業務への影響を踏まえて、優先順位を決める必要があります。
以下のチェックリストを使い、自社の状況を確認してみましょう。

まず確認したい項目

  • 自社が運営するWebサイトやWebアプリケーションを一覧化している
  • 利用しているPHPのバージョンを把握している
  • CMSや外部委託先のシステムについても確認している
  • 外部公開されているサーバーを把握している
  • 修正プログラムを適用する担当者と手順が決まっている
  • 不審なアクセスやファイルを調査できる体制がある
  • バックアップから復旧できることを確認している
  • 情報漏洩が疑われる場合の連絡・報告手順を整備している

状況別に考える対応方針

PHPの利用状況が分からない場合

まずはWebサイトの管理会社、サーバーの保守会社、CMSの提供元に確認します。自社で管理できるシステムから順に、利用製品とバージョンを整理しましょう。

影響を受けるバージョンを利用している場合

開発元やJPCERT/CCの情報を確認し、修正済みバージョンへの更新を優先します。外部公開されているシステムや、顧客情報を扱うシステムは、特に優先度を高く設定することが重要です。

更新したが、攻撃を受けていないか分からない場合

アクセスログや不審なファイル、プロセス、外部通信などを確認します。更新したことだけを理由に、安全が確保されたと判断しないようにしましょう。

不正アクセスの疑いがある場合

証拠となるログなどを保全し、必要に応じて対象システムを隔離します。社内のインシデント対応責任者や外部の専門家と連携し、影響範囲の調査と復旧を進めます。

なお、単一のログや検知ルールで、すべての攻撃を発見できるわけではありません。不審な痕跡が見つからない場合でも、システム構成やログの保存状況によっては、侵害がなかったと断定できないことに注意が必要です。

9. まとめ:PHPの脆弱性対策は、更新と侵害調査をセットで考える

PHPは、多くのWebサイトや業務システムを支えるプログラミング言語です。そのため、PHPの重大な脆弱性が公表されると、企業のWebサイトだけでなく、顧客対応や業務の継続にも影響が及ぶ可能性があります。
2026年10月に公表されたCVE-2026-109618とCVE-2026-109619は、条件次第で認証されていない第三者による遠隔コード実行につながる重大な脆弱性です。国内では財務省が一部コンテンツなどを一時停止し、点検と修正プログラムの適用を進める対応を公表しました。

また、AIは脆弱性の発見や検証を効率化する一方、攻撃者による調査や攻撃準備にも利用される可能性があります。企業には、脆弱性情報を迅速に把握し、必要な対応を進める体制が求められます。
自社が取り組むべき対策は、次の5点に整理できます。

  1. PHPを利用しているシステムとバージョンを把握する。
  2. 開発元の情報を確認し、修正プログラムを速やかに適用する。
  3. 更新できない場合は、サービスの一時停止やアクセス制限を検討する。
  4. 更新と並行して、不正アクセスや情報漏洩の有無を調査する。
  5. 経営層、情報システム部門、総務、営業などが連携できる対応体制を整える。

セキュリティー対策は、特定のソフトウェアを更新すれば終わるものではありません。自社の情報資産を把握し、脆弱性が発見された際に速やかに対応できる仕組みを整えることが重要です。
PHPの脆弱性問題を、自社のソフトウェア管理やインシデント対応体制を見直す機会として捉え、継続的なセキュリティー対策につなげていきましょう。


参考情報


あわせて読みたい
【セキュリティー対策の見直しを】増加するサイバー攻撃に備えるネットワーク対策とは?│LG1500AP│セキ... 企業を狙ったサイバー攻撃や情報漏洩が相次いでおり、企業規模を問わず、セキュリティー対策の見直しが重要になっています。特に、AIを活用した攻撃手法の高度化や、ソ...





【最新記事】

  • URLをコピーしました!
目次