PHPの脆弱性php2shell｜対象はWeb要求を処理する環境

ニュースで php2shell の CVE 番号と修正版の版番号まで読めても、自社のサイトや社内システムで PHP が動いているかを答えられなければ、次に誰へ何を頼むかは決まりません。読み終えたときに手元に残るのは、制作会社やレンタルサーバーへそのまま送れる確認の文面です。

外部の記述は2026年10月22日に開いた公式の告知・公的機関の注意喚起・セキュリティ企業の解説の範囲で、悪用の状況は出典ごとの表記のまま並べます。当社の点検は自社サイト1つを同じ日に確かめた運用記録で、ほかの会社の環境が対象外であることや安全であることを示すものではありません。

php2shellとは、PHP本体に見つかった重大な脆弱性をまとめた通称で、認証なしで遠隔からコードを実行される恐れがある

php2shell とは、2026年10月21日に修正が公開された PHP 本体の脆弱性 CVE-2026-109618 と CVE-2026-109619 をまとめた通称です。どちらも Web の要求を処理する途中のメモリの扱いに欠陥があり、認証なしで遠隔からコードを実行される恐れがあります。GMO Flatt Security によると、この名前は発見に関与したと見られる研究者の投稿と開示に関与した Wiz の記事で使われています（GMO Flatt Security「PHPの重大な脆弱性「php2shell」（CVE-2026-109618、CVE-2026-109619）の概要と対応指針」／2026年10月22日閲覧）。

図は、自社が対象かを3つの問いで順に確かめる流れです。Web の要求を受ける形でなければ公式が挙げた対象の外で、版が古ければ対応の箱へ進み、中身が見えない機器は別にメーカーの告知で確かめます。

PHP プロジェクトは2026年10月21日に PHP 8.5.12・8.4.27・8.3.36・8.2.35 を公開し、この2件を修正しました。php.net は、すべての PHP 利用者に直ちに更新するよう強く勧めています（The PHP Group（php.net）「Security advisory: Critical remote code execution vulnerabilities, update now」／2026年10月22日閲覧）。

公開は当初、10月22日 14:00 UTC の予定でした。The PHP Foundation によると、10月20日（UTC）に CVE 番号が誤った公開時刻と誤った CVSS 10.0 とともに出回ったため、10月21日 14:00 UTC（日本時間23:00）へ1日前倒ししました。技術的な詳細は漏れていないとしています（The PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」／2026年10月22日閲覧）。10月20日の予告はすでに10月21日 14:00 UTC を公開日時とし、どちらかの詳細が公になった場合や悪用の証拠が出た場合はさらに早める可能性があると書いていました（The PHP Group（php.net）「Upcoming Critical PHP Security Release」／2026年10月22日閲覧）。

CVE-2026-109618 は、メモリ不足（OOM）のときの処理で要求のメモリが不正な状態のまま残り、遠隔コード実行に至るものです。影響を受けるのは 8.2.35・8.3.36・8.4.27・8.5.12 より前の版です（PHP（php/php-src, GitHub Security Advisory）「RCE via OOM corruption · GHSA-w8hw-w9fx-j79w」／2026年10月22日閲覧）。CVE-2026-109619 は、ある要求のメモリを指したままのグローバルな状態が解放後も残り、同じワーカーが次の要求を処理するときに使われてしまうものです。解放済みメモリの使用（use-after-free）などを経て遠隔コード実行に至り、修正版は CVE-2026-109618 と同じです（PHP（php/php-src, GitHub Security Advisory）「RCE via stale global state · GHSA-6wmf-4rv5-p3rp」／2026年10月22日閲覧）。

深刻度の数字は、評価する機関と CVSS（深刻度を点数にする共通の尺度）の版で違います。採番機関の PHP は2件とも CVSS v4.0 で 9.2 とし、NVD 自身の評価は CVSS v3.1 で 9.8 です（NIST National Vulnerability Database（NVD）「NVD CVE API 2.0: CVE-2026-109618」・NIST National Vulnerability Database（NVD）「NVD CVE API 2.0: CVE-2026-109619」／2026年10月22日閲覧）。

危険の度合いは実行方式で違い、Apacheに組み込むmod_phpが最も高い

