PHPの重大な脆弱性（PHP2Shell）への対応｜影響の確認と更新・移行の進め方

2026年10月21日、PHPの開発チームは、認証なしで遠隔からコードを実行される（リモートコード実行）おそれのある重大な脆弱性2件を修正したセキュリティリリースを公開しました。企業サイトや業務システムがPHPで動いているなら、まず本番環境のPHPが対象のバージョンかを確かめ、修正版（8.5.12・8.4.27・8.3.36・8.2.35）へ更新することが対応の中心になります。

ただし、脆弱性が公表されたことと、自社のシステムが実際に攻撃を受けたことは別の話です。この記事では、システムの担当者と経営者が「何を確認し、どの順で動けばよいか」を、次の流れで整理します。

• 今回何が起きたのか、自社にどう関係するのか
• 自社が対象かどうかの確かめ方と、委託先への聞き方
• 今すぐ進める対応の順番と、すぐに更新できないときの暫定策
• サポートが終了した古いPHPを使っている場合の考え方
• 同じ問題で慌てないための運用の備え

今回のPHPの脆弱性では、何が起きたのか？#

**PHP本体に、認証なしの遠隔コード実行につながる脆弱性が2件見つかり、修正版が公開されました。**PHPの公式サイトは、Webのリクエストを処理しているすべてのPHPが影響を受けるとし、すぐに更新するよう強く呼びかけています。

公式サイトのセキュリティアドバイザリ（Security advisory: Critical remote code execution vulnerabilities, update now｜The PHP Group）と、事前告知（Upcoming Critical PHP Security Release｜The PHP Group）に書かれている要点は次のとおりです。

• 2件の脆弱性 — メモリ不足（OOM）の処理に関わるもの（CVE-2026-109618）と、リクエストの間で残ってしまう内部の状態に関わるもの（CVE-2026-109619）。事前告知では、どちらも深刻度の指標であるCVSS v4.0で9.2と評価されている
• 影響を受ける動かし方 — PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedを含め、Webのリクエストを処理しているすべてのPHP。公式はmod_phpのリスクがもっとも高いとし、アプリケーションのコードが動く前に、認証のないリクエストで攻撃が成立することが実証されているとしている
• 修正版 — PHP 8.5.12、8.4.27、8.3.36、8.2.35
• 完全な回避策はない — 各修正版のリリース告知には、完全な緩和策はなく、更新だけが安全な選択肢だと書かれている

日本では、IPA（情報処理推進機構）が2026年10月22日に注意喚起を掲載しています。IPAは、これらの脆弱性の組み合わせが「PHP2Shell」と呼ばれていること、影響を受けるのは8.2.35より前の8.2系から8.5.12より前の8.5系までのバージョンであることを示し、修正版への更新を求めています。あわせて、調査に関わったWiz社の情報として、PHP 5.4以降のバージョンはいずれかの脆弱性の影響を少なくとも受けるとしています（出典：PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)｜IPA）。IPAのページは、追記すべき情報があれば更新するとしているので、対応の途中でも見直してください。

自社の何が関係するのか？#

**PHPで動いているWebサイトや業務システムを公開・運用していれば、関係します。**自社でPHPのプログラムを書いた覚えがなくても、次のようなものはPHPで動いていることがあります。

• WordPressなど、PHPで作られたCMSで運用している企業サイトやオウンドメディア
• 予約・問い合わせ・会員登録のフォームや、ECサイト
• 外部の開発会社に作ってもらった社内の業務システムや管理画面
• パッケージ製品やサービスとして提供を受けているシステム

IPAは、自組織で開発・利用している製品等の影響については、その製品等の開発者やサービス提供元からの情報を確認するよう案内しています。製品として導入しているシステムは、提供元の発表を待つだけでなく、こちらから問い合わせてください。

自社のシステムが対象かどうかは、どう確かめる？#

**本番環境で実際に動いているPHPの正確なバージョンと、動かし方、提供元の修正状況の3点を確かめます。**ソースコードのリポジトリや設計書に書かれたバージョンは、あくまで「その時点で想定していた版」であり、本番環境で動いている版を示すとは限りません。

確かめる項目は、次の表にまとめました。

バージョンを確かめるときの注意点は？#

よくある見落としの一つは、サーバーに複数のPHPが入っていて、確かめた版とWebで動いている版が違うことです。コマンドラインで表示されるPHPと、Webサーバーから呼ばれているPHPが別のものである場合があるため、Webのリクエストを処理しているPHP（PHP-FPMのプールやApacheのモジュール）の版を確かめてください。

