PHPの重大な脆弱性とは｜CVE-2026-109618・109619の対応手順

昼の光が入るサーバールームで、ラックの赤い警告灯が点き、モニターに赤い警告が表示されている写真風のイメージ。「PHPの重大な脆弱性 確認と更新の手順」の文字入り。 セキュリティ

要点

  • 2026年10月21日、PHP公式は2件の重大な脆弱性を修正した8.2.35、8.3.36、8.4.27、8.5.12を公開し、直ちに更新するよう求めました。
  • GHSAの影響版一覧は8.2系以降です。CERT-EUは8.1以前も挙げ、PHP公式は7.4、8.0、8.1向けに最小限のソース修正を出しました。
  • 欠陥はPHP本体にあり、WordPress、テーマ、プラグインだけの更新では直りません。
  • レンタルサーバーではPHP版と事業者の最新告知を確認し、自主管理のサーバーでは修正版かベンダー修正済みパッケージへ更新します。
  • 最初に確認するのは、PHP版、契約事業者、対応状況、更新担当者です。
  • 更新が難しいサイトについて、IPAは、移行や、機能の縮小、公開の終了まで含めて、方針を決めるよう求めています。

2026年10月22日時点で何が起きているのか

2026年10月21日、PHP公式が、2件の重大な脆弱性を修正した版を公開しました。同じ日に、いくつかの機関が公表しています。

  • CISA（米国の機関）：2件を「php2shell」と呼び、直ちに更新するよう求めました。
  • CERT-EU（EUの機関）：PoC（概念実証＝攻撃が成り立つことを示す手順）が出回り始めたと説明しました。
  • Cloudflare：自社の顧客を狙う攻撃の通信を観測したと公表しました。
  • IPA（日本）：10月21日に事前準備のお願いを出し、22日に、修正版の公開を受けた続報「PHPの脆弱性対策について」を公表しました。

22日には、国内のレンタルサーバー事業者も告知を出しました（後述の表）。ここに書いた内容は、すべて時点の情報です。最新は、各公式ページで確認してください。

2件の脆弱性と影響を受ける版をやさしく説明

PHPは、WordPressなどのWebサイトの裏側で、Webの要求（リクエスト）を処理する仕組みです。脆弱性はセキュリティ上の欠陥、CVEはその識別番号です。今回の2件は、どちらも、外部から、認証なしで、サーバー上の命令を実行されてしまう「リモートコード実行」につながり得ます。実行されるのは、Webの処理を担当するアカウント（Webワーカー）の権限です。そのアカウントが触れられるものが、影響の範囲になります。

2件とも、深刻度は「Critical」で、CVSS v4.0は9.2です。CVSSは、深刻度を0〜10で表す点数です。内訳を見ると、ネットワーク越しに攻撃でき、必要な権限も、利用者の操作も要りません。一方で、攻撃を成立させる条件の複雑さは「高」で、一定の前提も必要とされています。簡単な欠陥ではありませんが、PHP公式は、mod_phpという方式で、攻撃が実際に成立することを実証しています。

どちらも、Webの要求を処理するすべてのPHP（PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど）が対象です。mod_phpとPHP-FPMは、PHPをサーバーで動かす方式の名前です。PHP公式は、mod_phpのリスクが最も高いと考えています。

CVE-2026-109618：メモリ不足時の後始末の誤り

メモリ不足で処理が途中で打ち切られたとき、準備の途中だった内部データが、後始末で「有効なもの」として扱われてしまう欠陥です。mod_phpでは、認証なしの要求だけで、アプリケーションの処理が始まる前に攻撃を引き起こせることが、実証されています。PHP-FPMも、分析の上では影響を受け得ますが、この欠陥について、完全な悪用は実証されていません。

CVE-2026-109619：前のリクエストの古い状態を再利用

ワーカー（Webの要求を順に処理する単位）に、前の要求の内部状態が残り、次の処理で、初期化の前に使われてしまい得る問題です。成立には、古い状態を残す処理と、それを使う処理の、両方が必要です。

たとえば、前の客が机に残した物を、次の客が備品だと思って使ってしまうようなものです。実際には、PHPの内部のメモリの状態で起きます。

