PHP2Shell（CVE-2026-109618とCVE-2026-109619）：PHPを使う企業がいますべきこと

ノートパソコンを手にサーバーラックで作業する技術者

2026年10月21日、PHPプロジェクトはPHP 8.5.12、8.4.27、8.3.36、8.2.35をリリースし、「認証なしでのリモートコード実行を許す可能性がある」2つの脆弱性を修正しました。平たく言えば、自社のWebサイトにHTTPリクエストを送れる人なら誰でも、自社のサーバーで自分のコードを実行できるおそれがあるということです。パスワードは要らず、構成によっては、アプリケーションが1行も実行しないうちに攻撃が成立します。この2つはPHP2Shellと名付けられ、PHPはどちらも9.2（CVSS 4.0、10点満点）と評価しています。

このガイドは、対応しなければならない人のためのものです。PHPで動くWebサイトやオンラインショップの所有者、IT管理者、そしてPHPの運用を委託先に任せているすべての人です。リリースの翌日である2026年10月22日に、PHPプロジェクト自身のアドバイザリ、各国のサイバーセキュリティ機関のガイダンス、ベンダーが公表した数字をもとに書きました。情報源の間で食い違いがある箇所は、そう明記しています。

要点

PHP本体を更新し、再起動してください。 WordPress、Drupal、Laravel、プラグインを更新しても、これは直りません。欠陥はアプリケーションの下にある、PHPそのものにあります。
PHPによれば、Webリクエストを処理するPHP環境はすべて対象です。PHP-FPM、mod_phpを使うApache、php-cgi、FrankenPHP、LiteSpeedです。PHPは、mod_phpを使うApacheのリスクが最も高いとしています。
PHPで動くWebサイトの半数近くは、PHPプロジェクトがもうリリースを出していないブランチで動いています（W3Techsのデータを当社が読み解いた結果。後述）。それらには、インストールできる公式パッケージがありません。
設定とファイアウォールで稼げるのは時間であって、安全ではありません。 PHPは暫定対策を挙げたうえで、それらは「環境を安全にするものではない」と述べています。
今日パッチを当てられないなら、 米国、英国、EUの機関の助言は同じです。当てられるようになるまで、そのシステムをインターネットから切り離してください。

これまでの経緯

2026年8月19日。 Wizの公開情報によれば、Wizの研究者が最初の欠陥を見つけ、8月24日にPHPのセキュリティチームに報告しました。PHPのアドバイザリには、ほかの複数の企業の研究者の名前も挙げられています。
10月20日。 予定されていた公開の2日前に、CVE番号がネット上に漏れました。PHPはリリースを1日前倒しして10月21日14:00 UTCとし、全員に準備するよう呼びかけました。
10月21日 03:02 UTC。 Cloudflareは、同社のWAFを利用するすべての顧客に対し、無料プランも含めてファイアウォールルールを有効にしました。同社は後に「当社の顧客を狙った攻撃トラフィックを観測した」と報告し、攻撃者が「当社の防御を回避しようと攻撃ペイロードを改変している」のを確認したとしています。
10月21日 14:00 UTC頃。 PHPが修正とアドバイザリを公開しました。同じ日に、米国のCISA、英国のNCSC、CERT-EU、そして欧州委員会、ENISA、CERT-EU、Europol、EU各国のCSIRTによる共同声明が、いずれも組織に直ちにパッチを当てるよう求めました。

どれほど深刻なのか

いつもの月例パッチとは違う点が3つあります。

攻撃者に必要なのはリクエストだけです。 ログインは要らず、誰かがリンクをクリックする必要もありません。PHPのアドバイザリは、mod_phpを使うApacheに対して実証されたエクスプロイトについて、「認証されていないリクエストが、アプリケーションのコードが実行される前に攻撃を引き起こしうる」と説明しています。Wizは最新のWordPress、Drupal、Joomlaへの攻撃を実証し、「影響を受けるPHPバージョンで動く単純な『Hello World』アプリケーションでさえ脆弱になりうる」と指摘しています。こうして実行されたコードはWebサーバーのアカウントの権限を持ち、ほとんどのサイトでは、そのアカウントでアプリケーションの設定を読めます。データベースのパスワード、APIキー、メールや決済の認証情報です。2つ目の欠陥であるCVE-2026-109619について、PHPはメモリの漏えいも確認しています。完全なコード実行に至らなくても、サーバーのメモリ上のデータが外に漏れるということです。

