PHPの脆弱性対応：影響確認・更新と保守会社への確認事項

何が起きたのか：2026年10月21日（日本時間の23時）、PHPの開発元は、認証なしで遠隔からコードを実行される恐れがある2件の脆弱性を修正した版を公開しました。この2件はPHP2Shellと呼ばれ、WordPressなどのCMSや業務システムを含め、Webのリクエストを処理するPHPが広く対象です。サイトのコードやプラグインではなくPHP本体の問題のため、PHP（または提供元のパッケージ）を更新しない限り直りません。AWSは公表の前から悪用の試みを観測したと報告しており、IPAも10月22日に注意喚起を出しています（IPA：PHPの脆弱性対策について）。

2件の脆弱性の内容：CVE-2026-109618は、メモリ不足の処理で、準備の途中のリクエストのデータを正しいものとして扱ってしまう問題です。CVE-2026-109619は、終わったリクエストの内部の状態が残り、同じプロセスが後で処理するリクエストで使われてしまう問題です。どちらも、認証なしで、Webサーバーのプロセスの権限でコードを実行される恐れがあり、開発元は深刻度をCVSS v4.0で9.2と評価しています（PHP公式の勧告）。

対象は、Webのリクエストを処理するPHPです。開発元は、PHP-FPM、Apacheのモジュール（mod_php）、php-cgi、FrankenPHP、LiteSpeedを含むと説明しており、特定の構成やCMSだけの問題ではありません。危険性が最も高いのはmod_phpで、アプリのコードが動く前に、認証のないリクエストで攻撃が成立することが実証されています。

この表は、10月21日に公開された修正の版で、今後も最新版という意味ではありません。更新する時点で、PHP公式サイトと、OS・製品の提供元の最新の情報を確認します（情報確認日：2026年10月26日）。PHP 8.1以前は、開発元から修正版のリリースはありません（7.4・8.0・8.1は、ソースからビルドする利用者向けに、最小限の修正がソースコードで公開されています）。一部のLinuxディストリビューションや長期サポート（LTS）の提供元は、修正を古い版に取り込んだパッケージを提供している場合があるため、提供元に確認するか、サポート中の版へ更新します。

10月23日の追加の案内：PHPの開発元は、別の脆弱性CVE-2026-115560についても案内を出しました（PHP公式の案内）。影響するのは、次の条件がそろう場合です。アプリが、設定でセッションの保存形式（session.serialize_handler）をphp_binaryまたはphp_serializeにしたうえで、実行中にini_set()でphpへ切り替えてからsession_start()を呼び、さらに、ファイルのアップロードの進み具合をセッションに記録する機能（session upload progress）が有効なままの場合です。開発元は、このような構成は実際にはまれだとして、次の通常のリリースで修正するとし、それまでは設定による対処を案内しています。10月21日の修正版に更新しただけでは、この件は解消されません（Cloudflareも、8.5.12を含む修正済みの版が影響を受けると説明しています）。条件に当たるかと、設定を変えたときに業務の機能へ影響がないかを、保守先に公式の案内に沿って確認してもらいます。

PHPは、Webサイトを作るために広く使われているプログラミング言語です。Web開発に向いた汎用のスクリプト言語で、HTMLの中に埋め込んで書けます。プログラムはサーバーで実行され、その結果のHTMLが閲覧者のブラウザに送られます（PHP：What is PHP?）。

普及した理由は、言語の手軽さのほかにもあります。WordPressのようなCMSはPHPで作られていて、WordPressの公式の要件も、PHPとデータベース（MySQLなど）が動くサーバーを前提にしています（WordPress：要件）。Webサイトの制作会社の多くは、作りやすく更新の画面も用意しやすいWordPressを、長いあいだ標準の選択肢として提案し続けてきました。発注する側も、デザインや更新のしやすさは確かめても、サイトがどのような仕組みで動いているかまでは気にかけてこなかったことが多くあります。こうして作られたサイトが、何年も、利用者が意識しないままPHPの上で動き続けています。