勧告によれば、セッションのアップロード進捗を通る経路は、mod_phpで確認されたほか、PHP-FPMでも検証されています。FPMの場合は、アプリケーション側に、適した処理があることが条件です。この機能は、既定で有効です。このため、FPMだから問題がない、とは読めません。

影響を受ける版と修正版

GHSAの影響範囲とPHP公式のサポート期限を整理します。

系統影響範囲と修正サポート期限すること
8.58.5.12未満／修正版8.5.122029年12月31日8.5.12以降へ更新
8.48.4.27未満／修正版8.4.272028年12月31日8.4.27以降へ更新
8.38.3.36未満／修正版8.3.362027年12月31日8.3.36以降へ更新
8.28.2.35未満／修正版8.2.352026年12月31日更新し、次の系統も計画
8.1以前（7.4、8.0、8.1など）CERT-EUが影響版に記載。7.4、8.0、8.1には最小限のソース修正7.4＝2022年11月28日、8.0＝2023年11月26日、8.1＝2025年12月31日に終了ベンダー修正を確認し、サポート中の版へ移行

IPA（2026年10月22日）も、影響を受けるシステムとして、8.2.35未満の8.2系、8.3.36未満の8.3系、8.4.27未満の8.4系、8.5.12未満の8.5系を挙げています。さらに、脆弱性の調査に関わったWiz社によれば、PHP 5.4以降のバージョンは、どちらか一方の影響を少なくとも受けるとしています。GHSAの一覧は8.2系以降、CERT-EUは8.1以前も対象です。7.4、8.0、8.1向けは、ソース構築者向けのバックポート（古い系統への修正）で、番号付きリリースではありません。

サイトを、下からサーバー（PHPが動く土台）、WordPress、テーマ・プラグインの順に示す図。欠陥があるのはPHP本体で、サイトのコードやプラグインだけを更新しても直らない。修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12で、サーバー事業者またはサーバー管理者がPHPを更新する。
図1　PHP本体の更新が必要な場所と修正版（PHP公式・Cloudflareをもとに当社が作成）
サイトを、下からサーバー（PHPが動く土台）、WordPress、テーマ・プラグインの順に示す図。欠陥があるのはPHP本体で、サイトのコードやプラグインだけを更新しても直らない。修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12で、サーバー事業者またはサーバー管理者がPHPを更新する。
図1　PHP本体の更新が必要な場所と修正版（PHP公式・Cloudflareをもとに当社が作成）

自分のサイトのPHP版と事業者の対応を調べる

  1. サーバー管理画面でPHP版を探します。項目名は事業者ごとに異なります。
  2. WordPressでは「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認します。古いPHPは「ステータス」に重大な問題として出ることがあります。
  3. 委託中なら、現在版と対応状況を保守担当へ聞きます。

公式修正版は8.2.35、8.3.36、8.4.27、8.5.12です。独自修正で表示版が一致しないこともあるため、事業者の告知も確認します。

レンタルサーバー事業者の告知

2026年10月22日の各社告知です。優劣比較ではなく時点情報のため、最新は公式ページで確認してください。

事業者・時点告知内容
エックスサーバー（2026年10月22日6:45時点。管理画面は13:15時点）8.2〜8.5は対象全サーバーへ適用済み。旧版は一部から順次対応。管理画面等は一部を除き再開。利用者サイトとメールは通常どおり
さくらインターネット（2026年10月22日）選択可能な全PHP版で対応完了し、緊急対応はないと案内。サポート中の最新版への移行も推奨。phpMyAdmin等は一部対応中
KAGOYA（2026年10月22日10:35更新）レンタルサーバー8.2〜8.5は順次更新の方針。他の対象プランは恒久対応を調整中で、公開停止やアクセス制限等を案内

利用環境ごとの対応手順

共用レンタルサーバーを使っている場合

事業者の告知で、自分のプランとPHP版が「対応済み」「順次対応」「調整中」のどれかを確認します。自分で版を選べても、古いWordPressやプラグインとの対応を先に見ます。

VPS・クラウドなどを自分で管理している場合

修正版またはLinuxディストリビューション／LTSベンダーの修正済みパッケージへ更新します。PHPを使うシステムと組み込み製品を洗い出し、公開中のものを優先します。更新できない間、CISAはオフライン化を求め、CERT-EUは公開ネットワークからの切り離しを検討するよう案内しています。