導入数が膨大です。 W3Techsによれば、サーバー側の言語が判明しているWebサイトの69.3%がPHPで動いています（2026年10月22日時点の数字）。Palo Alto NetworksのUnit 42は、独自のインターネットスキャンにもとづき、脆弱である可能性のあるインターネットに露出したインスタンスを2,260万超と数え、少なくとも1つの欧州の政府が予防措置としてWebサイトをオフラインにしたと報告しています。

エクスプロイトの開発が速く進んでいます。 CERT-EUは、初期の概念実証（PoC）が「出回り始めている」と報告しています。セキュリティ企業のwatchTowrは、同社のハニーポットが10月21日以降の悪用を記録していると述べています。Cloudflareは攻撃トラフィックを報告しています。さらにWizによれば、同社の研究者は全工程でAIモデルを使い、「世界トップクラスのチームでも数か月かかったであろう」作業を、研究者1人が1週間でこなしました。エクスプロイトを自社のPHPバージョンに合わせて調整する攻撃者も、同じ道具を持っています。

公平を期して、反対側の材料も挙げておきます。CISAが10月21日にアラートを公開した時点では、CISAは悪用を確認しておらず、どちらの欠陥もまだKnown Exploited Vulnerabilities（既知の悪用された脆弱性）カタログには載っていませんでした。Red Hatはこの問題の深刻度を、Criticalではなく「Important（重要）」としています。標準的なRed Hat Enterprise LinuxのサーバーはPHP-FPMで動いており、そこでは悪用がより難しいためです。ただし、難しいことは不可能ということではありません。PHPは、2つ目の欠陥の攻撃経路の1つがPHP-FPMでも成立することを確認しています。どれも、すべきことを変えるものではありません。変わるのは、どれだけ前もって警告を受けられるかだけです。

自社はどのバージョンか：数字で見る

W3Techsは、Webサイトが使っているPHPのバージョンも、バージョンを明かしているサイトを数えて公表しています。2026年10月22日時点の2つの表を合わせると、次のようになります。

PHPのブランチ	PHPで動くWebサイトに占める割合	PHPプロジェクトによる修正
8.3、8.4、8.5	約34%	あり：8.3.36、8.4.27、8.5.12
8.2	約18%	あり：8.2.35。ただし8.2自体が2026年12月31日にサポート終了
8.0、8.1	約14%	リリースなし。8.0と8.1：ソースのバックポートのみ
7.x	26.9%	リリースなし。7.4：ソースのバックポートのみ。7.3以前：なし
5.x以前	7.8%	なし

つまり、PHPで動くWebサイトの約48%は、PHPプロジェクトが修正版をリリースしないブランチで動いており、さらに18%は、いま修正を受けても10週間後にはサポートを失います。

注意点が2つあります。W3Techsに見えるのは、バージョンを表示しているサイトだけです。また、Linuxディストリビューションが古いブランチに自らパッチを当てている場合があります。後で見るとおり、Ubuntuはそうしています。バージョン番号だけでは、保護されているかどうかは分かりません。分かるのは、ベンダーのパッケージのバージョンです。

ステップ1：稼働しているPHPをすべて洗い出す

リストにないものにはパッチを当てられず、しかもPHPは見つけにくいところに潜んでいます。英国のNCSCは、インターネットに面したものを先に、すべてのPHPシステムを見つけるよう組織に求め、「古いPHPバージョンに限定して探さないこと」と付け加えています。EUの共同声明は、一部の製品が「直接PHPを使っているようには見えなくても、これらの脆弱性の影響を受ける可能性がある」と警告しています。

探すべき場所は次のとおりです。

Webサイトとショップ：WordPressとWooCommerce、Drupal、Joomla、MagentoとAdobe Commerce、Shopware、PrestaShop、TYPO3、そしてLaravelやSymfonyで作られたものすべて。
忘れられたもの：キャンペーン用のマイクロサイト、古い言語版、インターネットから到達できるステージングやテストのサーバー、何年も前に誰かが入れたWebメールやヘルプデスク。
コンテナ：phpのベースイメージから作られたイメージは、どれも独自のPHPを抱えています。ホストを更新しても、それには何の効果もありません。
ホスティングのコントロールパネル：cPanel、Pleskなどのパネルは、システムのPHPとは別に独自のPHPビルドを同梱しています。パネルで有効にしているバージョンは、それぞれ個別に更新が必要です。
PHPを内蔵した製品：アプライアンス、監視ツール、CRM、ヘルプデスク、ベンダーの管理画面。オランダのNCSCは、そうした製品の公開リストを、供給元ごとの対応状況とともに管理しています。
委託先：ホスティング会社、制作会社、下でPHPが動いていると分かっているあらゆるサービス。自社のシステムでどのPHPバージョンが動いていて、いつパッチが当たるのかを書面で尋ねてください。

