PHPの重大脆弱性で何が起きた？AIとの関係とWordPress利用者の対策を徹底解説

情報確認：2026年10月22日（日本時間）

2026年10月21日、Webサイトの土台として広く使われるPHPに、外部から不正なプログラムを実行されるおそれのある2件の重大な脆弱性が公表されました。「PHP2Shell」と呼ばれる問題です。修正版は同日夜に公開され、サーバー事業者やシステム管理者による対応が進んでいます。資料15

突然の強い注意喚起に、「PHPとは何なのか」「WordPressのブログも危ないのか」「サーバー会社に任せてよいのか」と戸惑った人もいるでしょう。さらに、AIによる攻撃や最近の個人情報流出のニュースが重なり、何と何が関係しているのか分かりにくくなっています。

まず押さえたいのは、PHP本体の修正が必要な問題であり、誰が修正するかは利用環境によって異なるということです。ConoHa WINGのように事業者が対応し、利用者によるPHPの切り替えは不要と案内しているサービスもあります。一方、自分で管理するVPSなどでは、自分か保守担当者の作業が必要です。資料21・資料24

AIとの関係も確認されています。ただし、今回明らかになったのは、以前から存在した欠陥の発見や、実際に悪用できる条件の解明にAIが使われたということです。何が起き、どこまで分かっているのかを整理したうえで、利用者ごとの対応を見ていきます。資料7・資料8・資料9

---

---

何が起きたのか――PHPに2件の重大な脆弱性

10月21日、国家サイバー統括室などがPHPの緊急更新に備えるよう呼びかけ、高市早苗氏もXで、その日の夜に対応する必要性を強く訴えました。これは、同日23時に予定されていた修正版の公開を前にした注意喚起です。この画像は、その時点の投稿を記録したものです。資料10・資料11

図1：高市早苗氏による2026年10月21日の注意喚起。画像は修正版公開前の投稿で、本文は公開後に判明した情報も反映している。出典：高市早苗氏の原投稿。提供されたスクリーンショットを掲載。

問題は、サイトの土台であるPHP本体

対象となったのは、特定のブログ記事や1つのプラグインではなく、PHPの処理を実行するエンジンです。脆弱性には、識別番号としてCVE-2026-109618とCVE-2026-109619が付けられています。CVEは、同じ欠陥を各社が共通の番号で追跡するための仕組みです。

2件とも、条件がそろうと、正規のアカウントでログインしていない相手によるリモートコード実行（RCE）につながります。これは、外部から送られた通信をきっかけに、攻撃者の意図した処理がサーバー上で実行されることです。公式アドバイザリの深刻度は、いずれもCVSS v4.0で9.2、Critical（緊急）とされています。資料2・資料3

CVSSの9.2は、技術的な深刻さを表す評価です。「92％のサイトが攻撃される」「利用者の92％が被害を受けた」という意味ではありません。初期に拡散した10.0という数字とも区別する必要があります。

何をされるおそれがあるのか

攻撃が成立した場合、PHPを動かすプロセスが持つ権限の範囲で、不正な処理を実行される可能性があります。そこから想定される被害には、次のようなものがあります。資料2・資料3

• Webサイトのファイルを改ざんされる。
• PHPが読み取れる設定情報やデータを盗まれる。
• データベースなど、サイトが接続できる先へ被害が広がる。
• 不正なプログラムを置かれたり、サービスを停止させられたりする。

実際の被害範囲は、サーバーの権限設定、保管されている情報、ほかの防御策などによって変わります。RCEが成立したからといって、直ちにOSの最高管理者権限まで取得されると決まるわけではありません。それでも、Webサイトの実行権限だけで重要な情報に届く場合があるため、緊急性が高い問題です。

---

PHPとは何か。「世界の7割が使う」の正しい意味

PHPは、主にサーバー側で動くプログラミング言語です。名称は「PHP: Hypertext Preprocessor」。訪問者がページを開いたとき、サーバーの内部で必要な処理を行い、その結果をブラウザーに返す用途に広く使われています。資料4

WordPressを使う人は、意識しなくてもPHPを使っている

WordPressのブログを例にすると、読者がページにアクセスした際、サーバーではWordPress本体やテーマ、プラグインのPHPコードが動きます。必要に応じてデータベースから記事や設定を読み取り、表示するページを組み立てます。資料20

関係を整理すると、次のようになります。

そのため、「自分はPHPでプログラムを書いたことがないから無関係」とは限りません。レンタルサーバー上にWordPressを設置しているなら、そのサイトを動かす仕組みにPHPが含まれています。

一方、一般の閲覧者が今回の対策として、自宅のパソコンやスマートフォンにPHPの修正プログラムを入れる必要は通常ありません。主な対応対象は、PHPを動かしているサーバーの管理者です。

約7割とは「サーバー側の言語を判定できたWebサイト」の割合