制作会社・保守会社に任せている場合

  • 現在のPHP系統と表示版は何ですか。
  • 2件への対応は完了していますか。独自修正なら告知はどこですか。
  • 未対応なら、更新予定と、それまでの公開範囲・暫定策は何ですか。
  • バックアップ、更新後の表示・フォーム・ログイン・ログ確認、戻し方は決まっていますか。

以下は6ステップです。

PHPの脆弱性への対応を6ステップで示す図。PHPの版を調べ、事業者の告知を確認し、バックアップを取り、修正済みの版へ更新するか事業者の対応を待つ。更新後は表示・フォーム・ログインを確認し、ログや身に覚えのないものも確認する。
図2　PHPの版の確認から更新後の点検までの6ステップ（PHP公式・WordPress公式・IPA等をもとに当社が作成）
PHPの脆弱性への対応を6ステップで示す図。PHPの版を調べ、事業者の告知を確認し、バックアップを取り、修正済みの版へ更新するか事業者の対応を待つ。更新後は表示・フォーム・ログインを確認し、ログや身に覚えのないものも確認する。
図2　PHPの版の確認から更新後の点検までの6ステップ（PHP公式・WordPress公式・IPA等をもとに当社が作成）

図の「事業者の対応を待つ」は、未修正のまま公開を続けるという意味ではありません。

PHPの版を上げるときの注意

古いWordPress、テーマ、プラグインは、新しいPHPで動かないことがあります。

  1. 現在版を記録し、復元できるバックアップを取る。
  2. WordPressとテーマ・プラグインの対応、問題時の戻し方を確認する。
  3. PHPを修正済みの版へ上げ、表示・フォーム・ログイン・管理画面・ログを確認する。

WordPress公式の対応表では、次のとおりです。

WordPressの版対応するPHP
5.1・5.27.3まで
5.3〜5.57.4まで
5.6PHP 8.0に最初に対応
6.4PHP 8.3にベータ対応（6.8で完全対応）
7.xPHP 7.4以上が必要

つまり、古いWordPressのまま、PHPだけを新しい版にすると、サイトが動かなくなることがあります。また、create_function()という関数は、PHP 7.2.0で非推奨、8.0.0で削除されました。これを使っている古いプラグインやテーマは、PHP 8.0以降で、エラーになることがあります。

PHP 7.4、8.0、8.1はサポート終了済みです。国家サイバー統括室もサポート終了製品・版を使わないよう求めています。8.2の期限も2026年12月31日なので、次の移行時期まで決めます。

更新が難しいとき：IPAが示した考え方

長く更新していないサイトでは、PHPを上げるために、プラグインやテーマの改修、動作確認が必要になり、すぐには進まないことがあります。IPAは、2026年10月22日の文書で、修正対応が難しい場合の考え方を6点に整理しています。

  1. 利用中のPHPのサポート状況を確認します。PHP 8.1以前はサポートが終了しています。修正が提供されない版なら、サポートのあるPHPへの更新か、対策済みの製品・サービスへの移行を検討します。
  2. 更新・移行までの間も、脆弱な状態を放置せず、暫定対策やアクセス制限を検討します。有効な暫定対策が難しいなら、被害や業務への影響を踏まえ、外部からのアクセス遮断や、サービスの一時停止が必要かを判断します。
  3. システムの役割と、更新・移行の難しさを把握します。長く更新していないシステムは、資料やノウハウの不足、担当者の不在、保守契約の終了で、対策が難しくなっていることがあります。
  4. 担当者だけでなく、事業責任者や経営層も含め、更新・移行と、その後の維持管理に必要な、人員・予算・保守体制を確保できるかを検討します。
  5. 維持管理の体制を確保できる見通しがあれば、更新や移行を進めます。見通しが立たなければ、いまのシステムの継続を前提にせず、保守を受けられる製品・サービスへの移行、機能の縮小、公開の終了やシステムの廃止も含めて検討します。
  6. 利用者や業務への影響を考え、必要なデータの移行・保存や、代わりの手段の案内を計画します。

つまり、「更新するか、放置するか」の二択ではなく、「作り直す」「縮小する」「公開をやめる」まで含めて、決めるということです。