php.net は、危険にさらされるのは Web の要求を処理するすべての PHP 環境だとして、PHP-FPM・Apache の mod_php・php-cgi・FrankenPHP・LiteSpeed を挙げています。最も危険度が高いのは mod_php で、アプリケーションのコードが動く前に認証なしの要求で攻撃が成立する実証済みの攻撃コードがあると書いています（The PHP Group（php.net）「Security advisory」／2026年10月22日閲覧）。並んでいるのは、Web サーバーが PHP を呼び出す方式（実行方式）の名前です。mod_php は Apache の中に PHP を組み込む形で、PHP-FPM は PHP を別のプロセスで動かす形です。

実行方式ごとの書きぶりは、出典の中でも違います。次の表は PHP の GitHub アドバイザリ2件と The PHP Foundation のブログの記述を並べたものです（PHP「GHSA-w8hw-w9fx-j79w」・PHP「GHSA-6wmf-4rv5-p3rp」・The PHP Foundation「Today's PHP Security Release」／2026年10月22日閲覧）。

PHP-FPM の書きぶりは出典で同じではありませんが、どちらを取っても更新を後回しにする理由にはなりません。確認された影響は、Web サーバーの作業用アカウント（Web ワーカー）の権限で認証なしにコードを実行されることです（PHP「GHSA-w8hw-w9fx-j79w」／2026年10月22日閲覧）。

Red Hat は、PHP が入っていないシステムや、信頼できない HTTP 要求に PHP をさらしていないシステムは影響を受けないと明記しています。標準的な RHEL は PHP-FPM を使い、FPM のワーカーは初期化の早い段階で失敗すると終了するので実際には遠隔コード実行は難しく、既定設定の mod_php の方が危険は高いとしています。直接影響を受けるのは RHEL 10・9・8 などで、RHEL 7 以前の PHP は影響を受けません（Red Hat「RHSB-2026-013（PHP request handling memory corruption: CVE-2026-109618, CVE-2026-109619）」／2026年10月22日閲覧）。

つまりコマンドライン用だけの PHP（Web の要求を受けない形）と、PHP を実行しないサイトは公式が挙げた対象の外にあります。Node.js や Python で動くサイトについて php.net が個別に書いているわけではなく、Web の要求を処理する PHP が無ければ挙げられた対象に当たらない、という読み方です。同じ会社の別のサイトや社内システムに PHP があれば、そちらは対象になりえます。

自社が対象かは、サイトと社内システムの置き場所を順に見てPHPが動いているかを確かめる

最初の作業は棚卸しです。IPA は、開発・運用しているプログラムのうち PHP を使っているものを可能な範囲で棚卸しするよう求めています。製品や機器の内部で使われている PHP は利用者側で把握できない場合があるので、まずマニュアルや提供元のセキュリティ情報を見るよう案内しています（独立行政法人情報処理推進機構（IPA）「【事前準備のお願い】PHPのセキュリティリリース公開予定について」／2026年10月22日閲覧）。

当社が2026年10月22日に自社サイトで確かめた順番は次のとおりです。

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

外部への要求は DNS の照会と HEAD／GET の要求（ページを取りに行く普通の要求）だけで、攻撃コードや細工した要求は送っていません。結論が出たあとに同じ確認をやり直し、見落としを別に探しました。結論は、当社のサイトは PHP を実行しない構成で今回の2件の対象ではない、というものです。

入口の応答から分かるのは入口のことだけなので、ヘッダーに実行環境の名前が無いことだけでは結論にせず、ファイルと設定まで見ています。点検の途中では、ブラウザ以外からの要求に配信元の確認画面が返っていることにも気づきました。検索エンジンが読めているかを Search Console の公開 URL テストで確かめ、「URL は Google に登録できます」と出ることを確認しています。

自社に置き換えるときは、次の置き場所を順に見ます。

• 公開サイトの住所: 昔のキャンペーン用の住所や移転前のサイトが残っていないか
• 問い合わせフォームや会員ページ: サイトの本体と別の仕組みで動いていないか
• 社内システム: 勤怠や顧客管理を自社のサーバーで動かしていないか
• 開発や制作に使う端末: PHP が Web の要求を受ける形で動いていないか
• 管理画面を持つ機器: ルーター・NAS・複合機などはメーカーの告知を見る

