PHP脆弱性CVE-2026-109618｜対象版と今日の対応

最終確認：2026年10月30日（JST）

よくある誤解は、「最初の注意喚起を読んで修正版を入れたなら、この件は終わり」というものです。修正版そのものは変わっていません。しかし、JPCERT/CCの注意喚起は10月22日の公開後、10月26日と10月29日に更新されました。10月29日の追記では、あるファイアウォール製品の特定版に対する侵害成功を示唆する痕跡と、内部ネットワークへの横展開を試みた痕跡が報告されています。

だから、2026年10月30日時点の実務は「パッチがあるかを調べる」だけでは足りません。修正済み版へ切り替わったことを実行中のプロセスまで確かめ、修正前の期間についてログと端末・サーバーの状態を確認する必要があります。JPCERT/CCも、速やかな対策適用と侵害有無の調査を求めています。

一方で、国内の被害を断定するのも正確ではありません。IPAは10月27日時点で、国内の攻撃被害事例を把握していないと明記しています。JPCERT/CCの追記にも、報告された侵害が日本国内で起きたとは書かれていません。「悪用の試みと侵害を示唆する報告はある」「国内被害をIPAは把握していない」を分けて扱うのが、現時点の正しい整理です。

10月21日夜の初報、レンタルサーバー各社の対応、一時対策の背景は、既刊のPHPの緊急脆弱性（php2shell）｜レンタルサーバーの対応と今やることにまとめています。ここでは、10月29日のJPCERT/CC更新後に経営者と担当者が判断し直す点に絞ります。

10月29日更新で変わったのは修正版ではなく、悪用状況の判断

JPCERT/CCのPHPにおける複数の脆弱性に関する注意喚起は、10月22日に公開され、同日、10月26日、10月29日に改訂されています。ページ本文で確認できるのは日付までであり、配信記録の時刻を公開時刻や更新時刻とは扱いません。

JPCERT/CCは、悪用できると主張する実証コードが多数公開され、悪用を試みる通信の観測報告も相次いでいると説明しています。ただし、公開された実証コードがどの環境でも任意コード実行に成功するわけではありません。PHPの版、実行環境、メモリ配置などの条件に依存し、環境ごとの調整が要るとも明記されています。

IPAはPHPの脆弱性対策についてを10月27日に更新し、両CVEが米国CISAの悪用確認済み脆弱性カタログへ追加されたことを案内しました。同時に、国内の攻撃被害事例は把握していないとしています。経営層への報告では、「悪用は未確認」とも「国内で被害が確定」とも丸めず、この二つの事実を並べてください。

対象版と修正版を、上流PHPとOSパッケージに分けて見る

PHP公式のセキュリティ告知と2件のGitHub Security Advisoryが示す対象版・修正版は共通です。PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含め、Webリクエストを処理するPHPが確認対象です。mod_phpだけの問題ではありません。

Linuxディストリビューションの版の読み方：OSベンダーは修正部分だけを古い系列へ取り込む「バックポート」を行うため、表示される上流PHP番号が8.5.12未満でも修正済みの場合があります。上流番号だけで決めず、Ubuntu USN、Debian Security Tracker、Red Hat Errataなどに掲載されたパッケージ版の末尾まで比較します。

たとえばUbuntu USN-8948-1では、Ubuntu 24.04 LTSのphp8.3は8.3.6-0ubuntu0.24.04.13が修正済みです。8.3.6だけを見て「8.3.36より古いから未修正」と判定してはいけません。Ubuntu 22.04 LTSのphp8.1も8.1.2-1ubuntu2.28で修正されていますが、これはUbuntuのパッケージとしての修正であり、PHPプロジェクトがPHP 8.1の通常版を再開したという意味ではありません。

Debianでは、bookwormのphp8.2は8.2.35-1~deb12u1、trixieのphp8.4は8.4.27-1~deb13u1が修正済みとして掲載されています。Red Hatは製品・ストリームごとにErrataが異なるため、単一のRPM版を当てはめず、利用中の製品に対応する告知を確認します。

2件ともCriticalでも、壊れ方と確認済みの範囲は異なる

両CVEは、CVE公式レコードでCritical、CVSS v4.0 9.2です。ネットワークから到達でき、事前の権限も利用者の操作も不要という評価です。悪用されると、外部からPHPの実行権限でプログラムを動かされる可能性があります。ただし、技術的な原因と確認済みの影響範囲は同じではありません。

CVE-2026-109618のGitHub勧告は、mod_phpではアプリケーション固有のコードが始まる前に成立する確認済み経路があると説明しています。WordPressの認証、WAF、セキュリティプラグインがあるからPHP本体の更新を後回しにできる、とは言えません。

