この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。PHP開発元、PHP Foundation、OpenAI、セキュリティ研究企業、国内外の公的機関の発表を基に、危険性・発見の経緯・注意喚起・対策を整理しました。主要な一次資料とPHP公式の追加注意事項は2026年10月25日に再確認しました。特定のサイトや個人のサーバー構成・運用ログは掲載していません。検証ステータス：🧪 主要な一次資料、コマンドの構文、試験データによる状態表示を確認。実Ubuntuでの更新作業とWordPress上の図表示は未検証。
2026年10月21日、プログラミング言語PHPの開発チームが、二つの重大な脆弱性に対応する修正版を公開した。通称「PHP2Shell」と呼ばれる問題だ。深刻度はCVSS v4.0で9.2。条件がそろうと、攻撃者がログインせずにWebサーバー上で不正なコードを実行できる。WordPressなど個別のWebアプリだけでなく、その土台となるPHP自体に関わるため、影響が広がりやすい。出典はPHP公式のセキュリティ告知とPHP Foundationの説明である。
今回のニュースにはもう一つ大きな特徴がある。以前から知られていた問題の深刻な攻撃可能性を、生成AIを活用したセキュリティ研究が具体的に示したことだ。なぜ修正が急がれ、政府や企業まで動いたのかを、発見から対策までの流れでたどる。
PHPとは何か――30年以上、世界のWebを支える仕組み
PHPは、Webサーバー側で動くオープンソースのプログラミング言語だ。たとえば買い物サイトで商品を選ぶと、PHPがデータベースから価格や在庫を取得し、注文内容を登録して、利用者に結果を返すことができる。会員ログイン、問い合わせフォーム、ブログ記事の表示なども代表的な用途だ。ブラウザーに表示される画面の裏側で、情報を取り出したり処理したりする役割を持つ。PHP公式の入門資料も、こうしたサーバー側での利用を説明している。
その始まりは1994年。開発者Rasmus Lerdorf（ラスマス・ラードフ）が自分のWebページへの訪問記録を調べるために作った小さな道具だった。「Personal Home Page Tools」と呼ばれ、1995年6月にはソースコードが公開された。ほかの開発者が改良に参加し、約30年かけて世界で使われる言語へ成長した。歴史はPHP公式マニュアルに残されている。
PHPを土台にする仕組みには、WordPress（ブログや企業サイトの管理）、DrupalやJoomla（大規模サイトなどのコンテンツ管理）、MediaWiki（ウィキ型の情報サイト）などがある。これらのサービスを利用していても、普段の閲覧者はPHPの存在を意識することが少ない。
世界への影響はどれくらい大きいのか
Web技術の採用状況を調べるW3Techsによると、参照ページの表示日である2026年10月24日時点、サーバー側のプログラミング言語を判別できたWebサイトの69.3％がPHPを使用していた。W3Techsの利用統計に示された数字だ。世界で幅広く使われる共通技術に欠陥が見つかったから、今回のニュースは日本だけの問題にとどまらなかった。
ただし、69.3％は「世界中の全サイトが対象」という意味でも、「その69.3％に脆弱性が残っている」という意味でもない。分母は言語を判別できたWebサイトであり、PHPの版数、修正状況、使い方、攻撃の成立条件はサイトごとに異なる。普及率と危険なサイトの割合は分けて読む必要がある。
どんな被害につながるのか
PHPはサーバー上でWebページやAPIなどを動かす仕組みであり、サイトの外観を変えるための部品ではない。PHPの内部にある欠陥が悪用されると、サイトのプログラムを変更していなくても危険が生じ得る。
研究チームは、条件を満たす構成で次のような影響を実証・説明している。
サイトの改ざん：不正なコードの実行により、ページ内容やファイルが変更されるおそれがある。
機密情報の窃取：サーバー内の処理メモリに含まれるパスワード、トークン、APIキーなどを読み取られる可能性がある。
サービス停止：PHPのプロセスが異常終了したり、Webサービスが正常に応答できなくなったりする可能性がある。
被害の拡大：サーバーの権限やネットワーク上の接続関係によっては、別の資産にも影響が及ぶ可能性がある。
これはすべてのPHPサイトで同じ攻撃が必ず成功するという意味ではない。攻撃成立条件や、その後に実行できる処理はPHPの動作方式、設定、権限、アプリケーションによって変わる。Wizの研究結果では、WordPress、Drupal、Joomlaを使った検証環境での攻撃成立が報告されているが、その事実を個々の運用サイトの侵害と混同してはいけない。
原因はWebアプリの不具合ではなく、PHPの内部処理
二つの脆弱性は、PHPがエラーやメモリ不足を扱う際の内部状態の問題に関係している。
| 識別番号 | 問題の概要 | 起こり得る影響 |
|---|---|---|
| CVE-2026-109618 | メモリ不足時に、初期化が不完全なデータが残る場合がある | メモリ破壊、不正なコード実行など |
| CVE-2026-109619 | 前のリクエストに関連した古い状態が、後の処理で使われる場合がある | 解放済みメモリの不正な利用、不正なコード実行など |
詳しくはPHP FoundationとUbuntuのセキュリティ通知が説明している。一般に「リモートコード実行（RCE）」とは、攻撃者が離れた場所から対象のコンピューターに意図しないプログラムを実行させることを指す。PHPの脆弱性だからといって、必ずしもOSコマンドインジェクションという攻撃手法と同一ではない。
生成AIは本当に発見に関わったのか
生成AIは実際に使われた。ただし、「AIが単独で見つけて修正まで終えた」という説明は正確ではない。
PHP Foundationによると、2024年にQuarkslabがOSTIFの調整のもとで実施した外部監査で指摘された別の問題をPHPの開発者が修正する過程で、今回のメモリ不足に関する問題の兆候が見つかっていた。Quarkslabが2024年時点で今回の2件を直接発見したという意味ではない。しかし、当時は具体的にどのような経路で攻撃が成立するのかが判明せず、互換性や性能への影響もあって修正方針の決定が難航した。
2026年には、生成AIを支援ツールとして利用した複数のセキュリティ研究が進んだ。
7月30日：セキュリティ企業Califが、OpenAIの「Patch the Planet」に関連してPHPの監査を開始。
8月11日：Califの研究者が、従来の問題につながる深刻なリモートコード実行の経路を報告。
8月19日～24日：WizがAIを使った研究で脆弱性と攻撃可能性を検証し、PHPのセキュリティチームへ報告。
10月21日：PHP開発チームが修正版を公開。
PHP Foundationは、OpenAIも同じ根本原因を独立して報告し、9月18日には追加の攻撃経路を報告したと説明している。OpenAIによる初回の独立報告の日付は同資料の本文に明記されていない。
AIを活用した調査と各組織の報告経緯は、Wizの技術報告とPHP Foundationの経緯説明を参照。
従来は膨大な解析と試行錯誤が必要だった攻撃可能性の検証をAIが支援し、深刻さが具体的に示されたことが対応を進める大きな契機となった。一方、修正の設計、互換性の判断、コードレビュー、配布は人間の開発者とセキュリティチームが担った。PHP Foundationは、AIによる報告が増えた現在も最終判断とパッチ作業は人間が行うと説明している。
この出来事は、AIが防御側の研究を速くする一方で、攻撃者による脆弱性の分析も容易にし得ることを示している。長年存在した欠陥が、AIの登場によって初めて実用的な攻撃経路として明らかになる場合もある。
ニュースに登場する人と団体は何者なのか
今回のニュースは、研究者が一社で発見し、一社で修正した話ではない。見つける人、直す人、広く配る人、注意を伝える人が役割を分担していた。
PHP開発チーム（The PHP Group）は、PHPという言語そのものを開発・保守する世界の開発者たちだ。脆弱性の修正を実装し、修正版を公開する中心的な役割を担った。その活動を資金面や人員面で支えるPHP Foundationは、企業・個人が参加してPHPの長期的な発展を支援する組織。今回も修正作業を進める人材の確保や関係者の調整を支えた。PHP Foundationの目的と経緯の説明を参照。
Quarkslab（クォークスラボ）はフランスのセキュリティ調査会社で、2024年にPHPのソースコードを監査した。OSTIF（オースティフ）は、オープンソースのセキュリティ監査を調整する非営利団体。監査の資金はドイツのSovereign Tech Agencyが提供した。この監査で別の問題が報告され、その修正過程が後の兆候の発見につながった。PHP Foundationの監査結果とOSTIFの監査報告に経緯がある。
Calif（カリフ）は米国発のセキュリティ調査会社。ソフトウェアに攻撃できる経路がないかを検証する専門家集団だ。OpenAIは生成AIを開発する企業で、「Patch the Planet」を通じて研究者に高度なAIと技術協力を提供した。Wiz（ウィズ）はクラウドやAI利用環境のリスクを調べるセキュリティ企業で、別の経路から問題を研究しPHPチームへ報告した。つまり、CalifやWizは主に発見・実証する側、OpenAIはAIと調査・調整の支援側という関係だ。各組織の説明はCalif、PHP Foundationの経緯説明、Wizを参照。
Canonical（カノニカル）はLinuxディストリビューションUbuntuの開発・提供を担う企業。PHP開発チームが用意した修正を、Ubuntuの既存のPHPパッケージに取り込み、Ubuntu利用者が更新できるようにした。セキュリティ研究者とは別の、配布・更新を担当する立場だ。Ubuntu公式セキュリティ通知に修正版数が示されている。
日本では、IPA（情報処理推進機構）が、情報セキュリティ対策やIT人材育成を担う独立行政法人として更新準備を呼びかけた。JPCERT/CCは、サイバー攻撃・事故の情報を集め、国内外の組織と連絡調整して被害の拡大を防ぐ中立的な調整機関。JISA（情報サービス産業協会）はITサービス企業などの業界団体で、行政からの注意喚起を会員企業へ届ける役割も果たした。組織の目的についてはIPA、JPCERT/CC、JISAで確認できる。
発見から緊急更新までの流れ
発見者と修正の担当者は同じではない。2024年の兆候の把握は、Quarkslabが監査で報告した別件をPHP開発者が修正する過程での出来事だ。メモリ不足問題の兆候を発見したのであり、両方のCVEが当時すでに特定されていたという意味ではない。PHP Foundationの説明と元の監査報告を参照。
flowchart TB
A["2024年：PHP開発者が<br/>メモリ不足問題の兆候を把握"]
B["2026年：研究者が生成AIを活用し<br/>攻撃可能性を具体化"]
C["Calif・OpenAI・Wizなどが<br/>PHP側へ報告・検証協力"]
D["PHPのセキュリティチームが<br/>修正パッチを実装・テスト"]
E["PHP開発元が修正版を公開"]
F["OS配布元がパッケージを準備・配布"]
G["IPA・JPCERT/CCなどが注意喚起"]
H["各組織が更新・侵害兆候を確認"]
A --> B --> C --> D --> E
E --> F --> H
E --> G --> H
図1の登場人物と出典
※1 PHP開発チーム／PHP Foundation：PHPの保守・修正／開発資金と人材の支援。組織と修正の経緯。
※2 Calif・OpenAI・Wiz：AIを活用した攻撃可能性の調査、PHPへの報告・協力。PHP Foundation／Wiz。
※3 OS配布元：PHPの修正を各OS・製品で更新できるようにする。Ubuntuによる配布例。
発見・実証と修正は別工程である。AIが攻撃経路の検証を支援し、PHPの開発者が修正を実装した。また、関係者が一列に順番待ちしたという意味ではなく、修正・配布準備・注意喚起には並行した作業もあった。
なぜ行政機関や業界団体まで注意を呼びかけたのか
今回の対応は、一つの企業だけの障害ではない。広く使われる共通技術の問題だからこそ、PHP開発チームからOS配布元、クラウド・ホスティング事業者、専門機関、行政、業界団体へと連絡と対策が広がった。
10月20日（世界協定時）：PHP開発チームが重大なセキュリティ更新の予告を公表。PHP Foundationによれば、公開前にCVE番号などの情報が流出したことも、予定を前倒しする理由となった。
10月21日（日本時間）：IPAが事前準備を呼びかけ、PHPを利用するシステムの把握と迅速な更新への準備を求めた。
10月21日23時ごろ（日本時間）：修正版の提供と詳細情報の公開が進んだ。
10月22日：JPCERT/CCが、速やかな更新と侵害の有無の調査を呼びかけた。国内の業界団体も、経済産業省からの周知依頼や内閣官房国家サイバー統括室の注意喚起を案内した。
これは日本政府がすべての企業に一律の法的な更新命令を出したという意味ではない。重大な危険性と利用範囲の広さを踏まえ、各組織が適切に判断・対応できるように情報を周知したという流れである。根拠はIPAの事前案内、JPCERT/CCの注意喚起、情報サービス産業協会の案内にある。
なお、「重大な危険性がある」「攻撃が実証された」「実際の被害が確認された」は異なる。IPAは、10月22日更新の事前準備の案内で、自機関として悪用した攻撃を確認しているわけではないと明示している。カナダのサイバーセキュリティセンターは10月23日更新の通知で、PoCの公開報告を把握している一方、同機関がその時点で実際の悪用を特定したわけではないと述べている。発表日時、各機関の観測範囲、報告内容が違うため、これらを一つの確定的な世界の被害状況として扱わない。
世界各地でも進んだ防御と周知
PHPは国境を越えて使われるため、対応も国際的だった。例えば、Web通信を保護するサービスを提供するCloudflare（クラウドフレア）は、脆弱性情報の公開前にWebアプリケーションファイアウォール（WAF）の対策ルールを準備・配布したと説明している。WAFは怪しいWeb通信を遮断する仕組みだが、PHP自体の更新を代わりに済ませるものではない。Cloudflareの対応報告参照。
また、カナダのサイバーセキュリティセンターも10月21日に注意を促した。各国の警戒情報と個別企業の影響調査は区別しなければならないが、今回の問題が世界的なソフトウェア基盤に関わることが分かる。
国内に広がった情報と対応――日時で追う
海外のPHP開発チームによる公開予告は、日本の行政・専門機関・業界団体・事業者に一つの指揮命令系統で直列に伝わったわけではない。公式情報を受け取った組織が、それぞれの役割と責任に応じて、事前準備、周知、サービスの一時停止、修正適用を並行して進めた。日本の読者にとって大事なのは「誰が誰の上司か」よりも「どの組織が何の情報を伝え、どの現場がいつ動いたか」である。
国内のサイバーセキュリティ体制はどうなっているのか
国家サイバー統括室（NCO、内閣官房）は、日本のサイバーセキュリティ政策の企画・総合調整や行政機関への助言・情報提供などを担う。一方、IPAは企業や一般のシステム利用者にも役立つ脆弱性・対策情報を発信し、JPCERT/CCは技術情報の収集、国内外との調整、インシデントへの対応支援を行う。経済産業省は所管分野の関係組織との連絡を担い、JISAのような業界団体が会員企業へ情報を届ける。これは上下関係を示す一覧ではなく、異なる役割を持つ組織の分担である。今回の周知依頼はJISAの掲載資料を参照。
JISAは経済産業省から会員企業への周知依頼を受けたと明記し、内閣官房国家サイバー統括室の注意喚起資料も掲載している。しかし、「IPAが内閣官房へ上申した」「内閣官房が報道機関へ一斉指示した」「全企業に法的な更新命令が出た」といった個別の連絡・指示経路は、これらの資料からは確認できない。報道機関も、政府だけでなくPHP公式や研究企業、各事業者の発表を独自に取材する。
図2：海外での公開から国内の周知・現場対応まで（原則日本時間、予告のみUTC）
flowchart TB
subgraph T20["10月20日（世界協定時）｜海外の起点"]
P["PHP開発チーム<br/>重大なセキュリティ更新を事前予告"]
end
subgraph T21["10月21日（日本時間）｜公開前の予防措置"]
IPA["IPA：更新に備えた準備を呼びかけ"]
SCI["東京科学大学：16時ごろ<br/>サーバーの暫定的な防護設定"]
XS_STOP["エックスサーバー：16時から<br/>サービスサイト・管理画面等を一時停止"]
RAK_STOP["ラッコ：19時ごろから<br/>一部サービスを予防的に停止"]
PATCH["PHP開発チーム：23時ごろ<br/>修正版を公開"]
end
subgraph T2122["10月21日以降｜政府・業界の並行した周知"]
NCO["内閣官房 NCO<br/>注意喚起文書を発出"]
METI["経済産業省<br/>JISAへ会員企業向け周知を依頼"]
JISA["JISA：注意喚起文書を掲載<br/>会員企業へ対策を案内"]
end
subgraph T22["10月22日（日本時間）｜パッチ適用と再開"]
JC["JPCERT/CC：更新と<br/>侵害有無の調査を呼びかけ"]
XS_FIX["エックスサーバー：6時45分<br/>PHP 8.2～8.5の修正適用完了"]
RAK_FIX["ラッコ：8時43分<br/>全サービスを再開"]
LOLI["ロリポップ！：13時ごろ<br/>サイト表示を再開"]
MOF["財務省：一部コンテンツを<br/>安全確認後、順次再開"]
PRESS["新聞・専門メディア<br/>対応状況を報道"]
end
subgraph T23["10月23日（日本時間）｜メンテナンス完了の公表"]
SAKURA["さくらインターネット：17時30分追記<br/>緊急メンテナンス全件終了を公表"]
end
P --> IPA
P --> PATCH
XS_STOP -.-> XS_FIX
RAK_STOP -.-> RAK_FIX
METI -->|"周知依頼"| JISA
NCO -.->|"注意喚起文書をJISAが掲載"| JISA
PATCH --> JC
PATCH --> XS_FIX
PATCH --> RAK_FIX
PATCH --> LOLI
PATCH --> MOF
PATCH --> SAKURA
PATCH --> PRESS
図2の読み方と出典注記
時間軸：上から下へ、発表・準備・修正適用が進んだ順に配置した。日時は特に断らない限り日本時間。10月20日の予告だけは世界協定時（UTC）で表記した。PHPの予告／IPAの事前案内。
国内の周知：NCOと経済産業省、JISAは異なる役割を持ち、情報が一列に伝達されたと確認できる資料はない。経済産業省からJISAへの周知依頼とNCO文書のJISA掲載は公表文で確認できる。JISAの案内。
公開前の対応：東京科学大学は暫定対策を、エックスサーバーとラッコは一部サービス・管理画面等の予防的停止を公表した。東京科学大学／エックスサーバー／ラッコ。
修正版公表後：ITサービス事業者による修正適用・再開の報告は、JPCERT/CCの注意喚起と区別した。JPCERT/CC／ロリポップ！／さくらインターネット／財務省。
矢印の意味：公開情報と対応時期の関係を概念的に示す。矢印は各組織間の個別の指示・連絡があった証拠ではない。点線は同じ事業者の停止から再開までの経過、または資料の掲載関係を表す。INTERNET Watchの報道も参照。
どこで実際に停止や更新が行われたのか――復旧を公表した実例
予防措置と、実際に修正を適用してサービスを再開したことは別である。ここでは金融機関や一般企業の停止情報を一覧から外し、ITサービス・ホスティング事業者の公式な対応完了・再開報告と、大学・行政機関が自ら公表した事例に絞った。以下は2026年10月25日時点の公表内容であり、掲載した組織・利用者の全システムに脆弱性があった、または侵害が発生したという意味ではない。
| 分野・組織 | 公式に公表された対応・復旧状況 | 一次情報 |
|---|---|---|
| 大学：東京科学大学 | 10月21日16時ごろに暫定対策。22日14時40分に一部を除いてサービス再開。同日18時30分の追記で、更新できない旧版の環境が一部残ることも明示。 | 大学の運用部門 |
| ホスティング：さくらインターネット | 10月22日、レンタルサーバで提供する全PHP版への対応完了を案内。23日17時30分の追記で、関連する緊急メンテナンスの終了を公表。なお、一部機能の個別停止とVPS利用者が管理するPHPは別扱い。 | さくら公式 |
| ホスティング：エックスサーバー | 10月22日6時45分にPHP 8.2～8.5、12時に7.4～8.1、14時に5.6～7.3の対象サーバへの修正適用を完了。サービスサイト・管理画面は順次再開。ただしPHP 5.1～5.5は23日17時時点で全件完了ではない。 | エックスサーバー公式 |
| ホスティング：ロリポップ！ | 10月22日13時ごろに利用者サイトの表示を再開。公式修正版がない旧PHPにも事業者側で修正を作成・適用。管理画面等は同日13時34分ごろ再開し、その他の機能も順次復旧。 | ロリポップ！公式 |
| ITサービス：ラッコ | 10月21日19時ごろから一部サービスを予防停止。修正適用後の22日8時43分に、全サービス再開を公表。提供するラッコサーバーのPHPにも修正を適用したと説明。 | ラッコ公式 |
| 官公庁：財務省 | 10月22日、一時停止していた一部コンテンツについて、セキュリティ対策と安全確認が済んだものから順次公開を再開したと公表。一部は機能調整後に公開すると明記。 | 財務省公式 |
ここでいう「復旧」「対応完了」は各公表文が対象としているサービスや機能の範囲に限る。事業者が全バージョンに対処した場合でも、サポート切れのPHPを長期利用して安全という意味ではない。また、医療機関など個別の組織について公式の裏付けがない被害状況や復旧状況は推測しない。
今回の事例から分かるのは、海外の開発元の更新予告→国内での予防措置→修正パッチ適用→利用再開の公表が短期間に進んだことだ。各社の判断は同時並行であり、すべての組織が同じ時刻・順序で対応したわけではない。
企業やサイト管理者は何を確認すべきか
第一に、Webサイト、業務システム、外部委託先のサービスなどでPHPが利用されているかを把握する。PHPはアプリケーションだけでなく、機器や製品内部でも使われる場合があり、利用者が直接バージョンを確認できないこともある。
第二に、利用している製品・OSの提供元が公表した更新を確認する。PHP本家では、2026年10月21日に8.2.35、8.3.36、8.4.27、8.5.12が公開された。ただしLinuxディストリビューションや製品ベンダーは別のパッケージ番号で修正を提供する場合がある。
第三に、更新後のサービス動作を確認する。ページ表示だけでなくログイン、フォーム、API、バックグラウンド処理などの主要機能を点検する。そして更新前後のログや不審な通信・プロセスも調べる。パッチの適用は、過去に侵害されなかったことの証明にはならない。 侵害の調査ポイントはJPCERT/CCの注意喚起にまとめられている。
10月23日の追加注意事項も確認する
PHP公式は10月23日、セッションのアップロード進捗機能について追加の注意事項を公表した。アプリケーションが設定時の session.serialize_handler を php_binary または php_serialize とし、実行途中で php へ切り替えてから session_start() を呼び、アップロード進捗機能も有効になっているという、限定的な組合せに関するものだ。
PHP公式は、次の通常バグ修正版まで session.upload_progress.enabled=0 とすることを案内している。10月21日の対策で既に無効化した場合は、その設定を維持する。実行途中でシリアライズ方式を変更しないアプリケーションでは、この追加注意事項の理由で機能を無効化する必要はない。設定変更はアップロード進捗表示などへの影響を確認し、Web側で実際に使われるPHP設定へ適用する。
この追加情報はCVE-2026-115560として次回リリースで詳報する予定とされている。10月21日の2件への更新を済ませたことだけで、関連する追加案内の確認まで不要になったとは判断しない。根拠：PHP公式：10月23日のSession upload progressに関する案内。
Ubuntuで修正済みパッケージを確認する例
更新方法はOS、PHPの配布元、導入方法により異なる。例として、Linux系OSで広く利用されるディストリビューションの一つ、Ubuntuを取り上げる。これは説明用の一般的な例であり、特定のサイトがUbuntuで稼働しているという意味ではない。
Ubuntu 24.04 LTSに対してCanonicalが案内したPHP 8.3の修正済みパッケージ版数は、8.3.6-0ubuntu0.24.04.13である。Ubuntu公式通知USN-8948-1に明記されている。
図3：PHP本体の修正がUbuntuの更新になるまで
Ubuntuの開発者が脆弱性をゼロから発見し直す必要はない。 PHP開発チームの修正を基に、CanonicalがUbuntuの既存バージョンでも動くように修正を取り込み、パッケージを用意する。これがバックポートの考え方である。
flowchart TB
A["PHP開発チーム<br/>PHP本体の修正を作成・検証"]
B["Ubuntuの提供元 Canonical<br/>修正を既存パッケージへ取り込む"]
C["Ubuntu向けにビルド・検証<br/>修正版パッケージを配布"]
D["システム管理者<br/>APTで修正版を取得・適用"]
E["PHP-FPM等の稼働状態を確認<br/>必要なサービス再起動を確認"]
F["パッケージ版数・サイト機能・<br/>エラーログを点検"]
A --> B --> C --> D --> E --> F
図3の登場人物と出典
※1 PHP開発チーム：修正を設計し、本家PHPの新しいバージョンに反映。PHP Foundationの修正説明。
※2 Canonical／Ubuntu：修正をUbuntuの既存バージョンに取り込む「バックポート」を行い、検証済みの更新パッケージを配布。Ubuntu公式通知。
※3 各サイトや企業の管理者：自分の環境に合うパッケージを適用し、動作や異常の有無を調べる。JPCERT/CCの対策案内。
例えばUbuntu 24.04 LTSの標準PHP 8.3では、元のPHPバージョンが8.3.6のままでも、完全なパッケージ版数が8.3.6-0ubuntu0.24.04.13なら今回の修正を含む。実際にどのPHPが稼働しているかは別途確認する。根拠：Ubuntu USN-8948-1。
例えばPHP 8.3のCLI、FPM、共通パッケージを利用している一般的なUbuntu環境では、インストール済み版数を次のように確認できる。
php -v
dpkg-query -W -f='${db:Status-Status}\t${binary:Package}\t${Version}\n' \
php8.3-cli php8.3-fpm php8.3-common
apt-cache policy php8.3-cli php8.3-fpm php8.3-common
この例は版数を調べるための確認コマンドであり、PHPの更新を実行するものではない。dpkg-query は「状態・パッケージ名・版数」を表示する。状態が installed の行を、インストール済みパッケージとして確認する。config-files などの行に版数が出ても、そのパッケージが現在インストール済みとは判断しない。dpkg-queryの公式マニュアルを参照。
php -v は呼び出したCLIのPHPを確認する。Webサイトが使うPHP-FPMやApacheモジュールと、同じ実体・版数であるとは限らない。apt-cache policy はAPTのローカル情報を表示するため、更新候補が表示されても適用済みの証拠にはならず、古いキャッシュなら候補情報も古い。PHP CLIの公式説明とapt-cacheの公式マニュアルを参照し、インストール済み版数と更新候補、Webで使用するPHPを分けて確認する。
なお、例示した3つのパッケージがすべてのUbuntu環境に導入されているわけではない。導入されていないパッケージの表示に関するエラーは、それだけで更新失敗を意味しない。PHPの実行方法（FPM、Apacheモジュール、CLIなど）と、使っているパッケージを特定してから確認する。
最初のphp -vが「8.3.6」と表示されても、それだけで未修正とは判断できない。Ubuntuなどでは、元の版数を保ちながらセキュリティ修正を取り込むバックポートが行われるからだ。確認すべきなのは、ディストリビューションの完全なパッケージ版数と、当該ベンダーの公式通知である。
実際の照会結果から読み取れること
次はUbuntu 24.04 LTSでの確認結果から、記事の判断に必要な部分だけを抜粋・整形した例である。ホスト名、ユーザー名、CPUアーキテクチャ、APT配布先、ビルド日時など、個別環境を特定する情報は掲載しない。パッケージの更新や設定変更を行った結果ではなく、読み取り専用コマンドの出力である。
php -v: PHP 8.3.6 (cli) 状態 パッケージ インストール済み版数 installed php8.3-cli 8.3.6-0ubuntu0.24.04.13 installed php8.3-common 8.3.6-0ubuntu0.24.04.13 installed php8.3-fpm 8.3.6-0ubuntu0.24.04.13 APTの候補版数（上記3パッケージ）: 8.3.6-0ubuntu0.24.04.13
この例では、CLI・FPM・共通パッケージの3件がインストール済みで、Ubuntu公式通知USN-8948-1のPHP 8.3修正版と一致している。表示中の PHP 8.3.6 だけを見て「修正前だ」と判断するのは誤りだ。一方、APTの「候補」は取得済みのリポジトリ情報に基づくもので、常に将来の最新状態まで保証するものではない。Canonicalの修正済みバージョン一覧で照合する。
ここで確認できたのは、2026年10月21日に公表されたCVE-2026-109618／CVE-2026-109619に対応するパッケージ版数までである。WebサーバーがそのパッケージのPHP-FPMを実際に利用しているか、更新後のプロセスが再起動されているか、10月23日の追加注意事項への対処が必要かは、この3コマンドだけでは判断できない。稼働状態やサービスへの影響は別途確認する。
更新を実施する場合は、事前にバックアップ、依存関係、サービス再起動の影響を確認する。コンテナー、独自ビルド、PPA、ホスティングサービスなどでは更新手順が異なるため、一律に同じコマンドを実行しない。PHP自体の修正と、WebアプリやCMSの更新も区別する。
同じ確認を繰り返すための読み取り専用サンプルでは、指定したパッケージを順に確認し、未導入・照会失敗・候補情報の欠落を区別する。APTのリポジトリURLや生の診断文は表示せず、パッケージ更新やサービス操作もしない。終了コード0は情報を取得できた意味であり、脆弱性対策の完了判定ではない。
簡易版のPHPパッケージ状態確認サンプルは、実行結果をターミナルに直接表示する。自動ログファイルは作成しない。コードを短い関数にまとめ、トップレベルの exit を使わないため、全文をターミナルに貼り付けてもログインシェルを終了させない。
使い方は、サンプルの保存先で bash check-php-package-status.sh を実行するだけである。画面にパッケージの状態と完全な版数、APTの候補版数が表示される。実行直後に echo $? と入力すれば終了コードも確認できる。終了コード0は情報取得成功を示すだけで、安全性を保証しない。 必要な場合だけ、利用者がターミナルの結果をコピーして保存する。パッケージの更新・サービス操作・外部送信は行わない。
このサンプルはBash構文と模擬パッケージデータ、ターミナルへの直接貼り付け・エラーの扱いを確認した。利用者からは、実Ubuntuで3パッケージの版数を正常表示し、ターミナルが閉じなかったとの実行結果が提供された。ただし、PHPの更新やWeb側PHPの稼働状況を自動検証するものではない。
まとめ：AIが発見を速めても、最後は人間と運用の責任
PHP2Shellが示したのは、広く使われるソフトウェアの基盤に潜む欠陥が、外部からの不正なコード実行や情報漏えいにつながるおそれと、生成AIがその危険性の解明を速める現実である。
今回の研究では、2024年に人間の開発者が把握した問題の兆候を、2026年のAI支援研究がより深い攻撃可能性として具体化した。修正と公開はPHP開発チームが主導し、公的機関や事業者が注意喚起と更新準備に動いた。
AIによる発見能力が高まるほど、防御側には利用システムを把握し、信頼できる修正を適用し、その後も異常を監視する基本的な運用が求められる。
参考・引用資料
以下は執筆時点で確認した出典。各資料が何を裏付けるかも併記した。
PHP公式：2026年10月21日の重大脆弱性に関する告知 — CVE、深刻度、修正版。
PHP Foundation：発見から修正までの経緯（2026年10月21日） — 2024年の兆候、2026年の報告、人間による修正。
Wiz：PHP2Shellの研究報告（2026年10月21日） — AI活用、攻撃可能性の実証、技術的影響。
IPA：PHPのセキュリティリリースに向けた事前準備（2026年10月21日） — 日本での準備要請と悪用確認の区別。
JPCERT/CC：PHPの脆弱性に関する注意喚起（2026年10月22日） — 国内向け対策、侵害調査ポイント。
情報サービス産業協会：経済産業省等からのPHP2Shell注意喚起 — 行政から業界団体への周知。
Ubuntu：USN-8948-1（2026年10月21日） — ディストリビューションの修正済みパッケージ番号。
PHP公式マニュアル：入門 — PHPの役割とサーバー側の仕組み。
PHP公式マニュアル：PHPの歴史 — 1994年の誕生、1995年の公開。
W3Techs：PHPの世界的な利用統計 — 参照ページに表示された2026年10月24日の69.3％という普及率とその分母。
PHP Foundation：活動目的 — PHP開発者を支える組織の役割。
Calif：会社紹介 — セキュリティ研究会社の役割。
Wiz：会社紹介 — クラウドセキュリティ研究企業の役割。
IPA：機構概要 — 国内でのIPAの役割。
JPCERT/CC：組織概要 — 国内外とのインシデント対応調整。
JISA：協会概要 — 業界団体の目的。
Cloudflare：PHP2Shellに対するWAF対策 — 国際的な緩和策の実例。
カナダ政府：PHPの重大脆弱性に関する警告 — 10月21日の初報と10月23日の更新、悪用確認状況、追加脆弱性への注意。
PHP Foundation：PHP Core Security Audit Results（2025年4月10日） — 2024年の監査を実施したQuarkslabと協力したOSTIF、監査資金。
OSTIF：PHP Audit Complete!（2025年4月10日） — 監査実施の経緯、検証範囲、Quarkslabによる作業。
東京科学大学：WWWサーバ代行サービス暫定対策（10月21日） — 10月21日の暫定対策と、22日の修正適用・一部再開の追記。
さくらインターネット：PHP脆弱性への対応状況（10月22日、23日追記） — 対象PHP修正、関連メンテナンス終了、公表範囲。
エックスサーバー：管理画面の停止とPHPパッチ適用・再開状況 — PHP版別の適用時刻と未完了の旧版。
ロリポップ！：PHP脆弱性への対応・再開完了報告（10月22日） — サイト表示・管理画面の再開と旧版への修正。
ラッコ：PHP2Shell対応・全サービス再開報告（10月22日） — 停止開始、再開時刻、PHPへのパッチ適用。
財務省：一部コンテンツの公開再開（10月22日） — 安全確認後の再開。
INTERNET Watch：PHPの脆弱性による国内の対応（10月22日） — 報道機関による国内の状況整理。
IPA：PHP2Shellの脆弱性対策に関する続報（10月22日） — 対象バージョン、修正版、対応が難しい場合の判断指針。
PHP公式：Session upload progressの追加注意事項（10月23日） — 限定的な構成での追加対処と次回リリースまでの案内。
Ubuntu公式マニュアル：dpkg-query — 状態・パッケージ名・版数の取得と表示書式。
PHP公式マニュアル：CLIのオプション —
php -vが示す情報。Ubuntu公式マニュアル：apt-cache — ローカルキャッシュに基づく確認と更新候補の扱い。
GitHubサンプル
リンク先は検証対象のコミットへ固定している。実環境への適用前に内容と配布元の最新通知を確認する。