もう一つは、OSのパッケージで入れたPHPの場合、修正が入っていても、バージョン番号が公式の修正版と同じにならないことがある点です。一般に、Linuxディストリビューションは、修正を各ディストリビューションが配布している版に移植（バックポート）して提供することがあるためです。PHPの公式アドバイザリは、Linuxディストリビューションや長期サポート（LTS）を提供するベンダーには事前に修正が渡されているとして、各ベンダーの更新パッケージを確認するよう求めています。番号だけで判断せず、そのベンダーのセキュリティ情報で、2つのCVE番号に対応したパッケージかを確かめます。

委託先や提供元には、何を聞けばよいか？#

保守を委託している会社やホスティング会社には、次の5点をそのまま聞いてください。回答を記録に残しておくと、社内への報告や取引先からの問い合わせにも使えます。

1. 1弊社のシステムで、本番環境で動いているPHPのバージョンと、動かし方（PHP-FPM・mod_phpなど）を教えてください。
2. 2今回のPHPの脆弱性（CVE-2026-109618、CVE-2026-109619）の影響を受けますか。
3. 3影響がある場合、修正版への更新はいつ、どの手順で行う予定ですか。更新の前にバックアップを取り、検証環境で動作を確認する予定はありますか。
4. 4更新までの間に、アクセスの制限などの暫定的な対策は取れますか。
5. 5更新後に、動作の確認とアクセス記録の確認を行い、結果を共有していただけますか。

「そもそもPHPを使っているかどうかも分からない」という場合は、サイトやシステムの一覧と、それぞれの保守の窓口を洗い出すところから始めます。窓口が分からないシステムがあれば、それ自体が今回いちばん急いで手当てすべき対象です。

今すぐ、どの順番で対応すればよいか？#

**影響の確認から本番反映後の確認まで、5つの順番で進めます。**バックアップと検証を飛ばして本番環境を更新すると、アプリケーションが動かなくなったときに元に戻せないおそれがあります。

1. 1影響を確かめる — 本番のPHPのバージョン・動かし方・入手元を確かめ、更新の対象を決める
2. 2バックアップと復元の手順を確かめる — プログラム・設定・データのバックアップを取り、戻す手順を確認する
3. 3検証環境で試す — 本番と同じ構成で修正版に上げ、主要な画面と処理が動くかを確かめる
4. 4本番環境に反映する — 利用の少ない時間帯を選び、関係者に告知したうえで更新する
5. 5動作とアクセス記録を確かめる — 更新後の動作と、不審なアクセスや見慣れないファイルが無いかを確かめる

なお、手順5で痕跡が見つからないことは、侵害が無いことの証明にはなりません。判断に迷う場合は、専門の調査会社などに調査を依頼してください。

同じ系列の中の更新（たとえば8.3系の古い版から8.3.36へ）は、バグ修正とセキュリティ修正が中心で、大きな改修が要らないことが多い更新です。それでも、拡張機能やアプリケーションの作りによっては動作が変わることがあるので、手順3は省かないでください。検証環境が無い場合は、本番環境の複製を一時的に作るか、更新の直後に確かめる画面と処理の一覧を先に用意しておきます。

すぐに更新できないときは、何をすればよいか？#

**暫定策で時間を稼ぎつつ、更新の期限を決めます。**暫定策はあくまで更新までのつなぎで、それだけで安全になるわけではありません。考えられる手段は次の3つです。

• 公式の軽減策を使う — PHPの公式アドバイザリには、memory_limit や post_max_size、session.upload_progress.enabled などの設定で、特定の攻撃経路を減らす方法が示されています。ただし同じアドバイザリが、これらは特定の経路を減らすだけで、安全な状態にするものではないと明記しています。設定する値と設定する場所（php.ini やPHP-FPMのプールの設定など。ini_set() や .user.ini には頼れないとされている項目がある）、ワーカーの再起動まで、アドバイザリの記載どおりに行う必要があります。アプリケーションへの影響も確かめたうえで変更します
• 公開する範囲を絞る — 社内向けの管理画面や業務システムは、社内ネットワークや特定の拠点のIPアドレスからだけアクセスできるようにする。使っていないフォームや機能は止める
• 停止するかを判断する — IPAは、有効な暫定対策を講じることが難しい場合、攻撃を受けた際の被害や業務への影響を踏まえ、外部からのアクセス遮断やサービスの一時停止が必要か判断するよう求めています。個人情報や決済に関わるシステムほど、この判断を先送りしないでください

暫定策を講じたら、「誰が、いつまでに、どの版へ更新するか」を決めて記録します。期限の無い暫定策は、そのまま恒久的な運用になりがちです。