それぞれについて、PHPのバージョン、PHPの動かし方（mod_php、PHP-FPM、LiteSpeed、FrankenPHP、コンテナ）、インターネットから到達できるかどうか、そして誰がパッチを当てられるのかを書き出してください。

ステップ2：正しい順序でパッチを当てる

インターネットから到達できるものから始め、その中でもmod_phpを使うApacheの構成を最初にしてください。

サポート中のブランチ（8.2から8.5）の場合。 8.5.12、8.4.27、8.3.36、8.2.35のいずれか、または修正を含むディストリビューションのパッケージに更新します。PHPによれば、Linuxディストリビューションは事前にパッチを受け取っていました。これまでに確認できているのは次のとおりです。

Ubuntu：14.04から26.10までのすべてのリリースに修正済みパッケージがあります。22.04以降では通常のアップデートで届き、20.04以前ではUbuntu Proのサブスクリプションが必要です。Ubuntu Proは5台まで無料です（Canonicalのお知らせ）。
Debian：Debian 13向けにphp8.4 8.4.27（DSA-6574-1）、Debian 12向けにphp8.2 8.2.35（DLA-4848-1）。
Red Hat Enterprise Linux：Red HatのセキュリティブレティンRHSB-2026-013が、リリースごとのパッケージを挙げています。
Remiリポジトリ（Red Hat系のシステムで新しいPHPを入れるのに広く使われています）：10月21日、CERT-EUは、Remiにリリース当日のパッケージがないことを指摘し、ディストリビューションのパッケージへの切り替えか、ソースからのビルドを勧めました。頼る前に、Remiが追いついたかどうかを確認してください。

PHP 7.4、8.0、8.1の場合。 PHPプロジェクトはこれらのリリースを出しません。PHPのセキュリティチームは3つのブランチ向けに最小限のソースのバックポートを用意しており、PHPを自分でコンパイルするなら役に立ちます。そうでなければ、修正はベンダーから得るか（たとえばUbuntu ProはUbuntu 20.04のPHP 7.4をカバーしています）、PHPのアップグレードで得るしかありません。8.1以前を使っていて更新できない場合のCISAの助言は率直です。パッチを当てるかアップグレードするまで、システムをオフラインにすること。

PHP 7.3以前の場合。 PHPプロジェクトからは何も出ません。ベンダーがまだ自社のビルドにパッチを当てているのでない限り、選択肢はアップグレードか、システムをオフラインにするかです。

更新したら再起動します。 パッケージをインストールしても、すでに動いているPHPは置き換わりません。Ubuntuのお知らせははっきり書いています。アプリケーションは「おそらく再起動が必要になる」。すべてのサーバーでPHP-FPM、Apache、LiteSpeed、またはコンテナを再起動してください。そのうえで、コマンドラインのphp -vだけでなく、Webサーバーが実際に動かしているバージョンを確認します。コマンドラインのPHPは、別のビルドであることがあるからです。

コンテナ：パッチ済みのベースイメージからイメージを作り直し、デプロイし直してください。パッチ済みのホストでも、古いイメージを動かしていれば露出したままです。

マネージドホスティング：事業者に日付とバージョンを尋ね、そのうえで自分でも確認してください。

ステップ3：今日パッチを当てられない場合

PHPのアドバイザリは暫定対策を挙げ、その前置きとして警告しています。これらの対策は「特定の攻撃経路への露出を減らすが、環境を安全にするものではない」。サーバーを運用している担当者向けに、要点をまとめます。

CVE-2026-109618について：memory_limit=-1を、アプリケーションが上書きできない形で設定します（たとえばPHP-FPMのプールやApacheの設定でphp_admin_valueを使う）。post_max_sizeは低く設定します（PHPは、ファイルアップロードがなければ8M、あれば32Mを勧めています）。Webサーバーまたはプロキシで、リクエストサイズ、フィールド数、multipartのパート数を制限します。メモリの上限にはコンテナまたはcgroupの制限を使い、RLIMIT_ASやRLIMIT_DATAは決して使わないでください。
CVE-2026-109619について：php.iniまたはサーバーの設定でsession.upload_progress.enabled=0を設定し（ini_set()や.user.iniファイルではなく）、すべてのワーカーを再起動します。PHP 8.5では、fatal_error_backtraces=0も設定してください。