W3Techsの2026年10月22日時点の調査では、PHPは、サーバー側のプログラミング言語を判定できたWebサイトの69.3％で使われています。この数値が「世界の7割がPHPを使う」という表現の根拠になります。資料5

ただし、分母を省くと意味が変わってしまいます。これは次の数字ではありません。

• 世界中の人の7割。
• インターネット上の通信量の7割。
• すべてのサーバーの7割。
• 今回の脆弱性で侵入されたサイトの割合。

PHPが広い範囲で使われる基盤であることは確かです。しかし、利用率からそのまま被害件数を計算することはできません。影響する条件や対策状況は、サイトごとに異なります。

---

どこが危険で、どのバージョンを修正するのか

今回の2件は、PHPが内部で使うメモリの扱いに関係します。メモリとは、処理中の情報を一時的に置く作業場所です。処理が途中で止まったときや、終わった処理から次の処理へ移るときの状態管理に問題があり、不正な動作につながります。資料2・資料3

2件の違いを、専門用語を減らして説明すると

たとえは仕組みの入口を説明するためのものです。実際には、こうした不整合を利用してメモリの読み書きや実行の流れに干渉できることが、重大な問題になります。

「WordPressのログインを守れば大丈夫」とは言えない理由

PHP公式は、Webリクエストを処理するPHP全般を注意対象に挙げています。Apacheのmod_phpだけでなく、PHP-FPM、CGI、FrankenPHP、LiteSpeedなども含まれます。中でもmod_phpでは、アプリケーションのコードが動く前に、認証不要で攻撃できる経路が実証されたと説明しています。資料1

ここが、通常の「管理画面のパスワードを強くする」という対策だけでは足りない理由です。WordPressがログインを確認するより前の段階で問題が起きるなら、そのログイン機能では防げません。

ただし、すべての環境で同じ手順の攻撃が成立するという意味でもありません。実際の成立条件は、PHPの系列、実行方式、設定、アプリケーションなどによって異なります。「自分の環境はPHP-FPMだから安全」と一律に判断せず、修正対象として確認する必要があります。

公式に公開された修正版

10月21日にPHP本体の開発元が公開した修正版は、次のとおりです。IPAの対策情報でも、同じ4系列の修正版が案内されています。資料15

自分でPHP公式版を管理する場合は、同じ系列の該当修正版、または修正を引き継いだ後続版が基準になります。たとえば「PHP 8.3を使っている」という情報だけでは、今回の修正が入っているか判断できません。

また、Linuxの配布元やサーバー会社が、既存の版に必要な修正を取り込んで提供する場合があります。そのときは、この表の番号だけで判定せず、配布元が今回の2件に対応済みと案内しているかを確認します。

古いPHPには、まったく救済策がないのか

PHP 8.1以前は、PHPプロジェクトによる通常のサポートが終了しています。ただし今回は、7.4・8.0・8.1向けの最小限のソース修正も用意され、Linux配布元や長期サポート事業者による修正提供もあります。「古い系列には一切対策がない」という説明は正確ではありません。資料1

一方、今回の修正が提供されたことと、その系列の通常サポートが復活することは別です。古いPHPを使い続ける場合は、誰がどの範囲の修正を提供するのかを確認し、サポートされる環境への移行も計画する必要があります。

---

なぜ突然の緊急対応になったのか。情報は漏れたのか

一般の利用者にとっては突然の警告でしたが、研究者とPHP開発者の間では、夏から調査と修正準備が続いていました。発見から一般への周知までの経緯と、公開直前に起きた混乱を分けて見ていきます。資料7・資料12

図2：国家サイバー統括室による2026年10月21日の事前警告。公開後の対応完了を示す投稿ではなく、修正版が出たら速やかに更新できるよう準備を求めたもの。出典：国家サイバー統括室の原投稿。提供されたスクリーンショットを掲載。

公表までの流れを時系列で見る

以下の時刻は日本時間です。「欠陥に気づいた日」「開発元に報告した日」「修正版を公開した日」は、それぞれ異なります。

時系列の出典：資料6・資料7・資料9・資料12・資料13。公開予定時刻と、各配布先で実際に取得できるようになった時刻には差があるため、修正版公開は「21日夜」と記載している。

「誰かがパッチの話を漏らした」のか

予定外に情報が出たことは確認されています。ただし、1つの漏えい事件にまとめると不正確です。

PHP Foundationの説明では、最初に出回ったのはCVE番号などで、この段階では技術詳細は漏れていませんでした。最初の流出元は、確認した公表資料では明らかにされていません。その後、発見者の一社であるCalifが実証動画を誤公開したと説明されています。資料6

さらに、Chainguardは修正済みコンテナイメージを予定より早く公開しました。CEOのDan Lorenc氏は自らの判断だったと認め、すでに攻撃の情報があり、顧客の保護を優先したと説明しています。一方、PHP側は情報解禁の合意に反したと批判しており、判断の妥当性について当事者の見解は一致していません。資料12