置き場所ごとに何が動き誰が管理者かを書き残す台帳の作り方は、ホームページの改ざん対策にまとめました。

版を確かめるときは、どの PHP の版かを取り違えないようにします。php -v を実行すると SAPI 名（PHP をコマンドラインと Web サーバーのどちらの入口で動かしているかを示す名前）と版が表示され、出力の「(cli)」はコマンドライン用の PHP の版であることを示します（The PHP Group（php.net）「PHP Manual: Command line options」／2026年10月22日閲覧）。Web 側で動いている版は、現在動作中の PHP パーサーの版を返す phpversion() 関数で取れます（The PHP Group（php.net）「PHP マニュアル: phpversion」／2026年10月22日閲覧）。Web 側の版は、管理画面か提供元の回答で確かめるのが取り違えの少ない方法です。確認用の PHP ファイルを公開の場所に置いたら、確かめた後すぐに消します。当社が要求を送った探られやすいパスにも、phpinfo.php が入っていました。

PHPを使っているなら修正版へ上げ、サポートが切れた版は更新か停止かをすぐ決める

修正版は PHP 8.5.12・8.4.27・8.3.36・8.2.35 で、使っている系列ごとにこの版以上へ上げます。すぐに更新できない場合の設定変更について、php.net は特定の攻撃経路への露出を減らすだけで導入環境を安全にはしないと明記し、完全な解決は更新だけだとしています（The PHP Group（php.net）「Security advisory」／2026年10月22日閲覧）。CVE-2026-109619 のアドバイザリも、あらゆる経路を覆う汎用の設定による緩和策は無いとしています。セッションのアップロード進捗機能は既定で有効で、アプリケーションが session_start() を呼ばなくても攻撃の材料になりうるとも書いています（PHP「GHSA-6wmf-4rv5-p3rp」／2026年10月22日閲覧）。セッションを使っていないサイトだから関係ない、とは言えません。

PHP 8.1 以前には、PHP プロジェクトからの更新がもう出ません。php.net は、一部のディストリビューションや LTS ベンダー（公式のサポートが切れた版にも修正を出し続ける事業者）が修正を移植しているので提供元に問い合わせるか、サポート中の版へ上げるよう案内しています。ソースから自分でビルドする人向けには、PHP 7.4・8.0・8.1 用の最小限のソース修正（バックポート）も出ています（The PHP Group（php.net）「Security advisory」／2026年10月22日閲覧）。Tenable の FAQ によると、研究者の Calif の解説では最も古い影響を受けるコード経路は PHP 5.4.0 までさかのぼり、PHP 5.4〜7.3 には PHP プロジェクトからの修正がありません（Tenable「php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions about critical PHP remote code execution vulnerabilities」／2026年10月22日閲覧）。

提供元が修正を移植していなければ、サポートが切れた版で決めることは、サポート中の版へ上げるか上げ終わるまで止めるかです。CERT-EU は直ちにパッチを当てるよう勧め、それができない場合は修正の適用と確認が済むまで、インターネットに面したアプリケーションを公開ネットワークから切り離すことを検討するよう求めています（CERT-EU「Security Advisory 2026-018: Critical Vulnerabilities in PHP」／2026年10月22日閲覧）。止めるかどうかは問い合わせや売上への影響と比べる経営の判断なので、技術の担当だけに預けません。

8.2.35 へ上げた場合は、次の予定も同時に決めます。php.net のサポート版一覧では PHP 8.2 のセキュリティ修正は2026年12月31日までで、8.3 は2027年12月31日、8.4 は2028年12月31日まで続きます（The PHP Group（php.net）「Supported Versions」／2026年10月22日時点の記載）。8.2 で今回の更新を済ませた場合は、年内にもう一度、8.3 以降へ移る段取りが要ります。

レンタルサーバーや制作会社に任せているサイトは、更新したかを相手に確かめる

サーバーの管理を任せているなら、PHP の版を上げられるのは権限を持つ相手の側なので、更新したかは相手に確かめます。