W3Techsの集計（2026年10月26日時点）では、サーバー側のプログラミング言語が分かるWebサイトのうち、69.2%がPHPを使っています。WordPressは、全サイトの39.6%、CMSが分かるサイトの58.3%で使われています（W3Techs：PHPの利用状況、W3Techs：WordPressの利用状況）。これはW3Techsが調べている2,000万を超えるサイトの集計で、1つのサイトが複数の言語を使う場合もあります。日本の企業サイトの割合や、脆弱性の影響を受けるサイトの数を示すものではありません。

そのうえで、PHP2Shellが大きな問題になった理由は、次の5つにまとめられます。

1. アプリの作りに関係なく、PHPそのものが対象になる：アプリの不具合ではなく、PHPがリクエストを処理する部分の問題です。Wizは、Hello Worldのような単純なアプリでも影響を受けることを示しています。アプリの側の対策だけでは防げません。
2. 使われている場所が広く、利用者が把握していない：企業サイトのCMS、独自の業務システム、購入した製品の内部、外部のサービスなど、PHPは利用者が意識しない場所で動いています。
3. 古い版が残っている：W3Techsの集計では、PHPを使うサイトのうち、7以前の版と判定されたサイトが34.5%あります。開発元は8.1以前の修正版をリリースしていないため、提供元の修正がなければ、更新や移行の判断が必要になります。ただし、版の判定は外から見える情報によるもので、提供元が修正を取り込んでいるかは分かりません。
4. 誰が更新するかが分かれている：サーバーの事業者、制作会社、保守会社、製品の提供元のどこがPHPを更新するのかが、契約で決まっていないことがあります。
5. 公表から攻撃までの時間が短い：AWSは、攻撃を観測するためのおとりのシステム（ハニーポット）で、公表の4日前の10月17日にさかのぼる悪用の試みを確認しました。実際のシステムで成功したかは分からないとしたうえで、少なくとも2026年10月17日から調査時点までのログを確認するよう勧めています（AWSの報告）。研究結果を公表したWizは発見や検証にAIモデルを使っており、AWSも、AIによって修正の内容から攻撃の手法を作る手間が下がっていると指摘しています（Wizの報告）。

これらは攻撃の試みと研究上の実証で、個々の企業が侵入されたことを示すものではありません。自社への影響は、自社の環境で確認します。その出発点が、次の章で扱う、PHPが動いている場所と管理者の洗い出しです。

IPAは事前の注意喚起で、PHPを使っているプログラムを可能な範囲で洗い出すことと、利用している製品にPHPが組み込まれていないかを、マニュアルや提供元のセキュリティ情報で確認することを求めています（IPA：事前準備のお願い）。すべてを自社で調べる必要はありません。システムごとに、誰に何を確認するかを決めます。

表は横にスクロールできます →

確認できない環境は、「対象外」ではなく「未確認」として記録します。手元のPCや1台のサーバーでPHPの版を確かめても、本番と検証、複数のサーバー、コンテナで状態が違う場合があります。外部のサービスについては、提供元に影響と対応の状況を確認します。

記録には、公開しているURLや用途、業務の担当、保守・提供元、実際に処理している環境、PHPの版または提供元のパッケージ、対象のCVE、判断の根拠、次の担当と期限を書きます。パスワードなどの認証情報や、顧客のデータそのものは記録に含めません。PHPの設定を表示するページ（phpinfo）をインターネットから見える場所に置いたり、他社のサイトを調べたりする必要もありません。

自社のサイトでPHPが使われているかは、まず、管理している人と契約から確かめます。サイトの制作・保守の会社やレンタルサーバーの事業者に問い合わせる、契約書や請求書でサーバーとCMSの名前を確かめる、サーバーの管理画面にPHPの版の設定があるかを見る、といった方法です。

外から見て分かる手がかりもあります。ただし、手がかりは設定で隠したり変えたりできるため、見つからないことは、PHPを使っていない証明にはなりません。

表は横にスクロールできます →

応答ヘッダーとCookieの既定の動きは、PHPの公式マニュアル（expose_php、session.name）で確認できます。手がかりを確かめるのは、自社が管理・利用しているサイトに限り、通常の閲覧と同じ範囲にとどめます。脆弱性を調べるツールでの検査や、攻撃が成立するかを試すことは、この確認には必要ありません。PHPが使われていると分かっても、版の表示だけでは、修正が済んでいるかは判断できません。最後は、管理者や保守先に、実際に動いている環境と修正の根拠を確認します（確認する8つの項目）。