注意が2つあります。PHPのセキュリティチームのメンバーが指摘したとおり、10月20日に広く出回ったセッションの設定が塞ぐのは2つ目の欠陥の経路だけで、1つ目には何の効果もありません。また、memory_limit=-1はPHP自身のメモリ上限を外すので、重いリクエスト1つでサーバーのリソースを使い果たしうるようになります。コンテナまたはcgroupの制限と組み合わせてください。

Webアプリケーションファイアウォール（WAF）は役に立ちますが、少しだけです。 CloudflareのルールはWAF付きのすべてのプランで、無料プランも含めて既定で有効になっており、Palo Alto Networksやほかのベンダーも独自の防御策を公開しています。それでもCloudflareは、「WAFによる保護があっても」PHPにパッチを当てるよう顧客に伝えており、攻撃者がルールをすり抜けようとペイロードを変えるのを実際に目にしています。また、WAFが守るのは、そこを通過するトラフィックだけです。サーバーが自身のIPアドレスで直接応答するなら、攻撃者はWAFを迂回できます。

どれもすぐには実施できないなら、 CISA、CERT-EU、NCSC、EUの共同声明はいずれも同じ方向を示しています。修正するまで、システムを公開インターネットから切り離すことです。1日メンテナンスページを出すほうが、サーバーを作り直すより安くつきます。

ステップ4：すでに侵入されていないか確認する

危険にさらされる期間は、漏えいが起きた10月20日から始まり、翌朝には攻撃トラフィックが報告されました。その期間にインターネットから到達でき、パッチが当たっていなかったシステムでは、パッチを当てれば扉は閉まりますが、その前に誰かが入ったかどうかまでは分かりません。NCSCは、すぐにパッチを当てられなかった場合は、侵害の兆候とバックドアを確認するよう求めています。

何を探すべきか、公表されたガイダンスと通常のインシデント対応の実務から挙げます。

PHPが普段決してしないことをしているPHPプロセス。たとえばシェルの起動やツールのダウンロード（CISA）。
通常と異なるmultipartリクエストの後に続く、メモリ上限エラーや繰り返されるHTTP 500レスポンス、はっきりした理由のないPHPワーカーの再起動、レスポンスに含まれる異常に大きいか不正な形式のPHPSESSIDクッキー（Wiz）。
新規または変更されたPHPファイル（アップロード用フォルダ、キャッシュフォルダ、ドキュメントルート内）、CMSの新しい管理者アカウント、誰も作っていないスケジュールタスク。

ログがきれいでも証拠にはなりません。2つ目の欠陥に関するPHPのアドバイザリはまさにその点を警告しており、Wizも、アプリケーションのログには状況を示す情報がほとんど残らないことがあると指摘しています。

何か見つかったら、パッチ作業ではなくインシデントとして扱ってください。 サーバーを隔離し、証拠を保全し、インシデント対応の専門業者を呼び、Webサーバーが読めたすべての機密情報を変更します。データベースのパスワード、APIキー、決済とメールの認証情報、署名鍵です。2つ目の欠陥はメモリを漏えいさせうるので、何日も露出したままパッチが当たっていなかったサーバーでは、侵入の兆候がなくても、そうした機密情報のうち最も重要なものをローテーションすることを検討してください。

ステップ5：通報が必要になりうること

脆弱性があるだけでは、通報すべきインシデントにはなりません。悪用された脆弱性は、通報対象になることがあります。

NIS2：自社が対象で、侵害が重大インシデントに当たる場合、国のCSIRTへの早期警告は24時間以内が期限です。当社のNIS2ガイドをご覧ください。
GDPR：個人データにアクセスされた場合、人にリスクをもたらすおそれが低いときを除き、侵害を知った時から72時間以内に監督機関へ通知しなければなりません。当社のGDPRガイドをご覧ください。
サイバーレジリエンス法：PHPを内蔵したソフトウェアや機器を販売しているなら、サイバーレジリエンス法（CRA）上、自社がその製造者です。EUの共同声明が改めて指摘しているとおり、2026年9月11日から、製造者は自社製品の実際に悪用されている脆弱性を、CRAの単一通報プラットフォームを通じて通報しなければならなくなっています。当社のCRAガイドをご覧ください。
自社の顧客：顧客のためにPHPをホスティングしたり運用したりしているなら、顧客から問い合わせが来ます。短い書面（何を動かしているか、いつパッチを当てたか、何を確認したか）があれば大半に答えられ、それは監査人やサイバー保険会社が見たがるのと同じ書面です。