CVE-2026-109619のGitHub勧告は、メモリ内容の漏えいと任意コード実行を影響として挙げています。ここでいう「情報が漏れる」は、すべてのデータベースが漏れたという被害報告ではありません。脆弱性の技術的影響として、Webワーカーのメモリ内容が漏れる可能性が確認されている、という意味です。

今日の順番は「版の確認→更新→再起動→前後の確認」

担当者への依頼は、次の順で具体化すると抜けが減ります。CLIのphp -vだけでは、Webで実際に動くPHP-FPMやmod_phpと別の版を見ていることがあります。コントロールパネル、パッケージ管理、実行中のサービスを合わせて確認してください。

1. 版と実行経路を確認する：公開サイト、管理画面、API、組み込み製品を洗い出し、PHPの系列、OSパッケージ版、PHP-FPM・mod_php・CGI・LSAPIなどの動かし方を記録します。委託先やレンタルサーバーには、修正済み版へ切り替わった日時と対象サービスを確認します。
2. 更新前の状態を残す：現在のパッケージ版、設定、稼働プロセス、主要画面の応答、直近ログの保管範囲を記録します。侵害が疑われる場合は、上書きや再構築より先に証拠を保全します。
3. 修正済み版へ更新する：PHP公式版を使う環境は8.5.12・8.4.27・8.3.36・8.2.35以降へ、LinuxはOSベンダーが示す修正パッケージへ更新します。PHPを組み込んだ製品は、PHPだけを独自に差し替えず製品ベンダーの更新を適用します。
4. ワーカーとWebサーバーを再起動する：ディスク上のパッケージが新しくても、古いPHPワーカーが動き続けていれば切り替えは未完了です。Ubuntu公式も、PHPを使うアプリケーションの再起動が必要になり得ると案内しています。対象サービスが分からない場合は、保守担当者と再起動範囲を決めます。
5. 前後を照合する：更新後のパッケージ版と実行中のPHPを再確認し、主要画面、フォーム、ログイン、API、バッチ、エラーログを更新前の記録と比べます。「更新コマンドが成功した」だけで完了にしません。

経営者が決めるのは、更新に伴う停止時間、保守先への連絡、更新できないサービスの一時停止、侵害が疑われた場合の調査体制です。担当者だけに「念のため見ておいて」と渡すと、どこまで確認できれば完了なのかが曖昧になります。

更新できない間の一時対策はあるが、完全ではない

「一時対策は無い」のではありません。PHP公式の2件の勧告には設定上の緩和策があります。ただし、どちらの勧告も、修正を含むPHPへの更新だけが完全または信頼できる対策であり、一般的な設定変更ですべての経路を覆うことはできないと明記しています。

memory_limit=-1はPHP側のリクエスト単位の上限を外す設定です。資源設計をせずに入れると、可用性への別の影響が出かねません。PHP公式の勧告を保守担当者が読み、フロント側の制限、コンテナやホストの容量、監視と一緒に判断してください。設定名だけをコピーして全サーバーへ一律適用する運用は避けます。

別件との区別：JPCERT/CCは同じ注意喚起に、10月23日公表のCVE-2026-115560も追記しています。これはCVE-2026-109618・109619とは別の脆弱性で、特定の設定とアプリケーションコードの組み合わせで生じます。PHP公式は次の通常の修正版までsession.upload_progress.enabled=0を推奨しており、CVE-2026-109619の一時策としてすでに設定済みなら追加操作は不要と説明しています。

入られていないかは、公式の確認項目と一般的な追加確認を分ける

JPCERT/CCがこの脆弱性について挙げた確認項目

• 過去のHTTPレスポンスに、不自然に長い、または異常な形式の値を含むPHPSESSID Cookieが設定されていないか
• 不審なmultipart/form-data形式のHTTPリクエストがないか。その前後にPHPのメモリ上限に関するエラーやHTTP 500がないか
• PHPワーカープロセスが予期せず異常終了したり、頻繁に再起動したりした痕跡がないか
• 不審なプロセス、外部通信、ファイル作成など、侵害を示す別の痕跡がないか

重要なのは、これらが「全部なければ安全」というチェックリストではないことです。JPCERT/CCは、悪用経路が複数あり、単一の検知ルールではすべてを検出できず、ログの記録状況によっては痕跡が残らないと注意しています。異常が見つからなくても、攻撃を受けていないとは断定できません。

一般的な侵害確認として追加すること