このため、「誰かが完全な攻撃コードを盗んで公開した」「政府がパッチを漏らした」といった一括りの説明には根拠がありません。初期情報の流出、動画の誤公開、修正済み成果物の先行公開を分けて捉える必要があります。

パッチの公開が、なぜ攻撃の手がかりにもなるのか

パッチは、プログラムの欠陥を直す変更です。修正前後の差を調べれば、「どこに、どのような問題があったのか」を推測する材料にもなります。守る側へ修正を届ける行為が、攻撃者へ調査対象を知らせる側面を持つわけです。

そこで重大な脆弱性では、開発元、研究者、OSの配布元、クラウド事業者などが、修正と公開の時期を調整します。発見した瞬間に詳細を世界へ広めると、利用者が更新できる前に攻撃の準備が進むおそれがあるためです。今回もPHPの開発者が修正を主導し、複数の組織が配布や防御の準備に参加していました。資料8

ただし、調整していれば情報が必ず守られるわけではなく、同じ弱点を別の人が独立に見つける可能性もあります。今回のAWSの観測は、先行公開の騒動より前の10月17日にさかのぼります。すべての攻撃が、特定の先行公開をきっかけに始まったとは言えません。攻撃者がどのように情報を得たのかは、確認できた資料からは分かりません。資料13

---

AIは今回、何を変えたのか

今回の研究にAIが使われたことは、当事者が明らかにしています。OpenAIは、CalifがGPT-5.6 Solを使って重大な欠陥を発見したと説明しています。Wizも、自社のWiz AtlasとGemini 4 Argon、GPT-5.6 Solを用いた研究を公表しています。資料8・資料9

以前からあった欠陥が、現実的な攻撃につながると分かった

PHP Foundationによれば、メモリ不足に関する問題の兆候は2024年に把握していました。しかし、修正候補の互換性・性能への影響や、限られた人員での判断の難しさがあり、作業が停滞しました。Foundation自身も、意思決定と資源の問題を認めています。資料6

その後の研究で、具体的に悪用できる経路が明らかになりました。Califは、古いPHPの系列まで影響する経路を確認したと報告しています。したがって、今回を「AIが生成したコードが、PHPに新しく穴を開けた事件」と説明するのは誤りです。資料7

以前からある欠陥について、実際にどの条件で危険な状態になるのかを調べ、その動きを再現する。ここでAIが研究を助けました。「不具合がありそう」と「外部からの侵入に使えると実証された」の間には、大きな違いがあります。

AIが速くするのは、コードを読む作業だけではない

当事者の研究報告から読み取れるのは、AIが複数の工程に関わったということです。資料7・資料9

• 複雑なコードや処理のつながりを調べる。
• エラーが起きた場合の特殊な経路を探す。
• 仮説を検証し、失敗した理由を分析する。
• 条件を変えて、再現性や悪用の可能性を確かめる。
• 修正案や検出方法の検証を助ける。

ただし、Califは、対象の歴史を知る人間が調査の方向を与えたことも強調しています。「AIに一言頼めば、すべての脆弱性を自動で発見できる」という話ではありません。欠陥の発見後にも、開発者による修正、互換性の確認、配布、利用環境への適用が必要です。

「AIの急速な進化の代償」と考えるべきか

ここは、確認された事実を踏まえて、3つに分けて考えると整理しやすくなります。

第1に、守る側が今まで見つけにくかった問題を発見できるようになること。修正まで届けば、ソフトウェアの安全性を高められます。今回も、AIを使った研究は修正につながっています。

第2に、攻撃する側も調査や試行を効率化できること。脆弱性の詳細や修正差分が公開された後、攻撃方法を調整する負担が小さくなるなら、更新までに残された時間は短くなります。実際の攻撃活動でAIが使われた事例も、後述する調査で報告されています。

第3に、発見の速度と、修正を行き渡らせる速度が一致しないこと。修正には、人の判断、運用体制、予算、利用者への連絡が必要です。AIが欠陥を見つけても、古いサーバーが自動的に安全になるわけではありません。

この3点は、今回の共同対応と攻撃調査から導ける見方です。「AIが進化したから危険になった」とだけ捉えるより、発見と攻撃が速くなる中で、修正を実際の稼働環境へ届ける体制が追いついているかという問題として考える方が、必要な行動につながります。

---

すでに攻撃されている？最近の個人情報流出との関係

今回の問題は、「理論上は危険だが、攻撃はまだ観測されていない」と説明できる段階ではありません。AWSは監視用環境MadPotで、修正版の公開前にあたる10月17日から攻撃試行を観測したと公表しています。資料13

攻撃試行と、侵入・流出の成功は区別する

AWSは、公開前の試行が実際のシステムで成功し得たかについては不明としています。一方、公開後には悪用が広がっていると説明しています。Cloudflareも、顧客を狙う攻撃通信や、防御を避けようとする変化を報告しています。資料13・資料14

