Info

PHPの重大なセキュリティ脆弱性に関するよくあるご質問の公開

2026年10月20日、PHPの開発・保守を担うPHP Security Teamより、重大なセキュリティ脆弱性2件への対応を目的とした緊急アップデートが予告されました。

翌21日には、認証されていない第三者によるリモートコード実行(RCE)につながる可能性があることが正式に発表され、修正版のPHPが公開されました。

今回報告された脆弱性は以下の2件です。

  • CVE-2026-109618:メモリ不足(OOM)の処理に起因する脆弱性
  • CVE-2026-109619:解放済みメモリに関連する内部状態の不適切な管理に起因する脆弱性

いずれも、国際的な脆弱性評価指標であるCVSS v4.0において「9.2(Critical)」と評価されています。

今回の問題は、多くのWebサイトやシステムの動作基盤となっているPHP自体に存在するため、広範な影響が懸念されています。

本FAQでは、今回の脆弱性に関して想定されるご質問について、PHP公式や公的なセキュリティ機関の情報に基づいてご説明します。

なお、以下は2026年10月22日時点で公表されている情報に基づくものであり、個別のWebサイトやサーバーの安全性を保証するものではありません。


PHPと今回の脆弱性について

Q. PHPとは何ですか?

PHPは、WebサイトやWebシステムを動かすために広く利用されている、サーバー側のプログラミング言語です。

Webサイトを閲覧する際、ブラウザから送信されたリクエストをサーバーが受け取り、必要に応じてPHPが処理を実行することで、ページの内容が生成・表示されます。

今回の脆弱性は、このPHPの内部処理に存在する問題です。

そのため、PHPを利用するWebサイトや業務システムが影響を受ける可能性があります。

Q. 今回の脆弱性では、どのような攻撃が成立する可能性がありますか?

今回報告された2件は、リモートコード実行(RCE:Remote Code Execution)につながる可能性がある脆弱性です。

RCEとは、攻撃者がネットワークを通じて、対象のコンピューターやサーバー上で、本来許可されていないコードを実行できる状態を指します。

今回の問題は、PHPがWebリクエストを処理する際のメモリ管理や内部状態の取り扱いに起因しています。

攻撃者が特殊なHTTPリクエストを送信することで、PHP内部の処理に異常を発生させ、不正なコードの実行につなげる可能性があります。

特に重大なのは、今回のRCEが認証を必要としない点です。

例えば、WordPressなどの管理画面にログインする権限を持たない第三者でも、一定の条件下で攻撃を成立させる可能性があります。

また、PHP公式は、Apacheのmod_php環境において、アプリケーションのコードが実行される前に攻撃が成立する経路を確認しています。

ただし、実際に攻撃が成立するかどうかや、その条件は、PHPのバージョン、修正パッチの適用状況、サーバーの構成などによって異なります。

Q. 攻撃が成功した場合、具体的に何をされる可能性がありますか?

RCEによって不正なコードが実行された場合、攻撃者はサーバー上の実行権限の範囲で、ファイルやデータにアクセスできる可能性があります。

想定される被害には、以下のようなものがあります。

① Webサイトの改ざん

Webサイトを構成するファイルを書き換えられ、ページの内容を変更されたり、不正な広告や外部サイトへの誘導を設置されたりする可能性があります。

② 顧客情報・個人情報の流出

WordPressなどでは、データベースの接続情報がサーバー内の設定ファイルに保存されています。

攻撃者がこれらの情報を取得し、データベースへアクセスできた場合、保存されているお問い合わせ内容や顧客情報などが流出する可能性があります。

③ 不正なプログラムの設置

サーバー上に不正なプログラムを設置され、継続的な不正アクセスや、ほかの攻撃に悪用される可能性があります。

④ Webサイトやサービスの停止

不正な処理によってサーバーに過剰な負荷がかかり、サービスが正常に動作しなくなる可能性があります。

ただし、RCEが成立しただけで、必ずサーバー全体の管理者権限が取得されるわけではありません。

実際の被害範囲は、PHPの実行権限、ファイルのアクセス権限、データベースの権限、サーバーの隔離構成などによって異なります。