緊急対応の後に変えるべきこと

よく管理されたサーバーの大半では、PHP2Shellは数日以内にパッチが当たるでしょう。それが自社の体制について明らかにしたことは、その後も変わらずに残ります。

パッチにどれだけ時間がかかるかを把握する。 アドバイザリからすべてのサーバーの再起動まで、数時間か、数日か、数週間か。正直な答えが「制作会社に聞かないと分からない」なら、次の脆弱性が来る前にそこを直してください。研究者が、AIでエクスプロイトの作業が数か月から1週間に縮んだと言うなら、攻撃者もその速さで動けると考えてください。
作ったばかりの台帳を維持する。 対応の中で最も大変だった部分であり、担当者がいなくなった瞬間から古くなっていきます。
サポートの終わったPHPから移る。 7.4や8.1のサイトは、今回はベンダーかソースのバックポートが必要でした。次回はどちらもないかもしれません。PHP 8.2は2026年12月31日にサポート終了を迎えるので、8.1から移るサイトは8.3以降へ直接移るべきです。PHPを移行するには、アプリケーションの更新も必要になることがよくあります。1つのCMSにとってそれが何を伴うかは、Drupal、Umbraco、Kenticoのサポート終了に関する当社の記事で説明しています。
mod_phpよりPHP-FPMを選ぶ（可能な場合）。今回は、そちらのほうがリスクの低い構成でした。
使っていないなら、アップロード進捗はオフのままにする。 PHPのアドバイザリは、アプリケーションが必要としない場合、パッチ適用後もsession.upload_progress.enabledをオフにしておくことを勧めています。
パッチ適用までの時間を契約に書き込む。 ホスティング事業者と制作会社に、PHPの重大な修正をどれだけ早く適用するかを尋ね、その答えを書面でもらってください。

今週のチェックリスト

コンテナ、コントロールパネル、ベンダー製品、ステージングサーバーを含め、すべてのPHP環境を洗い出す。
インターネットに面したシステムから、mod_phpを使うApacheを先頭にパッチを当てる。
すべてのPHPプロセスを再起動し、Webサーバーが報告するバージョンを確認する。
コンテナイメージを作り直し、デプロイし直す。
今日パッチを当てられないところでは、PHPの暫定設定を適用するか、トラフィックをWAF経由にするか、システムをオフラインにする。
委託先とホスティング事業者に、PHPのバージョンとパッチ適用日を書面で尋ねる。
10月20日以降、露出していてパッチが当たっていなかったものすべてについて、ログとファイルの変更を確認する。
通報義務（NIS2、GDPR、CRA）が当てはまるかを判断する。
PHP 8.1以前からの移行と、12月31日までの8.2からの移行を計画する。

当社がお手伝いできること

ほとんどの企業に欠けているのは、パッチを当てる意志ではありません。欠けているのは、自社で何が動いているかの明確な把握か、今週その作業をする人手です。そこを当社が引き受けます。

洗い出しとパッチ適用を数日で。 サーバー、コンテナ、ホスティングのパネル、委託先にまたがってPHP環境を見つけ出し、パッチを当て、再起動して検証し、何をいつ行ったかを書面の記録として残します。その記録は、顧客や監査人への回答にもなります。
古いPHPからの移行。 コードが新しいバージョンで動かないためにPHP 7.x、8.0、8.1に留まっているアプリケーションを、当社のレガシーシステムの保守サービスの中で、サポート中のバージョンへ移植します。
堅牢化とパッチ適用の定常業務化。次のアドバイザリが緊急事態ではなく、予定された作業になるようにします。

侵入の兆候を見つけたら、まずインシデント対応の専門業者に連絡してください。当社は、その業者と並行して再構築とアップグレードを担当できます。

自社で何を運用しているかを添えて、office@c9group.devまでご連絡ください。当社なら最初に何をするかをお返事します。

出典

2026年10月22日に確認。状況はまだ動いており、とくに悪用の状況とベンダーのパッケージは、その後変わっている可能性があります。

PHPプロジェクト

公的機関

研究者、ベンダー、データ