ニュースを読む際は、次の段階を分ける必要があります。

大量の攻撃通信を観測したとしても、その件数を「乗っ取られたサイト数」や「流出した人数」に読み替えることはできません。逆に、まだ被害公表がないからといって、未修正のままでよいとも言えません。

最近の日本企業の個人情報流出も、PHPが原因なのか

IPAは10月9日、金融・通信・オンラインアカウントを利用するサービスなどで、個人情報漏えいの公表が相次いでいるとして注意を呼びかけています。また、GMOサイバーセキュリティ byイエラエは10月19日、日本企業を狙う攻撃元の調査から、AIを利用するツールARTEXの使用を確認したと報告しています。資料16・資料17

しかし、これらと今回のPHPの2件を、1つの原因にまとめることはできません。確認した公表資料には、最近の国内の情報流出をまとめて今回の2件に結び付ける根拠はありません。個別の事件が関係しているかどうかは、被害組織や調査機関の分析を待つ必要があります。

関係を整理すると、AIは「攻撃を進めるための道具」、PHPの脆弱性は「侵入口の候補」、個人情報流出は「起こり得る被害」です。道具が同じでも侵入口は異なり、侵入口が同じでも被害の有無や範囲は変わります。

公開前のログも、調査対象になる

AWSが公開前の試行を報告している以上、被害が疑われるサイトで「公表日の10月21日以降だけ調べれば十分」とは限りません。調査範囲は専門家や保守担当者と判断し、公開前の記録も含めて保全することが大切です。資料13

また、更新した後に問題が消えたように見えても、それだけで過去の侵害がなかったと証明できるわけではありません。修正パッチは侵入口を直しますが、すでに持ち出された情報を取り戻したり、置かれた不正ファイルをすべて除去したりするものではありません。

---

「ハッカーは中国系AIを使っている」は本当か

中国で開発されたAIモデルやツールを攻撃者が使う事例は報告されています。ただし、「攻撃者の大半が中国系AIを使っている」と判断できる世界全体の統計は、今回確認した一次資料にはありません。具体的な観測事例と、世界全体の割合を分ける必要があります。

ARTEXを使う攻撃は、実際に報告されている

CrowdStrikeは10月7日、韓国の金融機関を狙った活動で、中国で開発されたセキュリティ検証ツールARTEXが悪用されたと報告しました。同社は攻撃者側の設定やセッション履歴などを分析し、DeepSeek、GLM、Grokなどの利用を確認しています。資料18

この事例について、同社は中国語を使う金銭目的の攻撃者である可能性を「中程度の確信度」で評価しています。これは、特定の国籍や国家の関与を確定したという意味ではありません。

また、GMOの日本企業を対象とした調査も、観測できた攻撃インフラの分析です。報告の見出しに「多く」という表現があっても、その調査範囲を超えて、日本や世界の攻撃全体の割合として読むことはできません。資料17

ツールの開発国、AIモデル、攻撃者の所属は別の情報

「中国系AI」という一言には、違う意味が混ざりやすくなっています。

中国で作られた道具を使ったからといって、使った人まで中国人と決まるわけではありません。反対に、中国語を使う攻撃者が、米国企業のAIを利用する場合もあります。

実行環境の名前と、背後で動くモデルが一致するとも限りません。たとえばARTEXの調査ではClaude Codeの履歴も扱われていますが、別のモデルへ接続する構成が確認されています。「Claude Codeという名前があるから、すべてClaudeによる処理」とも判断できません。資料18

複数の言語圏で、米国系AIの悪用も確認されている

CrowdStrikeは10月21日、スペイン語・英語、中国語、インドネシア語、ロシア語を使う攻撃者の活動で、Claude Codeが使われた事例を公表しました。中国語を使う攻撃者が、中継サービス経由で主にClaudeを利用したケースも含まれています。資料19

この報告から分かるのは、AIの悪用が1つの開発国や言語圏に限られないということです。この4事例から、逆に中国系モデルの利用が少ないと計算することもできません。

サイト運営者にとっては、モデルの開発国だけで危険を判断するより、自分の環境の未修正箇所、管理者、更新の経路を把握することが、具体的な防御につながります。

---

Xserver・ConoHa・WordPress利用者は何をすべきか

PHPの更新を誰が行うかは、契約しているサービスと保守範囲で変わります。サーバー会社の名前だけで判断せず、「共有レンタルサーバーなのか、VPSなのか」「運用を誰に任せているのか」を確認することが出発点です。

利用形態ごとの役割分担

これは責任分担の一般的な整理です。個別のサービスでは、契約や今回の告知を優先します。ConoHaの公式FAQも、VPSではOS更新やセキュリティ対応などの運用管理が利用者側に必要だと説明しています。資料24