暫定対策・WAFと悪用状況の見方

更新までの暫定対策

暫定策は完全な解決ではありません。設定は管理者か事業者が確認し、修正版へ更新します。

  • CVE-2026-109618：上書き不能な方法でmemory_limit=-1を設定。post_max_sizeはアップロード不要なら8M、必要なら32Mとし、upload_max_filesizeをそれ未満にします。Webサーバー側でも量を制限します。メモリ上限を外す設定なので、サーバー全体のメモリを使い切らないよう、コンテナやcgroupの上限を併用することが示されています（RLIMIT_ASやRLIMIT_DATAは使わない）。
  • CVE-2026-109619：session.upload_progress.enabled=0をサーバー側で適用し、全ワーカーを再起動。PHP 8.5ではfatal_error_backtraces=0も示されています。確認済み経路だけを減らす措置です。
  • 到達可能な致命的エラーや実行時間切れを減らし、ログを見ます。エラーがなくても安全とは限りません。

WAF（Webアプリケーションファイアウォール。Web通信を検査・遮断する仕組み）は、CISAによれば更新まである程度の保護になり得ます。Cloudflareは更新の代わりにならないとしています。

悪用は確認されているのか

観測範囲と時点が違うため、発行元ごとに読みます。

  • CISA（2026年10月21日）：公表時点で悪用を確認していない。
  • CERT-EU（2026年10月21日、v1.1）：PoCが出回り、悪用の可能性が高まった。悪用確認とはしていない。
  • Cloudflare（2026年10月21日）：自社顧客を狙う攻撃通信と、防御回避を試みる動きを観測。
  • KAGOYA（2026年10月22日10:35更新）：自社で悪用攻撃や情報漏えい等の被害を確認していない。

状況は変わり得ます。影響版と提供元の修正状況で対応を判断します。

侵害が疑われるときと、次に備えるための点検

CISAは、PHPワーカーがシェルを起動したりツールをダウンロードしたりしていないかの監視を勧めています。身に覚えのないアカウント、無効のはずのアカウント、異常なログも確認します。異常があれば、IPAは専門のセキュリティベンダーへの詳細調査を強く推奨しています。

平時はPHP系統、サポート期限、更新担当、バックアップと確認手順を一覧にします。公開範囲やアカウントの点検は国内で相次ぐ不正アクセス｜政府機関の注意喚起から確認したいことでも整理しています。

シンクトラストの代表的な確認項目には「古いソフトの放置」がありますが、診断はPHP更新の代わりではありません。相談後に対象・範囲・金額・日程を合意します。相談から診断までの流れとWordPress診断の解説WordPressのセキュリティ診断で確認すること｜更新だけで足りるかも参照してください。

よくある質問

WordPressのプラグインを更新すれば直りますか？

直りません。欠陥はPHP本体です。PHPを更新するか、事業者へ確認します。

共用レンタルサーバーなら、自分は何もしなくてよいですか？

契約プラン、PHP版、対応範囲を確認します。「対応済み」でも、終了版なら移行を検討します。

PHP 7.4を使っています。どうすればよいですか？

7.4は2022年11月28日に公式サポートを終了しました。今回のソース修正は番号付きリリースではありません。ベンダー修正を確認し、サポート中のPHPへ移行します。移行が難しい場合の考え方は、前の節（IPAの案内）を参照してください。

WAFがあれば安全ですか？

更新まである程度の保護になり得ますが、PHP更新の代わりにはなりません。

すでに攻撃されているのでしょうか？

この記事だけでは個別サイトの被害は判断できません。不審なプロセス、ログ、アカウントがあれば専門家へ相談してください。

PHPを上げたらサイトが表示されなくなりました。どうすればよいですか？

決めた手順で戻し、WordPress等との対応を確認します。操作は事業者のマニュアルに従うか、保守担当へ相談してください。

更新履歴

  • 2026年10月22日: 公開。2026年10月22日時点の情報（IPAの同日の続報を反映）。

出典

画像について：冒頭のアイキャッチ画像は、AIで生成した写真風のイメージに、当社が文字を入れたものです。図1・図2は、当社が作成しました。

タイトルとURLをコピーしました