WordPress などで作ったサイトが対象かは、WordPress の版ではなく、下で動いている PHP 本体の版と実行方式で決まります。CVE-2026-109618 の mod_php の経路はアプリケーション固有のコードが動き出す前に起きるので、WordPress を最新にしていても PHP 本体が修正前なら対象から外れません（PHP「GHSA-w8hw-w9fx-j79w」／2026年10月22日閲覧）。Tenable の FAQ によると、研究者の Calif は WordPress・Drupal・Joomla・Magento など人気の PHP アプリケーションの特定の版に対して、認証前の遠隔コード実行を確認したと述べています（Tenable「php2shell FAQ」／2026年10月22日閲覧）。

相手に送る文面は、次の程度で足ります。

当社のサイト（URL）が動いているサーバーの PHP について伺います。10月21日に公開された修正版（8.5.12・8.4.27・8.3.36・8.2.35 のいずれか以上）への更新は済んでいますか。済んでいれば更新した日を、まだであれば予定の日を教えてください。更新は御社で行うのか、当社で版を切り替える必要があるのかもあわせて教えてください。

返事が「8.1 以前のまま」なら、前の節の更新か停止かの判断に戻ります。返事が来ないときや、サーバーの管理画面に自社の名義で入れないときは、名義と権限の問題が先にあります。ベンダーロックインの対策で書いたとおり、アカウントは発注側の名義か管理者の権限で持っておくのが前提です。持てたら、二段階認証もその管理者のアカウントから有効にします。

情シスがいない会社では、問い合わせる人と止めるかを決める人を次の告知の前に分けておきます。情シスがいない会社のAI導入で書いた決める人と手を動かす人の分け方が、ここでも使えます。相手に聞かないと版さえ分からない状態から抜け出す道筋は、内製化の記事にまとめています。

悪用の状況は報告によって表記が割れていて、試みの観測と侵入の確認は別である

悪用されているかどうかは、同じ日に読んだ範囲でも出典ごとに書き方が違います。「悪用が始まった」とも「まだ大丈夫」ともひとまとめには言えないので、日付と表記をそのまま並べます（表の出典はいずれも2026年10月22日閲覧）。

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

書かれているのは「機能する攻撃コードは確認していない」から「悪用の試みを観測している」までの幅です。試みの観測は攻撃の要求が届いていることを示すもので、どこかのサイトが侵入されたことを示すものではありません。本記事で引いた出典の中に、侵入の被害の件数や対象を示した記述はありません。

逆に、KEV に載っていないことも安全の根拠にはなりません。KEV は悪用が確認された脆弱性を CISA がまとめた一覧で、確認した版（2026年10月21日公開・1754件）に載っていないというだけです。PHP の脆弱性では、CVE-2024-4577（2024年6月12日追加）や PHP-FPM の CVE-2019-11043（2022年3月25日追加）がこれまでに載っています（CISA（米国サイバーセキュリティ・インフラストラクチャ安全保障庁）「Known Exploited Vulnerabilities Catalog（JSON feed）」／2026年10月22日閲覧）。

対応は、悪用の確定を待たずに更新へ進むほうに寄せます。Rapid7 も、通常のパッチの周期とは別に緊急で更新するよう勧めています（Rapid7「CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP」／2026年10月22日閲覧）。

出回っている攻撃コードで自社のサイトを試すことは勧めません。Tenable は、出回る攻撃コードとされるものが動くかを検証しておらず、未検証の攻撃コードにはマルウェアが仕込まれていることがあると注意しています（Tenable「php2shell FAQ」／2026年10月22日閲覧）。確かめるのは版と実行方式で、攻撃が通るかではありません。

php2shellについてよくある質問

Q. WordPressのプラグインやテーマを更新すれば対策になりますか？

なりません。php2shell は PHP 本体の欠陥で、修正は PHP 8.5.12・8.4.27・8.3.36・8.2.35 として出ています（The PHP Group（php.net）「Security advisory」／2026年10月22日閲覧）。下で動く PHP 本体の版を、プラグインの更新とは別に上げます。

Q. 社内向けのシステムだけでPHPを使っている場合も、急ぐべきですか？

急ぎます。社内向けでも PHP が Web の要求を処理していれば、php.net が挙げた対象に入ります。Red Hat は信頼できない HTTP 要求に PHP をさらしていないシステムは影響を受けないとしていますが（Red Hat「RHSB-2026-013」／2026年10月22日閲覧）、社内から届く要求をすべて信頼できると言い切れるかは別の問題です。インターネットに面したものを先にし、社内向けのものも続けて更新します。