ConoHa WING：利用者によるPHPの切り替えは不要

ConoHa WINGは10月22日、現在のPHPバージョンを維持したまま事業者側で修正を適用し、利用者自身によるPHPバージョン変更などは不要と発表しました。本稿で確認した時点では、パッチの適用は順次進行中です。資料21

同社は、ファイルマネージャーとWebメールを予防的に一時停止しています。PHP対応の案内では、サイト表示やメール送受信は通常利用できるとしていますが、別途、10月22日12時〜21時予定のメンテナンスでは、対象ホストごとに数分〜数十分の利用できない時間が発生すると告知しています。終了時刻は前後する可能性があります。資料34

ここでは、次の3つを分けて読む必要があります。

• PHPの修正は、サーバー会社が進めている。
• 管理機能の一部は、予防措置で停止している。
• メンテナンスによる、一時的なサービス停止もあり得る。

機能が止まっていることだけを根拠に、「ConoHaが侵入された」「自分の情報が流出した」と判断することはできません。また、この案内の対象はConoHa WINGです。ConoHa VPSまで自動的に同じ対応になると考えないでください。

エックスサーバー：PHPの系列ごとに完了状況を確認する

エックスサーバーは10月22日の公式Xで、対象サーバーへの適用状況を次のように案内しています。資料22・資料23

この表を、同社のあらゆるサービスやVPSまで含む一律の保証として扱うことはできません。自分が契約しているサービスとPHP系列が、告知の対象に入るかを確認してください。

上記のホスティング状況は、10月22日14時50分〜14時53分の確認内容です。適用完了や機能再開については、各社の最新案内を優先してください。

表示されるPHP番号が古くても、修正済みの場合がある

サーバー会社やLinuxの配布元は、現在の系列を維持しながら、必要な安全対策だけを取り込むことがあります。これをバックポートと呼びます。利用中のアプリケーションとの互換性を維持しつつ、脆弱性を直すための方法です。資料25

今回のUbuntuの告知でも、たとえばUbuntu 26.10向けの修正済みパッケージとして、8.5.9-0ubuntu2.1が示されています。PHP公式の修正版8.5.12より古い番号に見えますが、配布元の修正が含まれる例です。資料26

したがって、管理画面の数字だけで「まだ危険」「もう安全」と結論を出すのは避けましょう。確認するのは、利用している環境が今回の2件に対応済みかです。もちろん、古い番号ならすべて安全という意味ではなく、配布元の具体的な案内が必要です。

WordPressの更新ボタンで、今回のPHPも直るのか

WordPress公式は、今回の問題はWordPress固有のものではなく、この2件に対処するためのWordPress本体の更新は必要でも予定されてもいないと説明しています。資料20

WordPressの更新と、PHPの更新は別です。本体・テーマ・プラグインを最新にしていても、PHP側に修正が入っていなければ、今回の問題への対応は完了していません。逆にPHPを修正しても、古いプラグインなどの別の脆弱性まで直るわけではありません。

利用中のPHPのバージョンは、WordPress管理画面の「ツール」→「サイトヘルス」→「情報」→「サーバー」で確認できます。ただし、この表示は確認の入口です。バックポートの有無を含む最終判断は、事業者の対応情報と合わせて行います。資料20

個人ブログの運営者が、いま確認すること

共有レンタルサーバーを使っている場合、まず次の順番で確認すると、不要な変更を避けつつ対応できます。

1. 契約サービスとPHP系列を確かめる。「ConoHa」だけでなくWINGかVPSかまで確認する。
2. 公式のお知らせで、自分の環境の修正状況を見る。「準備中」「適用中」「完了」を区別し、必要な追加操作が書かれていれば従う。
3. サイトの基本動作を確認する。トップページだけでなく、ログイン、問い合わせ、画像アップロード、購入機能など、実際に使う機能を確認する。
4. 普段の保守を続ける。WordPress・テーマ・プラグインの更新、バックアップ、管理者アカウントの確認は引き続き必要。

PHPの切り替えが不要と明示された環境で、慌てて別の系列へ変更する必要はありません。大きく系列を変える場合には、テーマやプラグインとの互換性を確かめる必要があります。一方、修正が未適用の環境で、確認作業を理由に対応を先延ばしすることも避けましょう。

---

自分でサーバーを管理する人の緊急対応

VPS、クラウドの仮想マシン、自社サーバー、独自のコンテナ環境などでは、自分か保守担当者が更新を進める必要があります。「クラウド上にある」「WordPressを簡単インストールした」という理由だけで、その後のPHP更新まで代行されるとは限りません。

まず、動いているPHPを漏れなく把握する

対象はメインのWebサイトだけではありません。管理する範囲を整理し、本番、検証環境、サブドメイン、古いテストサイト、管理ツール、WebメールなどにPHPが残っていないか確認します。