サポートが終了した古いPHPは、どうすればよいか？#

**PHP 8.1以前には、8.2.35のような公式の修正版は出ません。サポートが続くPHPへの移行を基本に、移行までの暫定策と期限を決めます。**公式アドバイザリは、8.1以前はPHPプロジェクトからの更新が無くなっているとしたうえで、一部のディストリビューションやLTSベンダーが修正を移植（バックポート）して提供していることを示しています。あわせて、ソースから自前でビルドしている場合やLTSベンダーを利用できない場合に向けて、PHPのセキュリティチームが7.4・8.0・8.1用の最小限の修正パッチを公開しています。

PHPの各系列のセキュリティサポートの期限と、当面の対応は次のとおりです（出典：Supported Versions｜The PHP Group）。

注意したいのは8.2系です。今回の修正版8.2.35で脆弱性は解消できますが、PHPの公式サイトは、8.2系は2026年12月31日にサポートを終え、それ以降はセキュリティ修正を受けられないとしています。8.2.35への更新は当面の対策として行い、あわせて移行を計画してください。8.3系もセキュリティサポートは2027年12月31日までなので、移行先は期限に余裕のある8.4系・8.5系を候補にし、少なくとも8.3系以降を選びます。8.1以前から8.2系に上げるだけでは、短い期間で再びサポート切れの状態に戻ります。

移行の前に、何を調べるのか？#

PHPの系列をまたぐ移行では、PHP本体だけでなく、その上で動くものがすべて新しい版で動くかを調べます。

• フレームワーク — 使っているフレームワークの版が、移行先のPHPに対応しているか。対応していなければ、フレームワークの更新も必要になる
• 拡張機能と依存ライブラリ — 使っている拡張機能や外部のライブラリが、移行先のPHPで提供・保守されているか
• アプリケーションのコード — 新しい版で使えなくなった書き方や、動きが変わった関数を使っていないか
• 動作確認の範囲 — 主要な画面・帳票・外部連携・バッチ処理を、どこまで確かめるか

調べた結果は、改修の工数、停止が必要な時間、業務への影響の3点で整理し、「すぐ必要な対応」と「期限を決めて進める移行」に分けます。

すぐに移行できないときは？#

**提供元による修正の移植と、アクセスの制限を組み合わせて暫定策とし、移行の期限を決めます。**OSやホスティングの提供元が修正を移植した更新を出しているなら、それを適用します。対応済みのパッケージかどうかは提供元のセキュリティ情報で2つのCVE番号への対応が明記されているかで確かめ、自社のサーバーに入っているパッケージの版がそれ以降になっているかを照合します。

IPAは、長期間更新していないシステムでは、開発時の資料やノウハウの不足、担当者の不在、保守契約の終了などで対策が難しくなっている場合があるとし、経営層も含めて、更新・移行とその後の維持管理に必要な人員・予算・保守体制を確保できるか検討するよう求めています。体制を確保する見通しが立たない場合は、保守を受けられる製品・サービスへの移行や、機能の縮小、公開の終了やシステムの廃止も選択肢に入れて検討するよう示しています。古いシステムの段階的な刷新の進め方は、基幹システム（レガシー）刷新の進め方｜2025年の崖・移行リスク・段階移行で解説しています。

次に同じ問題が起きたとき、慌てないためには？#

**どのシステムがどの版で動いているかを常に把握し、脆弱性が出たときに誰が何をするかを先に決めておきます。**今回の対応で慌てた点は、そのまま次の備えの材料になります。

• どこで何が動いているか分からない → 台帳とサポート期限を管理する — システムごとに、PHP・フレームワーク・OS・主な依存ライブラリの版と、それぞれのサポート期限を一覧にする
• 誰が判断するか決まっていない → 役割の分担を決めておく — 脆弱性情報を受け取る担当、影響を判断する担当、顧客や取引先への連絡の担当、更新作業の担当を決める
• 本番環境でいきなり更新する → 検証してから定期的に更新する — 検証環境と自動テストを用意し、緊急時だけでなく平時から定期的に更新する
• 戻せるかどうか分からない → 復元と停止の判断を準備する — バックアップから実際に戻せるかを定期的に試し、緊急時にどんな条件でシステムを止めるかを決めておく

台帳には、最低限、次の項目があれば今回のような確認にすぐ使えます。

