AIが長年見つからなかったソフトウェアの弱点を調べ、修正につなげる。
その能力が、Webサイトを支えるPHPの重大な脆弱性への対応で具体的に示されました。
サイトを運営する側にとっては、AIの進歩と同時に、利用中のサーバー環境を確かめる必要が生じた出来事です。
2026年10月21日に修正版が公開された「PHP2Shell」は、特定の企業や一つのプラグインだけの問題ではありません。
PHPという共通基盤にある欠陥のため、自社でPHPのコードを書いていなくても、利用サービスの内部で関係する場合があります。
ただし、影響を受ける可能性と、すでに被害が出たという事実は別です。
本記事では2026年10月24日時点の公式情報をもとに、AIが担った役割と、運営者が対応を判断するための確認事項を整理します。
PHPは、サーバー側でプログラムを動かし、Webページやデータを生成するために広く使われる言語です。
WordPressなどのCMSも、その上で動作します。
CMSを店舗に例えるなら、PHPは店内の設備を動かす土台に近く、目に見えるページの品質だけでは安全性を判断できません。
今回の2件は「CVE-2026-109618」と「CVE-2026-109619」です。
PHP側のセキュリティアドバイザリーでは、いずれも認証なしのリモートコード実行につながる重大な問題として扱われています。
これは、条件が成立した場合に、管理画面へログインしていない第三者がサーバー上でコードを動かせる危険を意味します。
前者は、メモリ不足で処理が中断された際に、不完全な内部データを有効なものとして扱ってしまう問題です。
後者では、処理を終えて解放したメモリへの参照が内部に残り、同じワーカーが後のリクエストを処理した際に使われることがあります。
通常のアクセスが正常でも、特殊なリクエストやエラー時に弱点が表面化し得る仕組みです。
出典：PHPセキュリティアドバイザリー
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
PHPの公式発表は、Webリクエストを処理するPHPの各種実行環境に確認を求め、Apacheのmod_phpを特にリスクの高い構成としています。
一方、実際の攻撃の成立条件や信頼性は、ビルド、拡張機能、アプリケーションの動作などで異なります。
したがって、「管理者パスワードが長い」「二要素認証を使っている」という確認だけで、この問題への対応は完了しません。
認証を通らずに到達する処理もあるため、保護する層に合わせた対策が必要です。
アカウント保護は続けながら、サーバー側の更新状況を別に確かめてください。
OpenAIによると、セキュリティ企業Califは「Patch the Planet」の取り組みの一環としてGPT-5.6 Solを利用し、重大な欠陥を特定しました。
Wizも独立した調査で脆弱性を発見・報告しています。修正とリリースはPHPのメンテナーが主導し、関係企業が調査や調整を支援しました。
Wizが公表した調査では、Wiz Atlas、Gemini 4 Argon、GPT-5.6 Solを利用しています。
同社は、環境ごとに異なる条件を調べ、検証を繰り返す過程でAIが役立ったと説明しました。
Google Cloudも、Gemini 4 Argonが発見、攻撃の検証、検知、パッチ検証に貢献したとしています。
ここから分かるのは、AIがコードを一度読んで危険箇所を指摘しただけではないということです。
発見した問題がどの条件で起こるのかを調べ、修正を確かめる作業にも使われました。
「AIがすべて自動で解決した」とまとめると、人の判断や組織間の調整が抜け落ちます。
出典：OpenAI／Wiz／Google Cloud
https://openai.com/ja-JP/index/coordinated-disclosure-of-critical-vulnerabilities/
https://www.wiz.io/blog/php2shell-php-rce
https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/
PHP Foundationの説明では、メモリ不足に関係する問題の兆候は2024年の監査に続く作業ですでに把握されていました。
ただし、具体的な攻撃経路の確認や、互換性・性能への影響を踏まえた修正には難しさがあり、対応が停滞した経緯も公表しています。
その後、Califなどからの報告によって影響が明確になり、修正の優先度が引き上げられました。
この経緯を踏まえると、「人間は何も気づかず、AIだけが突然見抜いた」という描写は正確さを欠きます。
編集上の見方として、今回の転換点は、疑われていた弱点を現実的な危険として確かめる調査が進んだことにあります。
見つける能力が高まっても、互換性を維持して直し、各サービスへ届ける仕事は残ります。
AIの導入と、修正を受け止める開発・運用体制への投資は、一緒に考える必要があります。
出典：PHP Foundation
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
今回確認すべきなのは、公開サイトを実際に動かしているPHPの状態です。
WordPress本体、テーマ、プラグイン、PHPは別の構成要素であり、CMSの管理画面で更新を終えたことから、サーバー側の修正まで適用済みだとは判断できません。
また、同じ契約内でも、メインサイトと旧サイト、管理画面、サブドメインが別の環境で動くことがあります。
普段使うページだけ確認して終えると、古い予約フォームや過去のキャンペーンサイトが確認から漏れます。
運営上は「何を更新したか」より、「どの公開環境に修正が反映されたか」を記録すると対応範囲が明確になります。
以下は担当の切り分けに使える表です。実際の責任範囲は契約によって異なるため、依頼先との確認用として利用してください。
制作会社がページを作り、サーバー会社が実行環境を管理する契約では、窓口が分かれることもあります。
連絡先をたらい回しにしないため、対象ドメインと契約情報を添えて、どちらがPHPの更新を担うかから確認すると話が進みます。
一般の利用者は、他社サイトのPHPを自分で更新できません。
サービスの公式案内に被害や利用者向け対応が記載された場合は、その内容に従います。
予防メンテナンスの告知だけを見て、すべての登録サービスで情報が漏れたと決めつける必要はありません。
一方、サイト運営者は、外部委託していても影響確認の結果を把握しておく必要があります。
「お任せしている」状態から、対応済みの範囲と未対応部分を説明できる状態へ進めることが、顧客への案内にもつながります。
WizはPHPの広い普及を背景に、今回の影響を大きく評価しています。
ただし、PHPの利用率をそのまま「世界のサイトの約70％が侵入された」「同じ方法で必ず攻撃できる」と読み替えることはできません。
調査による利用率には集計対象や技術の判別条件があり、さらに実際の危険性にはバージョン、適用済みの修正、設定、公開範囲が関係します。
本記事では、対象サイト全体の被害率として「70％」を見出しに使いません。読者が知るべきなのは、自分の環境が未修正かどうかです。
同様に、サービス停止にも区別があります。
侵入を受けて止まる場合と、修正中の露出を減らすために停止する場合では、意味が異なります。
攻撃の試行を検知したという発表も、攻撃が成功して情報を持ち出されたという発表とは分けて読む必要があります。
脆弱性対応では、発見日、開発者への非公開報告日、一般公開日、修正版の配布日が一致するとは限りません。
報告から公開まで時間があることだけで、利用者が知っていた問題を放置したと判断するのも早計です。
「公表の何日前から攻撃された」といった記述には、観測した組織、対象の脆弱性、観測時刻、侵入の成否が必要になります。
今回の添付図にある個別の日時や被害を示す表現も、そのまま事実として採用せず、一次資料で確認する扱いとします。
PHPは10月23日、セッションのアップロード進捗機能と特殊な設定変更が組み合わさる場合の問題について、追加の注意喚起を公開しました。
対象は、セッションのシリアライズ方式を特定の方式から実行時に切り替えるなど、限定された条件のアプリケーションです。
PHP側は発生しにくい構成と説明し、CVE-2026-115560の詳細な勧告を次のリリースで公表するとしています。
関連する緩和策として案内されている設定は「session.upload_progress.enabled=0」です。
対象条件と反映方法は担当者が公式案内で確認し、事業者の管理環境では独断で変更せず対応方針を尋ねてください。
これは当初の2件と区別して管理する必要があります。
「21日の修正版を入れた」という記録に加え、23日の案内を確認したかどうかも残すと、後から対応状況を検証できます。
出典：PHP公式ニュース／CERT-EU
https://www.php.net/archive/2026.php
https://cert.europa.eu/publications/security-advisories/2026-018/
10月21日に公開された当初の2件の修正版は、次のとおりです。
これは公開時点の対応表であり、導入時には利用事業者の最新案内も確認してください。
OSや商用の保守事業者が、元のバージョン番号を保って修正を移植する場合もあります。
画面に出る数字が表より小さいことだけで、直ちに未対応とは断定できません。
事業者の更新履歴や、該当CVEへの対応記録と照合してください。
逆に、コマンドラインで新しいPHPを確認できても、Webサイトが別のPHPで動いていれば確認は不十分です。
Google Cloudも、利用形態に応じてイメージの再構築や再配備などを案内しています。
更新ファイルの存在と、実際に動く環境への反映を分けて確かめる必要があります。
出典：PHP公式／Google Cloud
https://www.php.net/archive/2026.php
https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619/
委託先への確認には、次の項目が使えます。
最後の項目は、更新と被害確認が異なるためです。
修正は今後の悪用を防ぐ作業であり、すでに起きた侵入を取り消す処理ではありません。
不審なファイル、プロセス、外部通信などがある場合は、ログや証拠を保全し、保守会社やセキュリティ担当と調査範囲を決めます。
WAFによる遮断やアクセス制限は、更新までの露出を減らす補助手段です。
PHP側は、当初の2件を完全に修正するには更新が必要としています。
更新できない場合、CERT-EUは公開ネットワークからの隔離も検討するよう勧告しています。
また、担当者のPCにセキュリティソフトを入れても、別の場所で動くPHPサーバーの修正にはなりません。
端末保護、Webへのアクセス制御、PHPの更新は担当する場所が違います。
追加製品の検討より先に、今回必要な更新を誰が実施するかを確定させる方が、対応の抜けを防げます。
サイト運営者がまず確保したいのは、「利用中の環境について、誰が、どの修正を適用し、どう確認したか」という記録です。
未確認の部分があれば、契約先に対象ドメインを伝え、対応範囲と完了予定を確認してください。
AIによって調査が進むほど、見つかった問題を運用へ反映する力も問われます。
今回の対応を機に、サーバーの管理先、緊急時の連絡先、更新の判断者を整理しておけば、次の注意喚起にも着手しやすくなります。
関連する国内事例は、AI TOP TIERの「2026年10月のサイバー攻撃」記事も参照してください。
個別事例を読む際には、脆弱性対応による停止と、確認された攻撃被害を区別しましょう。
.png){kind=logo}