また、1つのサーバーで複数のPHP系列を使っている場合や、コマンドラインとWebで異なるPHPを実行している場合があります。PHPは実行方式によって設定も異なるため、php -vの結果だけを見て、Web側も修正済みと判断しないことが大切です。資料27

更新は「取得した」から「実際に動いている」まで確認する

基本的な対応は、次の流れです。

1. 対象環境と更新元を確定する。PHP公式版なのか、OSのパッケージなのか、独自リポジトリやコンテナなのかを確認する。
2. 復元手段を確保し、該当する修正を適用する。ファイルとデータベースのバックアップ、必要な設定の記録を確保したうえで、公式または配布元が示す修正版へ更新する。
3. 実行中の処理へ反映する。環境に応じてPHP-FPMやWebサーバーなどの再起動・再読み込みを行い、古いプロセスが残っていないか確認する。
4. Web側で実際に使われている版を確認する。複数のサイト、PHP系列、コンテナがある場合は、それぞれを確認する。
5. 主要機能とログを確認する。表示、認証、フォーム、ファイル処理などの動作を点検し、不審なエラーや変更がないかを見る。

これは修正の適用と実行方式の違いを踏まえた運用上の整理です。実際の更新手順や再起動対象は、利用している配布元や運用方式の案内に従います。資料15・資料27

コンテナでは、古いイメージを再起動しても、その中のPHPは更新されません。修正済みのベースイメージや依存パッケージを取得し、必要な再ビルドと再配置を行い、稼働中のコンテナに修正が入ったことを確認します。Docker公式も、イメージは作成時点の状態を保持するため、依存関係の更新を取り込む再構築が必要だと説明しています。資料28

すぐに更新できない場合、どうするのか

PHP公式は、完全な解決には更新が必要であり、設定変更による軽減策は特定の攻撃経路を減らすものだと説明しています。WordPress公式も、迅速に更新できない自主管理環境では、更新準備中の公開停止を検討するよう案内しています。資料1・資料20

このときの停止は、脆弱なPHPへリクエストが到達しない状態にすることが重要です。mod_phpではアプリケーションの実行前に攻撃が成立する経路があるため、WordPressのメンテナンスプラグインで「準備中」と表示するだけでは、PHP自体を止めたことになりません。

運用担当者が、Webサーバー、リバースプロキシ、ネットワークなど、PHPの手前の段階で適切に制限する必要があります。これは処理順序から導かれる運用上の注意点であり、各環境の構成に応じた判断が必要です。

WAFや設定変更を、修正の代わりにしない

WAFは、Webへの通信を調べ、不審なリクエストを遮断する仕組みです。今回も防御に使われていますが、Cloudflare自身が、WAFの保護があってもPHPの更新を行うよう求めています。資料14

ネット上で紹介されるmemory_limit=-1などの設定も、一般利用者が意味を確認せずに適用してよい万能策ではありません。特定の経路を抑える一方で、メモリの消費やサービス停止のリスクを考慮する必要があり、2件全体を解消するものでもありません。資料7

WAF、設定による軽減、公開範囲の制限、PHP本体の修正は、それぞれ役割が違います。自分の環境で何が実施済みで、何が残っているのかを把握してください。

すでに侵害された疑いがある場合

見覚えのない管理者、ファイルの改変、不自然な転送、不審な実行記録などがある場合は、更新だけで作業を終えず、サーバー会社や保守担当者に相談します。WordPress公式も、異常の具体化、記録、バックアップや環境の確認を含む対応を案内しています。資料31

調査に必要なログやファイルを保全し、必要に応じて影響するサービスを隔離します。不正ファイルを見つけたからといって、記録を残さず関連情報をすべて消すと、侵入経路や被害範囲が分からなくなることがあります。復旧や認証情報の変更も、侵害範囲と安全な環境の確保を踏まえて進めます。

---

PHPだけで終わらせない、今後のセキュリティ対策

今回の直接の修正対象はPHPです。ただし、確認する範囲はWordPressのブログに限りません。さらに、PHPを直しても、別のソフトウェアやアカウントにある問題まで消えるわけではありません。

PHPを使っているのは、ブログだけではない

PHPは、各種のWebアプリケーションや管理機能の内部でも使われます。利用者がPHPを選んだ記憶がなくても、導入した製品の一部に含まれている場合があります。

実際に今回、Palo Alto NetworksはPAN-OSやPanoramaについて、対象となる構成や版、対応を案内しています。資料32

このような製品では、一般向けPHPを勝手に入れ替えるのではなく、製品ベンダーが指定するファームウェアや更新手順、軽減策に従う必要があります。「WordPressを使っていないから関係ない」と判断せず、保有製品の告知も確認しましょう。

ほかの言語やソフトウェアにも、独立した脆弱性がある

PHP以外を使えば、セキュリティ更新が不要になるわけではありません。たとえばNode.jsも、10月21日に別件のセキュリティ更新を公開しています。資料33