Q. ルーターや複合機は関係ありますか？

関係する場合があります。ただし中身を自分で調べるのではなく、マニュアルやメーカー・提供元のセキュリティ情報を見ます。IPA は、すべての製品について内部での PHP の利用の有無を個別に確かめるよう求めるものではないとしています（IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」／2026年10月22日閲覧）。インターネットから管理画面に届く機器から先に見ます。

Q. ログにエラーが出ていなければ、攻撃されていないと言えますか？

言えません。CVE-2026-109619 のアドバイザリは、ログにエラーが無いことは安全の証明にならないと書いています（PHP「GHSA-6wmf-4rv5-p3rp」／2026年10月22日閲覧）。修正前の版を Web に出していた期間があるなら、更新を先に済ませたうえで、専門の事業者に調べてもらうかを決めます。

SAIの視点：PHPを実行しない構成でも、棚卸しはWebサイトの外まで広げる

点検で PHP が見つかったのは、サイトではなく最後に見た社内の開発用の端末でした。サイトの構成を確かめる手順は配信元とファイルと設定を見るので、手元の端末はその範囲の外にあります。

端末の PHP は、php -v で見ると「(cli)」付きの修正前の版でした。この表示だけでは、Web の要求を受ける形で動いているかは分かりません。当社は版とは別に簡易サーバーや FPM の起動と待ち受けの有無を確かめ、公式が挙げた対象の外と判断したうえで更新の対象に入れました。版と動かし方は別の問いなので、棚卸しの表でも別の列に分けて書きます。

置き場所ごとに誰が PHP を更新し誰が停止を決めるかを社内で答えられる状態も、FDE伴走開発で目指す運用の一部だと当社は考えています。

自社のサイトと社内システムのどこかで、PHP が Web の要求を処理しているか。答えが出ないまま任せている相手に文面を送ったなら、返ってきた PHP の版と実行方式の名前を、サイトの URL と一緒にお問い合わせへ送ってください。返事がまだのときは、制作会社やレンタルサーバーの名前が分かる範囲で書いてあれば足ります。

出典と確認日

外部の出典はいずれも2026年10月22日閲覧（php.net のサポート版一覧は同日時点の記載）。悪用の状況は各出典の記載時点の表記で、その後に更新されている場合がある。当社の記録は2026年10月22日の自社サイトの点検で、他社の環境を判定するものではない。

• The PHP Group（php.net）「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日）
• The PHP Group（php.net）「Upcoming Critical PHP Security Release」（2026年10月20日）
• The PHP Group（php.net）「Supported Versions」
• The PHP Group（php.net）「PHP Manual: Command line options」
• The PHP Group（php.net）「PHP マニュアル: phpversion」
• PHP（php/php-src, GitHub Security Advisory）「RCE via OOM corruption · GHSA-w8hw-w9fx-j79w」
• PHP（php/php-src, GitHub Security Advisory）「RCE via stale global state · GHSA-6wmf-4rv5-p3rp」
• NIST National Vulnerability Database（NVD）「NVD CVE API 2.0: CVE-2026-109618」
• NIST National Vulnerability Database（NVD）「NVD CVE API 2.0: CVE-2026-109619」
• CISA（米国サイバーセキュリティ・インフラストラクチャ安全保障庁）「Known Exploited Vulnerabilities Catalog（JSON feed）」（catalogVersion 2026.10.21 の版）
• The PHP Foundation「Today's PHP Security Release, and How We're Strengthening PHP Security」（2026年10月21日）
• CERT-EU「Security Advisory 2026-018: Critical Vulnerabilities in PHP」
• 独立行政法人情報処理推進機構（IPA）「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（2026年10月21日）
• Red Hat「RHSB-2026-013（PHP request handling memory corruption: CVE-2026-109618, CVE-2026-109619）」
• Rapid7「CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP」
• Tenable「php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions about critical PHP remote code execution vulnerabilities」
• GMO Flatt Security「PHPの重大な脆弱性「php2shell」（CVE-2026-109618、CVE-2026-109619）の概要と対応指針」
• 当社の運用記録: 2026年10月22日の自社サイトの点検（外部への要求は DNS の照会と HEAD／GET の要求だけ）