Q. Webサイトが正常に表示されていれば、攻撃されていないと考えてよいですか?

いいえ。Webサイトが正常に表示されていても、攻撃や侵害を受けていないことの証明にはなりません。

攻撃の内容によっては、サイトの表示に影響を与えずに、内部のファイルやデータへアクセスされる可能性があります。

攻撃や侵害の有無を調べるには、アクセスログ、ファイルの変更履歴、不審なプログラムの有無などを確認する必要があります。

一方、今回の脆弱性が存在することだけで、すでに攻撃や情報漏洩が発生していると判断することもできません。

脆弱性が存在することと、実際に侵害されたことは、分けて考える必要があります。

Q. WordPressを最新版にしていれば影響はありませんか?

いいえ。WordPress本体やプラグインが最新版であっても、今回の脆弱性の影響を受ける可能性があります。

今回の問題は、WordPressではなくPHP自体に存在するためです。

WordPress本体・テーマ・プラグインを適切に更新することは重要ですが、それだけで今回のPHPの脆弱性が修正されるわけではありません。

PHP本体の修正パッチが適用されているかを、別途確認する必要があります。


Webサイトの公開停止と予防的な対策について

Q. 予防的にWebサイトを一時停止すべきでしょうか?

一時的な公開停止や外部ネットワークからの隔離は、今回の脆弱性に対するリスク低減策の一つです。

CERT-EUやENISAなどの公的機関も、速やかな修正が困難な場合には、インターネットに公開されているシステムの一時的な隔離を検討するよう案内しています。

ただし、すべてのWebサイトについて、一律に公開停止が必要とされているわけではありません。

判断にあたっては、利用中のPHPに修正パッチが適用されているか、サーバー事業者による緩和策が実施されているか、サイトが取り扱う情報の重要性、公開停止による業務への影響などを確認する必要があります。

修正パッチが未適用で、有効な防御策も確認できない環境については、公開停止を含む一時的な隔離を検討する必要があります。

Q. Webサイトを非公開にすれば、今回の攻撃は防げますか?

非公開にする方法によって異なります。

今回重要なのは、Webサイトを閲覧できなくすることではなく、外部からの不正なリクエストが脆弱なPHPの処理に到達しないようにすることです。

例えば、WordPressのメンテナンスモードを有効にするだけでは、PHP自体は動作している場合があり、今回の脆弱性に対する十分な対策にはなりません。

また、Webサイトのファイルを移動したり、公開ディレクトリを変更したりしても、ほかの経路からPHPへアクセスできる場合にはリスクが残ります。

一時的にサイトを停止する場合には、Webサーバー側でアクセスを遮断するなど、脆弱なPHPへの外部からの到達を防ぐ構成にする必要があります。

Q. レンタルサーバーであれば、安全ですか?

レンタルサーバーでは、サーバー事業者がPHPの更新やサーバー基盤のセキュリティ対策を実施する場合があります。

エックスサーバーについても、2026年10月21日から利用者のサーバーを稼働させながら、予防的な安全対策を進める旨が案内されています。

ただし、サーバー事業者が予防的な対策を実施していることと、今回の脆弱性を根本的に修正するパッチが、個別のPHP環境に適用済みであることは同じではありません。

また、事業者によって対応内容や適用時期が異なる場合があります。

安全性の判断には、利用しているサーバー環境への具体的な修正パッチの適用状況を確認することが必要です。

なお、各サーバー事業者の対応状況は随時更新されるため、最新の公式案内をご確認ください。

Q. WAFなどのセキュリティ機能を使用していれば安心ですか?

WAF(Web Application Firewall)は、不正なWebリクエストを検知・遮断するためのセキュリティ対策です。

今回の脆弱性についても、特定の攻撃経路に対する防御や、リスクの低減に役立つ可能性があります。

しかし、PHP公式は、暫定的な緩和策だけでは今回の脆弱性を完全に解消できないと説明しています。

そのため、WAFを導入している場合でも、PHP本体への修正パッチ適用の必要性は変わりません。

Q. PHPの設定を変更することで、攻撃を防ぐことはできますか?

PHP公式は、修正版を直ちに適用できない環境に向けて、特定の攻撃経路のリスクを低減するための暫定的な設定変更を案内しています。