ここからは、このCVE専用の検知項目ではなく一般的なインシデント確認です。修正前の期間を対象に、説明できないプロセスや外部通信、公開ディレクトリの新規・変更ファイル、管理者アカウント、定期実行、サービス設定、認証情報の利用記録を確認します。異常が疑われる場合は、ログやディスクの証拠を保全してから影響範囲を調べ、必要に応じてシステムを隔離します。

運用会社へ調査を依頼する場合は、「不審なアクセスはありましたか」だけで終えず、対象期間、保存しているアクセスログ・PHPエラーログ・プロセス監視・外部通信ログ、修正済み版へ切り替えた時刻を聞きます。保存していないログは後から確認できないため、未確認と無事を混同しないことが大切です。

戻せるかは、証拠保全の後に別環境で確かめる

JPCERT/CCの今回の注意喚起に、PHP専用のバックアップ復元手順はありません。公式が求めているのは、更新、侵害有無の調査、証拠保全、影響範囲の調査、必要な隔離です。バックアップ確認は一般的な復旧準備として、CVE固有の指示と分けて進めます。

バックアップが「ある」だけでは、戻せるとは言えません。次を非本番または隔離した環境で確かめます。

• 修正前の疑わしい期間より前で、業務上必要なデータを含む復元点があるか
• バックアップへ本番サーバーと同じ認証情報だけで到達できないか。世代が上書きされずに残っているか
• ファイル、データベース、アップロードを、どの順で戻すか記録されているか。侵害の疑いがあるシステムのAPIキーやトークンは古い値を復元せず、無効化して再発行する
• 暗号鍵は復号や証拠保全に必要なものを保全しつつ、侵害範囲を評価し、鍵の所有者がローテーション要否を判断できるか
• 修正済みPHPと確認済み設定でサービスを再構築し、主要機能を再現できるか
• 復元物に不審なファイル、設定、アカウント、定期実行が残っていないか

JPCERT/CCの侵入後対応FAQも、復旧前に侵入経路へ対処し、ネットワークへ戻す前にマルウェアや不正設定が除かれていることを確認するよう案内しています。これはランサムウェア向けの一般的な資料であり、今回のPHP脆弱性専用の手順ではありませんが、「古い状態へ戻すだけでは再侵害を防げない」という復旧判断に使えます。

侵害が疑われる状態で、証拠保全より先に本番をバックアップで上書きしないでください。復元できること、修正済みの構成で作り直せること、侵害原因を閉じられることの三つを別々に確認します。

Claude Code・MCP・社内エージェントは、PHPを通る経路だけ確認する

今回の公式文書は、Claude Code、MCP、社内AIエージェントそのものを脆弱な製品として挙げていません。AIツールを使っているという理由だけで、CVE-2026-109618・109619の対象になるわけではありません。名称ではなく、実装言語とリクエストの経路で判断します。

社内エージェントがPHPの管理画面やAPIを呼ぶ場合、エージェント本体がNode.jsやPythonでも、呼び出し先のPHPは別に確認が必要です。また、侵害が疑われた場合は、そのPHPシステムが保持していたAPIキーや接続権限、エージェントが取得・送信できたデータの範囲を確認し、疑わしいAPIキーやトークンは無効化して再発行します。バックアップ内の古い認証情報をそのまま復元してはいけません。これは「AIだから影響が拡大する」という断定ではなく、侵害されたWebワーカーの権限と接続先を棚卸しする一般的な影響調査です。

同じ10月21日に公開されたNode.jsの更新は別件です。MCPサーバーやエージェントがNode.jsで動く場合は、Node.jsの脆弱性（2026年10月）｜22・24・26系の更新と今やることで対象系列を切り分けてください。PHPとNode.jsをまとめて「AI基盤の脆弱性」と呼ぶと、担当と修正版を取り違えます。

経営者は停止判断、担当者は証拠付きの完了条件を持つ

更新できないシステムが残ったとき、担当者だけで抱え込ませないことも重要です。IPAは、外部アクセスの遮断やサービスの一時停止が必要かを、攻撃時の被害と業務影響を踏まえて判断するよう案内しています。長期間更新していないシステムでは、アプリ改修、資料不足、担当者不在、保守契約終了が障害になり得るため、経営層を含めて人員・予算・保守体制を決める必要があります。

サイバー攻撃全般の初動とAIを使う会社の確認項目は、AIサイバー攻撃とは｜中小企業の防御5手も参照してください。今回のPHP対応では、その一般的な枠組みに、JPCERT/CCが挙げたCookie、multipart、メモリ上限エラー、PHPワーカー再起動の確認を足します。

よくある質問

Q. WordPressのセキュリティプラグインを入れていれば更新不要ですか？