保守会社から「対応済み」と回答があっても、どの環境に、何を根拠に、いつ反映したかが分からなければ、自社では判断できません。依頼するときは、次の書き出しと8つの項目を使って確認します。

1. 対象のシステムと環境：対象のサイト・システム、本番や検証などの環境、PHPを動かしている方式（PHP-FPM、mod_phpなど）
2. 影響の判断と根拠：2件のCVEと、10月23日のCVE-2026-115560が当てはまるかの判断と、その根拠
3. PHPの版と提供元の対応：PHP公式の版、またはOS・製品の提供元のパッケージと、その修正の状況
4. 担当と見通し：作業の担当、承認する人、更新の予定
5. 更新までの暫定措置：反映までに取る措置と、それでも残るリスク
6. 反映と動作の確認：すべての稼働環境に反映したことと、主な機能を確認した結果
7. 攻撃の兆候の確認：確認したログの種類と期間、ログの保存期間、不審な点の有無
8. 未確認の事項と次の連絡：まだ確認できていないことと、次に連絡する時期

返信の期限は、公開の範囲や業務への影響に応じて、相手と合意します。契約上どこまでが保守の範囲かが分からない場合も、まず現状の確認を依頼し、範囲を超える作業が必要なら、担当と費用を相談します。回答にサーバーの情報やログが含まれる場合は、送る方法と受け取る人を決めておきます。

PHPの開発元は、更新だけが完全な対策で、設定による緩和は特定の攻撃の経路を減らしても、安全にするものではないとしています（PHP公式の勧告）。影響の確認と並行して、インターネットに公開しているシステムから、更新を速やかに進めます。全システムの棚卸しや、次の定例の会議が終わるのを待つ必要はありません。

どのシステムから進めるかは、公開の範囲（インターネットから届くか、社内やVPNからだけか）、扱う情報と業務の重要度、悪用の状況から判断します。CVSSのスコアは判断の材料の1つで、それだけでは順番は決まりません。

更新まで時間がかかる場合は、アクセス元の制限、使っていないファイルのアップロードの機能の停止、WAFのルールなどの暫定措置を検討します。IPAは、有効な暫定措置が難しい場合に、外部からのアクセスの遮断やサービスの一時停止の要否を判断するよう求めています。WAFや設定による対処は、PHP本体の修正の代わりにはなりません。Cloudflareも、WAFで保護していてもPHPを更新するよう求め、サイトのコードやプラグインを更新するだけでは直らないと説明しています（Cloudflareの説明）。設定の変更は、業務の機能や動作の安定性に影響することがあります。公式の案内の適用条件と限界を確かめ、管理者が判断します。

更新を緊急の変更として進める場合も、承認と確認は省きません。誰が承認し、何を確かめたら完了とするかを決めて記録します。進め方はシステム変更管理の記事で扱っています。更新の後に業務の機能が動かない場合も、脆弱性のある版へそのまま戻すのではなく、公開の範囲の制限や代わりの手段を含めて判断します。

PHPのパッケージを入れ替えても、WebサーバーやPHPのプロセスを再起動していない場合や、複数のサーバーやコンテナの一部に反映していない場合は、古い版が動き続けます。反映の手順は、配置の方法と提供元の手順に従います。担当者に次の点の確認を依頼し、結果を記録します。

• 実際にリクエストを処理しているすべての環境（複数のサーバー、コンテナ、待機系を含む）で、修正した版またはパッケージが動いている
• コンテナのイメージや、サーバーを作り直すための設定が古い版のままになっておらず、作り直したときに古い版へ戻らない
• ログイン、問い合わせ、ファイルのアップロード、決済など、主な業務の機能が動く
• 10月23日の案内の条件に当たるか。設定を変えた場合は、業務の機能への影響
• 誰が、いつ、どの環境で何を確認したか

更新は、これから先の攻撃の経路を閉じるもので、すでに侵入されていないかの確認は別に必要です。AWSは、少なくとも2026年10月17日から調査時点までを対象に、Webサーバーのログや、予期しないプロセスの実行、ファイルの変更を確認するよう勧めています。ただし、PHPの開発元は、ログにエラーがないことは安全の証明にならないとしています（CVE-2026-109619の勧告）。ログを残している期間が短い場合や、必要な記録を取っていない場合もあるため、確認したログの種類と期間を記録します。