保守契約を結んでいる場合は、脆弱性への対応がどこまで契約の範囲に含まれているかも確かめてください。定期的な更新や緊急時の対応が契約に入っていなければ、今回のような更新のたびに個別の見積もりと調整が必要になります。保守契約の内訳と見直し方は、システムの保守・運用費用の相場は？内訳・契約形態・見直しのポイントで整理しています。

まとめ#

今回のPHPの脆弱性への対応で押さえたいのは、次の点です。

• 2026年10月21日に、認証なしの遠隔コード実行につながる重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）の修正版、PHP 8.5.12・8.4.27・8.3.36・8.2.35が公開された。完全な回避策はなく、更新が対応の中心になる
• まず本番環境で動いているPHPのバージョン・動かし方・入手元を確かめる。OSのパッケージは、番号ではなく提供元のセキュリティ情報で対応済みかを確かめる
• 影響の確認、バックアップと復元の確認、検証環境での確認、本番反映、反映後の確認の順に進める
• すぐに更新できない場合は、公式の軽減策・公開範囲の絞り込み・停止の判断を組み合わせ、更新の期限を決める
• 8.2系はセキュリティサポートが2026年12月31日に終わる。8.1以前は公式の修正版が無いため、期限に余裕のある版への移行を計画する
• 台帳、役割の分担、定期的な更新、復元と停止の準備を運用に組み込み、次の脆弱性に備える

まずは、自社で動いているWebサイトと業務システムを一覧にし、それぞれの保守の窓口に、前述の委託先への5つの質問を送るところから始めてください。

よくある質問（FAQ）#

Q. 自社でPHPを使っているかどうか分かりません。どう確かめればよいですか？

A. サイトやシステムの一覧と保守の窓口を洗い出し、窓口に本番環境のPHPのバージョンを問い合わせるのが確実です。WordPressなどのCMSや、外部の会社に作ってもらった業務システムがPHPで動いていることがあります。

Q. 脆弱性が公表されたということは、自社のサイトはすでに攻撃されたのですか？

A. 脆弱性があることと、実際に攻撃を受けたことは別です。まず修正版への更新を進め、あわせてアクセス記録や見慣れないファイルが無いかを確かめてください。不審な点が見つかった場合は、更新とは別に、被害の範囲の調査が必要になります。判断に迷う場合も、調査を検討してください。

Q. 設定を変えれば、更新しなくても大丈夫ですか？

A. 大丈夫ではありません。PHPの公式アドバイザリは、設定による軽減策は特定の攻撃経路を減らすだけで安全な状態にするものではないとし、各修正版のリリース告知も、完全な緩和策はなく更新だけが安全な選択肢だとしています。

Q. レンタルサーバーやホスティングを使っている場合は、何をすればよいですか？

A. 提供元のお知らせを確認し、PHPの版を自分で切り替える方式のサービスなら、修正版の入った版に切り替えます。提供元がPHPを管理している場合も、いつ対応されるのか、どの版になるのかを問い合わせて記録してください。

Q. PHP 8.2を使っていますが、8.2.35に上げれば十分ですか？

A. 今回の脆弱性への対策としては有効ですが、8.2系は2026年12月31日にサポートが終わり、それ以降はセキュリティ修正を受けられません。8.2.35への更新とあわせて、移行を計画してください。8.3系も2027年12月31日に期限を迎えるため、移行先は8.4系・8.5系を候補にします。

PHPのバージョンや対応の要否が分からない方も、ご相談ください#

PHPのバージョンや対応の要否が分からない方も、まずは現在の状況をご相談ください。確認すべき範囲と、対応の優先順位を一緒に整理します。

弊社（株式会社TryWith）は、システム受託開発の中で、リリース後の障害対応やサーバー監視を含む継続的な保守・運用サポートと、既存システムのモダナイゼーションを手がけています。他社が開発したシステムでも、既存コードのレビューから現状を把握したうえで、開発を担う立場から次のようなご相談に応じます。

• 影響の確認 — 本番環境のPHPのバージョン・動かし方・入手元を確かめ、対象かどうかを整理する
• 更新の進め方の整理と実施 — バックアップと検証の手順を決め、修正版への更新と更新後の確認を進める
• 古いPHP環境の移行 — フレームワーク・拡張機能・依存ライブラリへの影響を調べ、改修の範囲と移行の計画を立てる
• 継続的な保守 — 台帳づくりや定期的な更新など、次の脆弱性に備える運用を整える

対応の範囲と時期は、状況をお伺いしたうえでご提案します。お問い合わせの際は、分かる範囲で、対象のサイト・システム、PHPのバージョン、サーバーやホスティングの種類、保守会社の有無、ご希望の時期をお知らせください。

お問い合わせはこちら