これは今回のPHPと同じ欠陥という意味でも、すべてAIが見つけたという意味でもありません。多くのシステムは、OS、実行環境、ライブラリ、アプリケーションなどの組み合わせで動いており、それぞれに更新が必要になるということです。

今回の問題だけを理由に、十分な検討なく言語やホスティング方式を乗り換えるより、現在の構成と更新担当を明確にすることが先です。移行そのものにも、互換性確認や継続的な保守が必要になります。

緊急対応の後に、運営者が整えておきたいこと

PHPへの今回の対応を確認したら、サイト全体の保守も点検します。WordPress公式のセキュリティ文書では、ホストとサイト所有者の役割、更新、権限、バックアップなどが整理されています。資料29

• 更新するものを把握する。WordPress本体、テーマ、プラグイン、PHP、OS、公開している管理ツールなどの担当と更新方法を整理する。
• 不要なものを減らす。使っていない拡張機能、管理者アカウント、放置した検証サイトを確認し、安全に整理する。
• 認証を強化する。管理アカウントには使い回さないパスワードを使い、可能なら多要素認証を設定する。権限は必要な範囲に絞る。
• バックアップを復元できる状態にする。ファイルとデータベースの両方を確保し、同じ障害で一緒に失わない保管と、復元方法を確認する。
• 異常に気づく仕組みを持つ。更新失敗、管理者の追加、ファイル変更、サイト停止などの通知や記録を確認できるようにする。
• 連絡先を決める。緊急時にサーバー会社、制作会社、社内担当者の誰へ連絡し、誰が停止や復旧を判断するかを決めておく。

自動更新を使っていても、成功したかを確認できることが大切です。WordPressのプラグイン・テーマの自動更新は対象ごとの設定があり、失敗する場合もあります。「自動更新を有効にしたから、すべて常に最新」とは限りません。資料30

サイト運営者以外も、普段使うOS、ブラウザー、ルーターなどの更新やアカウント保護は続けてください。ただし、それらの更新は、Webサーバー上の今回のPHP修正を代行するものではありません。

---

今回の問題から、何を受け止めるべきか

PHP2Shellは、広く使われる基盤の欠陥が、AIを使った研究によって具体的な危険として明らかになり、世界中の運用者が短時間で修正を届ける必要に迫られた問題です。公開調整の途中では情報の流出や先行公開もあり、準備と周知をいっそう難しくしました。

ここから「PHPを使うサイトはすべて侵害された」「最近の個人情報流出はすべて同じ原因」「攻撃者は中国系AIばかり」と結論づけることはできません。判断には、利用率、攻撃試行、侵入成功、情報流出を区別し、それぞれに対応する証拠が必要です。

読者がまず確かめるべきことは、自分のサイトのPHPを誰が管理し、今回の2件への対応がどこまで終わっているかです。共有レンタルサーバーなら、自分のサービスと系列に対応する公式案内を確認する。自主管理なら、修正を実行中の環境まで反映する。管理を委託しているなら、担当と完了状況を確認する。この確認が、ニュースを自分の対策へつなげる第一歩になります。

---

参考資料・公式情報

以下は2026年10月22日に確認した資料です。本文中の資料番号から対応する出典へ移動できます。対応状況が更新されるページは、最新の記載を優先してください。

PHPの概要・脆弱性・修正

資料1｜PHP公式：Security advisory: Critical remote code execution vulnerabilities, update now（2026年10月21日）
対象となる実行環境、修正版、旧系列への対応、軽減策の限界。
PHP公式アドバイザリ・2026年アーカイブ

資料2｜PHP公式セキュリティアドバイザリ：RCE via OOM corruption
CVE-2026-109618の仕組み、影響、深刻度。
GitHub Security Advisory — GHSA-w8hw-w9fx-j79w

資料3｜PHP公式セキュリティアドバイザリ：RCE via stale global state
CVE-2026-109619の仕組み、影響、深刻度。
GitHub Security Advisory — GHSA-6wmf-4rv5-p3rp

資料4｜PHPマニュアル：一般的な情報
PHPの名称と概要。
PHP公式・日本語FAQ

資料5｜W3Techs：Usage statistics of PHP for websites
2026年10月22日時点の69.3％と、その集計対象。
PHPの利用統計

発見・AI・公開調整

資料6｜PHP Foundation：Today's PHP Security Release and How We're Strengthening PHP Security（2026年10月21日）
以前からの問題認識、修正の課題、情報流出・公開調整に関する当事者の説明。
PHP Foundationの説明

資料7｜Calif：PHP2Shell
発見者による技術報告、研究方法、発見・報告の時系列。
Califの研究報告

資料8｜OpenAI：Coordinated disclosure of critical vulnerabilities（2026年10月21日）
AIを使った発見と、PHP開発者・各社の共同対応。
OpenAIの共同対応報告