不審なファイルやプロセス、身に覚えのない変更が見つかったなど、攻撃を受けた疑いがある場合は、社内の責任者と保守先へすぐに連絡し、分かったことを記録します。専門の相談先として、JPCERT/CCのインシデント相談・情報提供の窓口もあります。初動の確認・連絡・被害拡大の防止は、セキュリティインシデント対応計画の記事で扱っています。

更新が進まない理由には、技術以外の事情もあります。保守の契約が切れている、作った会社と連絡がつかない、ソースコードやサーバーの権限が手元にない、新しい版でアプリが動くか分からない、といった事情です。何が妨げになっているかと、確認と対応のそれぞれの担当を分けて整理します。

PHP本体のサポートと、OSや製品の提供元のサポートは別です。PHPの開発元は8.1以前の修正版をリリースしていませんが、提供元が修正を提供している場合があります。また、PHP 8.2のセキュリティ修正は、2026年12月31日で終わる予定です（PHP：Supported Versions）。使っている版と提供元の、支援の期限と条件を確認します。

更新が難しいシステムは、IPAの案内も踏まえ、更新や移行までの暫定措置、公開を続けてよいか、代わりの手段、更新・移行・機能の縮小・廃止を、業務の担当者も交えて判断します。企業サイトであれば、公開サイトでPHPを動かさない構成に移すという選択肢もあります（WordPressやPHPをやめるという選択肢）。移行には時間がかかるため、当面の更新や暫定措置とは分けて判断します。

• 保守の会社を変える場合の、契約・資料・権限の引き継ぎ：開発会社の引き継ぎチェックリスト
• WordPressのサイトを続けるか、移行するかの判断：WordPressをやめるべきかの判断基準
• 業務システムの移行の方式と進め方：レガシーシステム移行の進め方

以下は対応状況の記入例です。保守先からの「対応済み」という回答と、対象・根拠・反映の確認を分けて記録します。

表は横にスクロールできます →

記録の形式や細かさは、システムの数と体制に合わせて変えて構いません。確認した日と確認した人を残しておくと、次に同じような公表があったときにも、この記録をもとに確認を進められます。

今回のような脆弱性は、公開しているサーバーでPHPが動き続ける限り、公表のたびに同じ確認と更新が必要になります。PHPそのものが悪いわけではありません。ただ、会社案内、サービス紹介、お知らせ、採用情報が中心のサイトであれば、閲覧されるたびにサーバーでプログラムを動かす必要はありません。

WordPressやPHPを公開環境から外し、あらかじめ作ったHTMLを配信する構成に移せば、PHP2ShellのようなPHP本体の脆弱性や、WordPress本体・プラグインの脆弱性の影響を、公開しているサイトでは受けなくなります。管理画面やログイン画面も、インターネットに公開しなくて済みます。

表は横にスクロールできます →

保守がなくなるわけではありませんが、脆弱性の情報を追って公開サーバーを更新し続ける対象は減ります。会員機能、EC、予約、多言語などの仕組みがあるサイトは、移す範囲と方法を個別に検討します。WordPressを編集用のCMSとして残す構成では、WordPress側の更新と脆弱性への対応も残ります。

移行には準備と時間がかかります。移行を決めた場合も、いま動いているサイトのPHPの更新や暫定措置は後回しにせず、並行して進めます。記事・画像・URL・フォームの引き継ぎ方と、続けるか移行するかの判断基準は、WordPressからモダン構成へ移行する手順で扱っています。Next.jsとヘッドレスCMSを組み合わせる構成の考え方はモダンWeb開発の構成判断で、移行後に残る費用と削減できる費用はホームページ維持費の記事で扱っています。

Malakeでは、WordPressを公開環境から外し、生成したHTMLをCloudflareで配信する構成への移行を支援しています。現在のサイトのURLをもとに、移行できるか、推奨する構成、概算の費用を無料で診断します。WordPressを続けたほうがよい場合は、その理由もお伝えします。詳しくは、WordPress移行の診断・支援内容をご覧ください。

最後に、確認の漏れを見つけるためのチェックリストと、主な疑問への回答をまとめます。すべての項目にチェックが付いても、安全が保証されるわけではありません。