例えば、メモリ使用量に関する設定や、HTTPリクエストのデータサイズ制限、セッション関連機能の無効化などです。

ただし、これらは特定の攻撃経路を防ぐための緩和策であり、脆弱性そのものを修正するものではありません。

また、設定内容によっては、ファイルのアップロードや既存システムの動作に影響する可能性があります。

そのため、PHP公式が示す技術情報と利用環境を確認し、サーバー管理者や保守担当者の判断のもとで実施する必要があります。


PHPのバージョンとアップデートについて

Q. 今回、どのPHPバージョンにアップデートすればよいですか?

2026年10月21日、PHP公式より以下の修正版が公開されています。

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

今回の脆弱性に対しては、これらの修正版、または該当する修正を含む後続バージョンへのアップデートが必要です。

なお、サーバー事業者やOSの提供元が独自に修正パッチを適用している場合もあるため、実際の更新方法は利用環境によって異なります。

Q. 自社サイトで利用しているPHPのバージョンはどこで確認できますか?

レンタルサーバーの管理画面から確認できる場合があります。

ただし、PHPの表示バージョンだけでは、サーバー事業者が独自の修正パッチを適用しているかどうかまでは判断できない場合があります。

修正状況が不明な場合には、サーバー事業者または管理担当者へ確認する必要があります。

Q. PHP 7.4など、古いバージョンを使用している場合はどうなりますか?

PHP 7.4を含むPHP 8.1以前のバージョンは、PHP公式による通常のセキュリティサポートが終了しています。

今回の重大な脆弱性についても影響が懸念されるため、修正パッチの適用状況を確認する必要があります。

PHP公式は今回、例外的にPHP 7.4、8.0、8.1向けの修正ソースコードを提供しています。

また、OSや長期サポートサービスの提供元が、古いPHPに修正パッチを適用する場合もあります。

ただし、修正ソースコードが公開されたことだけで、現在利用しているサーバーへの適用が完了したことにはなりません。

サーバー事業者に今回の脆弱性への対応状況を確認するとともに、将来的には公式サポート対象のPHPバージョンへの移行を検討する必要があります。

Q. PHPのバージョンが変わっていなければ、修正されていないということですか?

必ずしもそうではありません。

サーバー事業者やOSの提供元が、既存のPHPバージョンに対して、セキュリティ上の修正だけを適用する場合があります。

このような対応は「バックポート」と呼ばれます。

バックポートされた場合、PHPの表示バージョンが変わっていなくても、特定の脆弱性が修正されていることがあります。

ただし、実際に適用されているかどうかは、提供元の修正履歴や公式案内などによる確認が必要です。

Q. PHPをアップデートすると、Webサイトが動かなくなることはありますか?

はい。PHPの更新内容によっては、既存システムとの互換性に問題が生じる場合があります。

特にPHP 7.4から8系への移行など、メジャーバージョンをまたぐ更新では、従来使用できていた関数やプログラムの動作が変更されている場合があります。

そのため、WordPressのテーマやプラグイン、独自開発した機能などが正常に動作しなくなる可能性があります。

一方、同じPHP系列内でのセキュリティ修正は、通常、大規模な仕様変更を目的とするものではありません。

ただし、動作への影響がないことを保証するものではないため、必要に応じてバックアップの取得や検証環境での動作確認を行うことが重要です。

Q. プラグインなどの関係でPHPを更新できない場合はどうすればよいですか?

まず、現在のPHPバージョンに対して、今回の脆弱性を修正するパッチが提供されているか確認する必要があります。

修正パッチが提供されていない場合には、PHPのバージョンアップに際して問題となるプラグインやテーマを特定し、代替製品への変更や必要な改修を検討します。

また、すぐにアップデートできない場合には、PHP公式や公的なセキュリティ機関が案内する暫定的な緩和策や、外部ネットワークからの隔離も検討対象となります。

ただし、暫定的な緩和策だけでは脆弱性を完全に解消できないため、最終的には修正パッチの適用が必要です。


自社サイトへの影響と情報漏洩について

Q. WordPress以外のWebサイトも対象になりますか?