資料9｜Wiz：PHP2Shell（2026年10月21日）
独立した発見、使用したAI、調査・検証と報告時期。
Wizの研究報告

資料10｜国家サイバー統括室：PHPの脆弱性に関するX投稿（2026年10月21日）
図2の原投稿。修正版公開前の注意喚起。
国家サイバー統括室の投稿

資料11｜高市早苗氏：PHPへの緊急対応を呼びかけるX投稿（2026年10月21日）
図1の原投稿。
高市早苗氏の投稿

資料12｜Chainguard CEO Dan Lorenc氏：先行公開についての説明
修正済みイメージを先行公開した判断についての本人の説明、および当事者の見解。
Dan Lorenc氏のLinkedIn投稿

攻撃観測・個人情報流出・AI悪用

資料13｜AWS：Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot（2026年10月21日）
公開前の攻撃試行、公開後の状況、観測の限界。
AWSの脅威調査報告

資料14｜Cloudflare：PHP脆弱性へのWAF対応に関する報告（2026年10月21日）
攻撃通信の観測、WAFによる防御、PHP更新の必要性。
Cloudflareの対応報告

資料15｜IPA：PHPの脆弱性対策について（CVE-2026-109618、CVE-2026-109619：PHP2shell）（2026年10月22日）
今回の問題を日本語で確認するための公的情報。
IPAの注意喚起

資料16｜IPA：不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について（2026年10月9日）
国内で続く情報漏えい公表についての案内。
IPAの注意喚起

資料17｜GMOサイバーセキュリティ byイエラエ：相次ぐ不正アクセスの攻撃元の多くがAIであることを確認（2026年10月19日）
日本企業を狙う攻撃元インフラとARTEX利用に関する調査。
GMOの調査報告

資料18｜CrowdStrike：Unknown Threat Actor Uses AI-Driven ARTEX to Target South Korean Finance（2026年10月7日）
ARTEX、利用モデル、観測された使用言語と帰属判断の限界。
CrowdStrikeのARTEX調査

資料19｜CrowdStrike：CrowdStrike Uncovers New Agentic AI Campaigns（2026年10月21日）
複数の言語圏の攻撃活動におけるClaude Codeの悪用。
CrowdStrikeの4事例の調査

WordPress・ホスティング・運用

資料20｜WordPress公式：Critical PHP Security Release（2026年10月21日）
WordPressとの関係、ホストへの確認、PHPバージョンの確認方法。
WordPress公式の今回の案内

資料21｜ConoHa WING：【重要】PHPの脆弱性への弊社対応について（2026年10月22日）
パッチ適用状況、利用者によるPHP変更不要、管理機能の予防停止。
ConoHa WINGの対応案内

資料22｜エックスサーバー公式X：メンテナンス状況について③（2026年10月22日）
PHP 8.2〜8.5の対象サーバーへの適用完了。
エックスサーバーの公式発表③

資料23｜エックスサーバー公式X：メンテナンス状況について④（2026年10月22日）
PHP 7.4〜8.1の適用完了と、7.3以前の対応継続。
エックスサーバーの公式発表④

資料24｜ConoHa VPS：よくある質問
VPSにおけるOS更新・セキュリティ対応などの運用管理。
ConoHa VPS公式FAQ

資料25｜Red Hat：Backporting Security Fixes
バックポートと、バージョン番号だけでは判断できない理由。
Red Hatのバックポート解説

資料26｜Ubuntu：USN-8948-1 — PHP vulnerabilities（2026年10月21日）
今回の2件を修正したUbuntuのパッケージ。
Ubuntuのセキュリティ通知

資料27｜PHPマニュアル：The configuration file
PHPの実行方式による設定読み込みの違い。
PHPの設定ファイル解説

資料28｜Docker：Building best practices
イメージの性質と、依存関係の更新を取り込むための再ビルド。
Docker公式のビルド指針

資料29｜WordPress：Hardening WordPress
管理責任、更新、権限、認証、バックアップなどの基礎。
WordPress公式のセキュリティ強化ガイド

資料30｜WordPress：Plugins and themes auto-updates
自動更新の設定と、更新失敗を含む運用上の確認点。
WordPressのプラグイン・テーマ自動更新

資料31｜WordPress：FAQ My site was hacked
侵害が疑われるときの確認と対応。
WordPress公式の侵害対応案内

資料32｜Palo Alto Networks：CVE-2026-109618
PAN-OS・Panoramaの対象構成・版と、製品固有の対応。
Palo Alto Networksの製品アドバイザリ

資料33｜Node.js：October 2026 Security Releases（2026年10月21日）
PHPとは別件のセキュリティ更新。
Node.jsのセキュリティ更新

資料34｜ConoHa WING：【緊急メンテナンス】［ConoHa］ サーバーメンテナンス（2026年10月22日）
12時〜21時予定の保守と、対象ホストごとの一時的な利用停止。
ConoHa WINGのメンテナンス案内