いいえ。PHP本体の脆弱性です。特にmod_phpではアプリケーションコードが始まる前に成立する確認済み経路があるため、WordPress側の認証やプラグインを修正済みPHPの代わりにはできません。

Q. php -vが8.3.6なら未修正ですか？

一概には言えません。Ubuntu 24.04 LTSなら、8.3.6-0ubuntu0.24.04.13が修正済みです。OSベンダーのパッケージ版を末尾まで確認し、Webで実際に動いているPHP-FPMやmod_phpも別に確認してください。

Q. PHP 8.1以前を使っています。どうすればよいですか？

PHPプロジェクトはPHP 8.1以前の通常の更新版を提供しません。今回の深刻度を踏まえ、PHP 7.4・8.0・8.1には最小限のソースバックポートがありますが、サポート再開や通常のバイナリー更新を意味しません。サポート中の系列へ移行するのが基本です。Ubuntuなどが修正パッケージを提供している場合は、そのOSと契約のサポート条件、修正済みパッケージ版を確認します。

Q. 一時対策を入れれば、更新を延期できますか？

安全とは言えません。PHP公式は、設定変更を特定の経路に対する緩和策と位置づけ、更新だけが完全または信頼できる対策だとしています。設定変更後も更新計画と侵害確認を止めないでください。

Q. 不審なログが見つからなければ、侵害されていませんか？

断定できません。JPCERT/CCは、悪用経路が複数あり、単一ルールですべてを検出できず、ログの残り方によっては痕跡がない場合もあると説明しています。ログがない期間や保存していない項目は「未確認」と扱います。

Q. Claude CodeやMCPサーバーも直ちに停止すべきですか？

製品名だけでは判断できません。Claude Codeの公式要件にPHPは含まれていません。MCPは複数言語で実装できるため、PHP製でWebリクエストを処理するサーバー、PHPの管理画面やAPIを呼ぶ連携先があるかを確認します。

Q. CVE-2026-115560も同じ修正版で直っていますか？

別件です。PHP公式は10月23日時点で、影響構成は一般的ではなく、次の通常のバグ修正版までsession.upload_progress.enabled=0を推奨するとしています。CVE-2026-109619の一時策として同設定を適用済みなら追加操作は不要です。

結論と次の一歩

2026年10月30日時点で、修正版はPHP 8.5.12・8.4.27・8.3.36・8.2.35です。10月29日のJPCERT/CC更新で変わったのは版ではなく、悪用状況の判断です。攻撃を試みる通信の観測報告に加え、特定製品で侵害成功を示唆する痕跡が追記されました。IPAは国内被害を把握していないとしていますが、それは各社のシステムが未侵害だという証明ではありません。

1. 対象を確定する：実際にWebリクエストを処理するPHPと、OS・組み込み製品のパッケージ版を記録します。
2. 修正を実行中にする：修正済み版へ更新し、すべての関係ワーカーを再起動し、更新後の版と主要機能を確認します。
3. 修正前の期間を調べる：JPCERT/CCの確認項目と一般的な侵害調査を分け、証拠を保全し、別環境で復元可能性を確かめます。

「更新済みパッケージがある」「設定を変えた」「ログに異常がない」は、それぞれ別の証拠です。三つを一つの完了報告にまとめず、更新、実行中の版、侵害確認、復旧可能性を分けて記録してください。

参考・出典

• PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起 — JPCERT/CC（2026年10月22日公開、10月29日更新、参照日：2026年10月30日）
• PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619） — IPA（2026年10月27日更新、参照日：2026年10月30日）
• Security advisory: Critical remote code execution vulnerabilities, update now — The PHP Group（2026年10月21日、参照日：2026年10月30日）
• RCE via OOM corruption — php/php-src GitHub Security Advisory（2026年10月21日、参照日：2026年10月30日）
• RCE via stale global state — php/php-src GitHub Security Advisory（2026年10月21日、参照日：2026年10月30日）
• Informational advisory: Session upload progress — The PHP Group（2026年10月23日、参照日：2026年10月30日）
• USN-8948-1: PHP vulnerabilities — Ubuntu（2026年10月21日、参照日：2026年10月30日）
• CVE-2026-109618・CVE-2026-109619 — Debian Security Tracker（参照日：2026年10月30日）
• Claude Code setup — Anthropic（参照日：2026年10月30日）
• MCP SDKs — Model Context Protocol（参照日：2026年10月30日）
• 侵入型ランサムウェア攻撃を受けたら読むFAQ — JPCERT/CC（2026年6月18日更新、参照日：2026年10月30日）