はい。PHPを利用しているWebサイトやシステムは、WordPress以外でも影響を受ける可能性があります。

PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境を影響対象として挙げています。

一方、PHPを使用していないシステムについては、今回のPHP固有の脆弱性による直接的な影響はありません。

ただし、外部のPHP製システムやAPIと連携している場合には、接続先の環境についても確認が必要になることがあります。

Q. WixなどのWebサイト制作サービスも影響を受けますか?

Wixなどのクラウド型Webサイト制作サービスでは、一般的にWebサーバーや実行環境の管理をサービス提供事業者が担っています。

今回の脆弱性はPHPに関するものであり、PHPを使用しない構成のWebサイトには直接的な影響はありません。

ただし、サービス内部でPHPが使われている場合や、外部のPHPシステムと連携している場合には、関連する環境について確認が必要となる可能性があります。

このようなサービスについては、利用者自身がPHPを更新するのではなく、原則としてサービス提供事業者の公式案内に従って対応を判断することになります。

Q. 顧客情報の流出が確認されていない場合でも、利用者へ注意喚起する必要がありますか?

今回の脆弱性が公表されたことだけで、すべてのWebサイトが利用者への個別通知を必要とするわけではありません。

まずは、利用中のシステムが影響を受けるか、実際に不正アクセスや情報漏洩が発生していないかを確認することが重要です。

個人情報の漏洩などが確認された場合や、そのおそれがあると判明した場合には、被害の内容や法令上の要件に応じて、関係機関への報告や本人への通知などが必要になることがあります。

通知の要否については、実際の調査結果と関係法令に基づく判断が必要です。

Q. Webサイト管理者は、まず何を確認すればよいですか?

今回の脆弱性に関して、PHP公式や公的なセキュリティ機関は、影響を受けるシステムを特定し、速やかに修正を適用するよう推奨しています。

具体的には、以下の事項を確認することが重要です。

  1. WebサイトやシステムでPHPを使用しているか
  2. 現在利用しているPHPのバージョン
  3. 今回の脆弱性に対する修正パッチの適用状況
  4. サーバー事業者によるセキュリティ対策の実施状況
  5. PHP更新に伴うテーマ・プラグイン・独自機能への影響
  6. 不審なアクセスやファイル変更などの兆候の有無

修正が未適用の場合は、外部公開されているシステムを優先して対応することが重要です。


HeartLanguageの対応について

※このセクションは、上記の一般的な技術情報とは異なり、当社のサービスおよび対応範囲に関するご案内です。

Q. HeartLanguageが保守しているWebサイトは対応してもらえますか?

当社が保守・運用を担当しているWebサイトやシステムについては、保守契約に基づき、契約上の対応範囲に応じて今回の脆弱性による影響を確認し、必要な対応を進めてまいります。

サーバー事業者による修正パッチの適用状況や、PHPの更新に伴うシステムへの影響についても、個別の環境に応じて確認・検討いたします。

具体的な対応内容や実施状況は、対象となるシステムやご契約内容によって異なります。

Q. HeartLanguageが過去に制作したサイトで、現在は自社管理している場合も相談できますか?

はい。ご相談いただけます。

当社が過去に開発・制作したWebサイトやシステムについて、現在はお客様ご自身または他の事業者様が管理されている場合にも、今回の脆弱性に関する技術的なご相談を承っております。

また、当社が制作していないWebサイトや業務システムについても、影響調査やセキュリティアップデートなどのご相談が可能です。

実際の調査や作業については、対象となる環境や管理権限などを確認したうえでご案内いたします。

Q. 今回の調査やアップデートには費用がかかりますか?

ご契約内容および必要な作業によって異なります。

当社の保守契約に含まれる対応については、原則として契約の範囲内で対応いたします。

一方、保守契約のないシステムの調査やアップデート、大規模な改修など、契約範囲外の作業が必要となる場合には、別途費用が発生することがあります。

具体的な作業内容と費用については、事前にご案内いたします。


※本FAQは2026年10月22日時点の公開情報に基づいています。セキュリティに関する技術情報や各サーバー事業者の対応状況は随時更新されるため、最新情報については各提供元の公式発表をご確認ください。