php2shell: PHPの深刻な脆弱性

phpの脆弱性(php2shell)

今回のサーバー停止とエラー表示は、ご推察の通り、PHPの重大な脆弱性（セキュリティ上の欠陥）に対応するため、GMOペパボ（Hetemlおよびロリポップの運営元）が実施した緊急メンテナンスが原因です。   
ITmedia

今回判明したPHPの欠陥に関する主な情報は以下の通りです。

脆弱性の深刻度: 10月21日、ウェブサイトの多くを動かしているプログラミング言語「PHP」に、「php2shell」（CVE-2026-109618、CVE-2026-109619）と呼ばれる極めて深刻な欠陥が発表されました。これを放置すると外部から不正アクセスを受け、最悪の場合はサーバーを乗っ取られる危険性があります。   
はてなブックマーク

極めて高い緊急性: 攻撃者がこの欠陥を悪用するスピードが非常に速いと懸念されたため、情報処理推進機構（IPA）や政府の国家サイバー統括室が速やかな対応を強く呼びかけました。高市首相も公式アカウントで大至急の対応を呼びかけるほどの緊急事態でした。   
ITmedia

各社の一斉対応: 修正プログラムは21日の午後11時頃に公開されました。これを受け、GMOペパボをはじめ、さくらインターネットやエックスサーバーなど国内の主要サーバー各社は、被害を未然に防ぐためにサービスを一時停止し、緊急のアップデート作業を一斉に実施しました。   
KFB福島放送

ご自身のサイトのデジタルアーカイブや問い合わせフォームなどでPHPスクリプトを活用されていますが、今回の件はお客様が記述したコードのミスではなく、PHPという言語の実行環境そのものの欠陥です。Hetemlやロリポップのような共用サーバーを利用している場合、基盤となるPHPのシステム更新はサーバー会社側が行うため、ご自身で設定変更やアップデートを行う必要はありません。

今回のPHPの重大な脆弱性（通称「php2shell」、CVE-2026-109618およびCVE-2026-109619）は、どこかで実際の被害やシステム障害が発生したことで発覚したわけではありません。一般的に、こうした欠陥はセキュリティ専門の研究者が調査の過程で発見し、開発元（The PHP Group）へ非公開で報告します。   
Webの相談所

今回NHKのニュースなどで大きく報じられ、GMOなどのサーバー提供会社が緊急停止の措置をとる事態になった最大の理由は、「公式の修正プログラムが配布される前に、欠陥に関する情報がインターネット上に漏洩してしまったから」です。

この脆弱性の具体的な危険性と、各社が緊急対応に追われた背景は以下の通りです。

危険性の高さ: メモリ不足が発生した際の処理の欠陥を悪用するもので、パスワード等による認証を一切行わずに、外部からサーバー上で任意のプログラムを実行（リモートコード実行）できてしまう極めて深刻なものでした。また、PHP 5以降のほぼすべてのバージョンという非常に広い範囲が対象でした。   
Security NEXT

「ゼロデイ(*)」状態の発生: 欠陥の情報が先に漏洩したことで、公式の修正プログラムが公開される（日本時間10月21日23時前倒し公開）よりも前に、世界中の攻撃者がこの弱点を狙った自動攻撃ツールを作成し、一斉攻撃を始める危険性が急浮上しました。   
Webの相談所
(*ゼロデイ(攻撃): OSやソフトウェアの脆弱性（セキュリティ上の欠陥）が発見された際、開発元が修正プログラム（パッチ）を配布する前に行われるサイバー攻撃またはその脆弱性自体)

サーバー各社の緊急防衛措置: 修正プログラムを適用する前の無防備な状態のサーバーを守るため、ホスティング各社は、特定の通信（海外からのPOSTリクエストなど）を強制的に遮断したり、一時的にサーバー自体をメンテナンス状態にして通信を止めるという緊急措置をとらざるを得ませんでした。

つまり、サイバー攻撃による被害が実際に広がる前に、サーバー運営会社側が先手を打ってシステムを強制停止し「防御」を行ったため、お客様のサイトでも502 Bad Gatewayエラーが発生していたという状況になります。

ゼロデイ攻撃

ウェブを検索しました
はい、その後の続報がいくつか出ています(10月23日時点)。

公表前の攻撃について

Amazonは、10月17日(公表の4日前)に、おとりシステム「MadPot」への攻撃試行を確認しました。発信元は商用の匿名化ネットワーク上のIPアドレスでした。 
amazon
Amazonは、この攻撃者が公表前にどうやって悪用情報を入手したのかは不明としています。 
theregister
21日の公表日当日には、協定世界時2時ごろを最初として複数のPoC(実証コード)が確認され、2時から8時にかけて別々の匿名化インフラから追加の攻撃試行がありました。ペイロードや匿名化手段が異なるため、複数の攻撃者によるものと見られます。 
amazon
これらの試行が実際のシステムで成功し得たかどうかは、分析中です。 
amazon

情報漏えいの経緯

21日未明に2件の脆弱性の存在がSNSなどで先に広まり、PHP側は更新の配信を22日夜から21日夜へ前倒ししました。 
itmedia
21日午前5時ごろ、研究者のCalifが脆弱性に関する動画を誤って公開し、複数のターゲットで動作するPoCが示されました。動画は削除されたものの、コピーが出回りました。 
itmedia
PHP財団は、供給網セキュリティ企業のChainguardが、合意された公開期限より前にパッチ済みビルドを公開したと非難しています。 
theregister
ただしAmazonの10月17日の検知は、その件よりも前に攻撃を試みた者がいたことを示しています。 
theregister

その後の状況

セキュリティ企業Hadrianは21日、「PHP2Shell」が大規模に悪用されていると警告しました。攻撃の多くはPHPのセッションアップロード進捗の経路を悪用しているとのことです。 
theregister
watchTowrも、実際の攻撃を確認したと報告しています。 
watchtowr

日本経済新聞によると、22日には米国のテック企業が数百万件の攻撃試行を検知したと明らかにしました。Amazonは、AIなら数分足らずで欠陥を悪用できると警鐘を鳴らしています。 
nikkei
対策

修正版は、PHP 8.5.12、8.4.27、8.3.36、8.2.35です。PHP 7.4〜8.1には公式リリースがなく、セキュリティチームによる最小限のソースバックポートのみです。PHP 7.3以前はサポート終了で、PHPプロジェクトによる修正はありません。 
tenable
PHPは、設定変更だけでは脆弱性を完全には塞げないとしており、完全な対策は更新のみです。 
watchtowr
GMO Flatt Securityも、「session.upload_progress.enabled = 0」にするだけでは対策にならず、迂回して攻撃される見込みだと追加調査で判断しています。 
impress
Amazonは、調査を公表日ではなく、確認された最初の攻撃である10月17日までさかのぼって始めるよう呼びかけています。 
amazon
自分のサーバーでPHPを使っている場合は、バージョンの確認と更新に加え、10月17日以降のアクセスログの確認をおすすめします。ご利用の環境(レンタルサーバー、WordPressなど)に合わせた確認方法が必要でしたら、お知らせください。

Sources:

Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure
The Register: Hackers pile on PHP2Shell
ITmedia NEWS: PHP脆弱性“PoCフライング公開”の経緯
日本経済新聞: PHP欠陥｢AIなら数分で標的に｣
Tenable: php2shell FAQ
watchTowr: PHP2Shell
窓の杜: PHPの脆弱性2件

PHPバージョン

GMOのレンタルサーバーhetemlとlolipopを使っています。PHPのバージョンはどのようにして確認しますか

ウェブを検索しました
検索ではロリポップとヘテムル固有の手順や、PHP2Shellへの対応状況は確認できませんでした。以下は一般的な手順です。管理画面のメニュー名は変わっている可能性があるので、実際の表示に合わせて読み替えてください。

方法1: 管理画面で確認する(手軽)
ロリポップ: ユーザー専用ページにログインし、「サーバーの管理・設定」の中の「PHP設定」を開きます。ドメインごとに現在のバージョンが表示され、変更もここでできます。
ヘテムル: コントロールパネルにログインし、サーバー設定の中の「PHP設定」(またはPHPバージョン切替)を開きます。こちらもドメインごとに設定します。
ドメインごとにバージョンが違うことがあるので、複数のサイトを運営している場合は全ドメインを確認してください。

方法2: phpinfoで確認する(正確)
管理画面には「8.3.x」のような大まかな表示しか出ないことがあります。今回の修正版は8.5.12、8.4.27、8.3.36、8.2.35のようにパッチ番号まで指定されているため、細かいバージョンはこの方法で確認するのが確実です。

次の1行だけを書いたファイル(例: info.php)を作ります。
php
   <?php phpinfo(); 
サーバーのサイトの公開フォルダにアップロードします。
ブラウザで https://自分のドメイン/info.php を開き、ページ上部の「PHP Version」を見ます。
確認したらすぐに、サーバーからファイルを削除してください。 phpinfoにはサーバーの内部情報が多く含まれ、今のように攻撃が活発な時期に残しておくのは危険です。
確認後の判断
対応バージョン(8.5.12、8.4.27、8.3.36、8.2.35)以上であれば、修正済みです。
PHP 8.1以前の場合は、公式の修正版がありません。可能なら8.2以降への切り替えを検討してください。ただし、WordPressのプラグインやテーマが新しいバージョンに対応していないとエラーになることがあるため、事前にバックアップを取り、切り替え後に表示を確認してください。
管理画面で選べる最新の8.x系にしても、レンタルサーバー側のパッチ適用が済んでいなければ、脆弱性が残る可能性があります。phpinfoで出たバージョンが修正版かどうかが、最も確実な判断材料です。
ロリポップとヘテムルのお知らせページやサポートからの告知で、PHP2Shellへの対応状況を確認しておくと安心です。
phpinfoで出たバージョンを教えていただければ、修正済みかどうかを一緒に判断できます。

PHP logo

PHP Version 7.4.33 と出ました。

7.4.33はPHP 7.4系の最終の公式リリースで、公式の修正版は出ていません。PHP2Shellの修正版は8.2以降だけなので、このまま使い続けるのは避け、バージョンを上げることをおすすめします。

PHPプロジェクトは、7.4〜8.1については最小限のソース修正を配布しているだけです。レンタルサーバー側が独自に対処している可能性もゼロではありませんが、phpinfoの表示だけでは判断できません。ロリポップとヘテムルのお知らせでPHP2Shell対応の告知がない限り、未対応と考えて動くのが安全です。

優先してやること
phpinfoのファイルを削除する。 まだ残っていれば、すぐ消してください。
バックアップを取る。 サイトのファイルとデータベースの両方です。
PHPのバージョンを上げる。 管理画面のPHP設定で、8.3か8.4(選べれば8.5)に切り替えます。8.2も修正版はありますが、サポート期間が短いので、新しい方が無難です。
切り替え後に表示を確認する。 7.4から8.xへの切り替えは変更が大きく、古いプラグイン、テーマ、自作のPHPコードでエラーが出ることがあります。エラーが出たら元のバージョンに戻せますが、戻している間は脆弱な状態になります。
phpinfoで再確認する。 8.3.36以上、8.4.27以上などになっているかを見ます。確認したらファイルはまた削除してください。
切り替え前後に気をつけること
WordPressを使っているなら、先にWordPress本体、テーマ、プラグインを最新に更新してから切り替えると、エラーが起きにくくなります。
画面が真っ白になる、エラーメッセージが出るといった場合は、対応していないプラグインやテーマが原因であることが多いです。
切り替えをすぐにできない場合の暫定策として、不要なサイトの停止や、アクセス制限も有効です。ただし、公式には完全な暫定策はないとされています。
ログの確認
攻撃は10月17日から確認されているので、可能ならアクセスログを17日までさかのぼって確認してください。見慣れないファイル(特に最近作られた.phpファイル)がないかも、FTPやファイルマネージャで見ておくと安心です。

使っているのがWordPressなのか、自作のPHPなのかを教えていただければ、バージョンを上げる際の注意点をもう少し具体的にお伝えできます。

自作のサイトですが、管理画面でphpのバージョンの選択ができます 8.5(CGI版)と8.3(モジュール版)があります

どちらの版も修正版の対象です。8.5(CGI版)をおすすめします。 理由は次のとおりです。

8.5は、今回の修正版(8.5.12)が出ている最新系統で、サポート期間も長いです。
8.3(モジュール版)にする場合は、8.3.36以上であることを確認する必要があります。
PHP2Shellは、研究者の公開した動画ではmod_phpやphp-fpmといった構成で攻撃が再現されています。CGI版とモジュール版でどちらが安全かは確認できていないため、その差には頼らず、修正版のバージョンになっているかどうかで判断してください。
切り替えの手順
サイトのファイルとデータベースのバックアップを取ります。
管理画面で、使っているドメインのPHPを8.5(CGI版)に変更します。
サイトを開いて動作を確認します。
phpinfoで、バージョンが8.5.12以上になっているか確認します。確認後、phpinfoのファイルは削除してください。
重要なサイトで不安なら、まずサブドメインなど影響の小さいところで試すと安心です。

自作サイトで7.4から上げるときの注意点
7.4から8系への切り替えでは、次のような点でエラーや警告が出ることがあります。

存在しない配列キーや未定義の変数を使うと、警告が出るようになりました。
文字列と数値の比較の結果が変わりました。たとえば0 == "abc"が、以前は真でしたが偽になります。
関数に型の合わない値を渡すと、警告ではなくエラー(TypeError)で止まるようになりました。
create_function()など、廃止された関数が使えなくなりました。
nullを文字列関数に渡すと、非推奨の警告が出ます。
エラーが出る場合は、サーバーのエラーログを見ると、原因の行がわかります。画面が真っ白になるときも、ログに理由が残っていることが多いです。

CGI版を選ぶときの注意
モジュール版と違い、CGI版では.htaccessのphp_valueやphp_flagが使えません。これらを書いている場合は、php.iniでの設定に変える必要があります。心当たりがあれば、切り替え後に確認してください。

切り替えてエラーが出たら、そのメッセージを貼っていただければ、原因と直し方を一緒に探します。

"バージョン変更"の隣にphp.ini の設定ボタンがあります

そのボタンから、php.iniの設定を変更できます。先ほど書いた「CGI版では.htaccessのphp_valueが使えない」件は、そこで代わりに設定する形になります。

.htaccessにphp_valueやphp_flagを書いていなければ、触る必要はありません。そのまま切り替えて大丈夫です。
書いている場合は、同じ設定(例: upload_max_filesize、memory_limit、display_errors)をphp.iniの設定画面に移してください。
バージョンを切り替えたあとは、php.iniの設定画面も開いて、設定が引き継がれているか確認しておくと安心です。サーバーによっては、バージョンごとに設定が別になっていることがあります。
この画面で、PHP2Shellを防ぐ設定はできないと考えてください。GMO Flatt Securityは、session.upload_progress.enabled = 0にするだけでは迂回されるとして、これを完全な対策としていません。PHPも、設定変更では完全に塞げないとしています。対策はバージョンを上げることだけです。

切り替えたあとの表示やphpinfoの結果で、気になる点があれば教えてください。

8.5.12に変わっていました。

8.5.12なら、PHP2Shellの修正版です。この件については、修正済みになりました。

残りの確認
phpinfoのファイルを削除する。 まだ残っていれば、すぐ消してください。
サイトの動作を確認する。 トップページだけでなく、フォームの送信やログインなど、PHPを使う機能も一通り動かしてみてください。エラーが出たら、そのメッセージを教えてください。
もう片方のサーバーも確認する。 ロリポップとヘテムルの両方を使っているとのことでしたので、今確認したのがどちらか、もう一方は何のバージョンかを見てください。ここで見たのは1つだけです。
ログとファイルを確認する。 更新前の攻撃を受けていた可能性があるため、できれば10月17日以降のアクセスログに不審な点がないか見てください。見覚えのない.phpファイル、特に最近作られたものがないかも、ファイルマネージャやFTPで確認しておくと安心です。
ログの見方や、不審なファイルの見分け方が必要でしたら、お伝えします。

ロリポップはwordpressです

ロリポップはWordPressなのですね。先ほど確認した8.5.12は、ロリポップとヘテムルのどちらのバージョンでしたか。自作サイトの方が8.5.12に変わったのであれば、WordPress側のPHPはまだ未確認です。

WordPress側のPHPバージョンの確認
phpinfoのファイルを作らなくても、WordPressの管理画面から確認できます。

管理画面の「ツール」→「サイトヘルス」を開きます。
「情報」タブを開き、「サーバー」の項目を見ます。
「PHPバージョン」に、8.5.12のような数字が出ます。
ロリポップの管理画面のPHP設定にも、ドメインごとのバージョンが出ています。

7.4など古いままの場合の手順
WordPressは、自作サイトより先に更新の準備が必要です。

バックアップを取る。 サイトのファイルとデータベースの両方です。ロリポップのバックアップ機能やプラグインでも構いません。
WordPress本体、テーマ、プラグインを最新に更新する。 古いままPHPだけ上げると、エラーで管理画面に入れなくなることがあります。
使っていないプラグインとテーマは削除する。 更新が止まったものは、PHPを上げたときにエラーの原因になりやすく、攻撃の入り口にもなります。
ロリポップのPHP設定で、8.5(CGI版)か8.3(モジュール版)に切り替える。 8.3の場合は、バージョンが8.3.36以上かを確認してください。
サイトを確認する。 表示、ログイン、投稿の保存を試します。
サイトヘルスで、PHPバージョンを再確認する。
切り替え後に画面が真っ白になったり、管理画面に入れなくなったりしたら、PHP設定で元のバージョンに戻すと復旧します。戻している間は脆弱な状態なので、原因のプラグインやテーマを特定して、できるだけ早く再挑戦してください。

補足
WordPressはPHP 7.4から8.5への切り替えで、古いテーマやプラグインがエラーを出しやすいです。切り替え後にエラーが出たら、そのメッセージを教えてください。

ロリポップとヘテムルのどちらがどのバージョンか、教えていただけますか。

8.5.12は自作のほうです。

了解しました。自作サイトは修正済みなので、残るのはロリポップのWordPressです。こちらのPHPバージョンはまだ確認できていません。

次にやること
ロリポップの管理画面のPHP設定、またはWordPressの「ツール」→「サイトヘルス」→「情報」→「サーバー」で、現在のバージョンを確認します。
8.5.12以上(8.3なら8.3.36以上)なら、修正済みです。
7.4など古いままなら、前のメッセージの手順で進めてください。バックアップ、WordPress本体・テーマ・プラグインの更新、PHPの切り替え、表示確認の順です。
先ほどの7.4.33が、どちらのサイトで出たものかはまだ確認できていません。もしロリポップ側で出たものであれば、WordPressは今も7.4のままの可能性が高いです。

確認したバージョンを教えていただければ、次の手順を具体的にお伝えします。

wordpressは8.2.35です

8.2.35は修正版です。ロリポップのWordPressも、PHP2Shellについては修正済みになっています。これで自作サイトとWordPressの両方が対応できました。

残りの確認
WordPressの動作確認。 表示、ログイン、投稿の保存が問題なく動くか見てください。
phpinfoのファイルが残っていないか。 作っていれば削除してください。
ログとファイルの確認。 更新前の攻撃を受けていた可能性があるので、できれば10月17日以降のアクセスログに不審な点がないか、見覚えのない.phpファイルがないかを見ておくと安心です。WordPressなら、wp-contentフォルダやアップロードフォルダの中は特に確認する価値があります。
今後のこと
PHP 8.2は旧バージョン扱いで、公式のセキュリティサポートは今年末ごろに終わる見込みです。正確な日付は、公式のサポート表で確認してください。年内に余裕のあるときに、WordPress本体、テーマ、プラグインを最新にしてバックアップを取ったうえで、8.3以降に上げておくと安心です。急ぐ必要はありませんが、サポートが切れる前に済ませておくのがおすすめです。

ログの見方や不審なファイルの見分け方が必要でしたら、お伝えします。

未発表情報の漏洩

一通り自分が管理しているサイトの処置・確認が済んだので、php2shellに関連するチャットに戻った。

今回の公表前の攻撃については、AI同志で情報が伝わったという見方はありませんか

ウェブを検索しました
私が調べた範囲では、「AI同士で情報が伝わった」という見方を示した報道や分析は見つかりませんでした。誰がどうやって情報を得たのかは、現時点では不明のままです。

確認できていること
Amazonは、攻撃者が公表前にどうやって悪用の情報を入手したかは不明としています。匿名化されたIPアドレスから、おとりシステムが狙われたことから、攻撃者の活動と見ています。 
techtarget
thehackernews
一部の報道では、情報漏えいや内部関係者の関与、Amazon側のシステムへの侵入を裏づける証拠はないとされています。 
techtimes
別の解説記事は、考えられる経緯として、公表前の調整に関わった事業者や研究者からの漏えいと、公式発表前に非公開の場で情報が出回った可能性を挙げています。ただしいずれも推測で、確認されたものではありません。
AIが関わる可能性
AIが情報の「伝達」役をしたという説は見当たりませんが、AIが攻撃者の「再発見」を助けた可能性については、示唆する記述があります。

今回の脆弱性そのものが、Califなどが、OpenAIのPatch the Planet*の取り組みの中で、AIを使って発見したものです。AIを使った別々の複数のチームが、それぞれ独立に同じ欠陥へたどり着いています。 
innovatopia
(*Patch the Planet（パッチ・ザ・プラネット）」とは、2026年6月に発表された、AI（人工知能）を活用してオープンソースソフトウェア（OSS）などの重大な脆弱性を迅速に発見し、修正・パッチ適用を世界規模で支援するセキュリティ・イニシアチブ。)

TechTargetの記事は、PHPの公表が近いと知った別の関係者が、その夜のうちに、社内のAI環境と最先端のモデルで同じ脆弱性を独立に見つけたと伝えています。この人物が攻撃者だったという話ではありませんが、AIを使えば短時間で同じ穴に到達できることを示しています。
Amazonも、エンバーゴ(*)が防御側を守れるのは、他の誰かが同じバグを発見するまでの間だけだと述べています。 
amazon
(*エンバーゴ（embargo）とは、報道関係者に対して「指定された日時までは発表内容を公表してはいけない」とする取り決めのこと)

一方、Cloudflareのプリンス氏は、攻撃するには対象の環境(DebianかUbuntu(*)か、どのコンテナイメージかなど)を知る必要があり、悪用は難しい脆弱性だと述べています。 
techtarget
(* • Ubuntu: 約6カ月ごとに新バージョンがリリースされ、2年ごとのLTS（長期サポート）版もある。新しい技術やソフトウェアを早く取り入れる。
    • Debian: 固定スケジュールはなく、約2年おきに十分なテストを経てリリースされる。非常に高い安定性を誇る。)

私の整理
17日の攻撃者が、(a)どこかから情報を得たのか、(b)AIを使って独立に見つけたのかは、今ある情報では切り分けられません。AIで独立に発見される可能性は、実際に3チームが別々に見つけていることからも、現実的です。ただ、それが17日の攻撃者の説明になるかどうかは、確認されていません。また、公表前に実際のシステムが侵害されたという記録はなく、確認されているのは試行だけです。 
shattered

今後、AmazonやPHP財団から追加の調査結果が出る可能性があります。続報を調べることもできますので、必要でしたらお申し付けください。

Sources:

Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure
TechTarget: PHP2Shell disclosure unravels
Tech Times: Someone Knew About PHP’s Critical Flaws
shattered.io: PHP2Shell Attacks Began 4 Days Before Disclosure
innovaTopia: PHP2Shell、AIが見つけたPHPの重大脆弱性
InfoWorld: PHP2Shell exposes the weakness in coordinated vulnerability disclosure

AI同志の情報と漠然とした疑問をもちましたが、例えばChatGPTというのはどのような構造になっていますか? 一つの超巨大なプログラムなのか、企業の事業部のように分化しているものなのか

ご質問の二択でいうと、中心にあるのは「一つの巨大なもの」ですが、それを包むサービス全体は「事業部のように分化したもの」に近い、というのが実態です。

中心にあるモデル
ChatGPTの頭脳にあたる大規模言語モデルは、人が手で書いた巨大なプログラムではありません。「重み」(パラメータ)と呼ばれる数千億個規模の数値の集まりで、大量の文章を学習する過程で自動的に調整されてできたものです。それを動かすプログラム自体は比較的小さく、知識や振る舞いのほとんどは数値の中に溶け込んでいます。ソフトウェアの感覚でいうと、巨大なソースコードではなく、巨大な設定ファイルを小さな実行エンジンが読んでいるイメージです。

モデルの内部には、入力に応じて一部の「専門家」部分だけを使う、Mixture of Experts(MoE)という分割の仕組みを採用したものもあります。ただ、これは会社の事業部のように人が役割を決めて分けたものではなく、学習の結果として自然に役割が分かれたものです。また、ChatGPTの各モデルが実際にどういう構造かは、OpenAIが詳しく公表していないので、外部から断定はできません。

周りを固めるシステム
一方、ユーザーがChatGPTとして使っているものは、モデル単体ではなく、複数の部品が組み合わさったサービスです。たとえば次のようなものがあります。

会話の履歴や、ユーザーに関する記憶を管理する部分
有害な入出力を検知する安全用の仕組み
Web検索、プログラム実行、画像生成といった道具(ツール)
質問の難しさに応じて、軽いモデルと高性能なモデルを振り分ける仕組み
こちらは、複数の部署が連携する会社に近いものです。

「AI同士」の情報伝達との関係
ここが、先ほどのご疑問に関わる点です。

モデルの重みは、会話の最中には変化しません。ある会話で聞いたことを、別のユーザーとの会話や、別のAIに自動的に伝える仕組みはありません。
AI同士が情報をやりとりするのは、人間が設計した「テキストのやりとり」を通じてです。たとえば、複数のAIに役割を分けて連携させるエージェントの仕組みや、Webに公開された文章を別のAIが読む場合です。
つまり、AIがAIに秘密を直接渡すような経路は、今の仕組みでは考えにくいです。情報が伝わるとすれば、人間が貼り付けたり、AIが読み書きできる共有の場所を経由したりするケースです。
今回のPHP2Shellの件で現実的なのは、AIが情報を伝えたというより、AIを使った人間が、同じ欠陥に独立してたどり着くことです。

私自身はClaudeで、ChatGPTの内部を直接知っているわけではありません。ここで述べたのは、公表されている情報と、大規模言語モデル全般に共通する仕組みの説明です。

今回の欠陥はテスト中に発見されたとのことですが、テストの結果を外部に漏らすことは禁じられていると思いますがそれでも漏れたのですか?

少し補足しますと、今回は「テスト中の結果が漏れた」というより、調整された公表の手続き(エンバーゴ)の途中で、情報がいくつかの経路から外に出たというのが実態です。

発見から公表までの流れ
AIを使った研究者たちが、8月にPHPの開発チームに脆弱性を報告しました。それから約2か月、公表日まで内容を伏せたまま、修正の準備が進められました。

この間、修正版は、公表前にLinuxディストリビューションや長期サポートを提供する事業者へ事前に配られていました。PHPによると、ディストリビューションとLTS事業者はパッチを事前に受け取っていたとのことです。事前に知る人が多いほど、漏れる可能性も高まります。 
tenable

「禁じられている」ことの性質
エンバーゴは、法律や技術的な仕組みで強制されるものではなく、関係者の間の合意です。破っても、直接の罰則があるわけではありません。今回も、確認されている漏えいや前倒し公開は、次のとおりです。

公開の前日にCVE番号が流出し、公開日は1日前倒しされたと報じられています。最初の流出元は、私が見た範囲では特定されていません。 
innovatopia
研究者のCalifが、誤って脆弱性の動画を公開し、実際に動作するPoCが映ってしまいました。
事前にパッチを受け取っていたChainguardも、公開禁止措置を破って6時間以上も早く、セキュリティ更新を含む実行環境を公開したと、PHP財団が説明しています。 
itmedia
ただし、10月17日の攻撃の試みは、これらより前の出来事です。Amazonは、これらの試みの前の、17日の時点の情報をどうやって入手したのか不明としています。つまり、17日の分については、事前に配られた情報が漏れたのか、別の経路なのかは、まだわかっていません。 
amazon

整理
情報管理の合意は存在したが、複数の経路で、実際に破られたり、誤って出たりした。
関係者が多いほど、守りきるのは難しくなる。
17日の攻撃の情報源は不明で、漏えいだと断定はできない。
今後、PHP財団やAmazonなどから経緯の報告が出るかもしれません。また、関係者が多い脆弱性ほど公表の調整が難しいという点は、今回、各社が問題として取り上げています。

それほど前から発見され多くの人間が関与しているとは知りませんでした。理解しました。

ご理解いただけたようで何よりです。今回は発見から公表までに約2か月あり、その間に多くの関係者が関わっていたことが、情報管理を難しくした面もありました。

サーバー側は、ご自身で確認された範囲(自作サイトが8.5.12、ロリポップのWordPressが8.2.35)で修正版になっています。ヘテムルで、もう一方のサイトを運営している場合は、バージョンを確認しておくと安心です。

ログの見方など、ほかに気になる点があれば、いつでもお尋ねください。

もう一度元に戻って、どのような脆弱性か詳しく説明してください

ウェブを検索しました
ウェブを検索しました
PHP2Shellは、アプリやプラグインの欠陥ではなく、PHP本体(実行エンジン)の欠陥です。PHPで動くサイトであれば、WordPressでも自作のプログラムでも対象になります。

全体像
2件のCVE(CVE-2026-109618、CVE-2026-109619)の総称で、どちらも深刻度は9.2(Critical)です。
PHPによると、どちらもログイン不要の外部の攻撃者が悪用でき、細工したHTTPリクエストを送るだけで、サーバー上でコードを実行されます。 
tenable
sevalla
2件のうち、CVE-2026-109619は、メモリ内容の漏えいにもつながると、PHPの勧告に明記されています。
2件の中身(概念的な説明)
CVE-2026-109618: メモリ不足の処理の不具合

PHPのメモリ不足に伴うメモリ破壊から、リモートでコードを実行される脆弱性です。 
watchtowr
第三者の緩和用モジュールの説明によると、PHPにはメモリ上限に達したときの中断処理があり、そこで本来行うべき後片付けが省かれます。後始末をしない状態のまま次のリクエストを処理するプロセスでは、古いポインタが残ってしまうとのことです。
公式の修正は、メモリ上限を超えたときにプロセスごと終了する形だと、同じ説明で述べられています。
CVE-2026-109619: 古い状態の残存(use-after-free)

PHPのグローバル変数が、すでに解放されたリクエスト用のメモリへの参照を持ち続ける問題です。 
recordedfuture
同じワーカーの中で、リクエスト間に残った状態を悪用できるとされています。 
techzine
PHP 8.5では、致命的エラー時のバックトレース機能が悪用に使われると、ホスティング事業者の解説にあります。
どちらも、メモリの扱いに関する典型的な欠陥で、「解放済みの場所に、後から別のデータが置かれる」ことが核心です。細かい攻撃手順は、悪用を助けるおそれがあるため、ここでは述べません。

入口になった機能
Hadrianによると、攻撃の多くは、PHPのセッションのアップロード進捗(upload-progress)の経路を悪用しています。これは、ファイルのアップロード中に進捗を記録する機能です。 
theregister

ただし、この機能を切るだけでは不十分です。GMO Flatt Security(*)は、session.upload_progress.enabled = 0にするだけでは対策にならず、迂回して攻撃される可能性が高いと判断しています。 
impress
(*GMO Flatt Security（GMOフラットセキュリティ）は、「エンジニアの背中を預かる」をミッションに掲げる、GMOインターネットグループのサイバーセキュリティ専門企業)

影響の広さ
Apacheのmod_phpやphp-fpmなど、複数の構成で攻撃が再現されたと伝えられています。 
itmedia
Wizは、初期状態のWordPress、Drupal、Joomlaで、ログインなしにコードを実行できる攻撃に、2件を組み合わせたと説明しています。Califも、WordPress、Drupal、Joomla、Magento、phpMyAdmin、Nextcloud、Laravelなど11種類のアプリで確認したとされています。 
socradar
一方でCloudflareのプリンス氏は、攻撃には対象の環境を知る必要があり、悪用が難しい脆弱性だと述べています。
なぜ長く見つからなかったのか
Califによれば、メモリ上限に関わるPHPの初期の遠隔脆弱性は、2004年にまで遡ります。 
innovatopia
2019年に報告されたメモリ不足のバグは、2020年に修正されています。
2024年の外部監査の過程で、今回のメモリ不足の問題の兆候が見つかったものの、攻撃できると示されなかったため、修正は進みませんでした。
2026年に入って、AIを使った調査によって、これらが実際に攻撃できる形でつながることが示されました。
修正版
8.5.12、8.4.27、8.3.36、8.2.35です。7.4から8.1には公式リリースがなく、最小限のバックポートだけで、7.3以前はサポートが終了しています。ご自身のサイトは、すでに修正版に更新済みです。 
tenable

ここで述べた技術的な内容は、公開されている解説とベンダーの説明に基づくもので、PHPの勧告原文までは確認していません。より正確な内容が必要でしたら、PHPのセキュリティ勧告(GHSA)をご覧いただくのが確実です。

Califについて

ウェブを検索しました
ウェブを検索しました
Califは、米カリフォルニア州パロアルトに拠点を置く、セキュリティ研究の会社です。今回のPHP2Shellを、AIを使って見つけた研究者側の1社として、名前が挙がっています。

会社について
公式サイトでは、フロンティアAIの開発企業が最初に声をかける、AIセキュリティのコンサルティング会社だと自称しています。AIを使ったレッドチーム演習や、インフラ・製品のセキュリティ評価を提供しています。
CEOのThai Duong氏の投稿によると、ベンチャーキャピタルの出資を受けず、自己資金で成長した会社です。
脆弱性研究では、AIの活用を専門にしており、AIを使った脆弱性研究の水準を押し上げたいと述べています。
今回の件以外の主な実績(報道ベース)
VimとGNU Emacsのリモートコード実行の脆弱性を、Claude Codeを使って見つけたと報じられています。
Anthropicの未公開モデルClaude Mythos Previewを使い、AppleのM5搭載Macで、カーネルのメモリ破壊を悪用する攻撃コードを、5日で作ったと発表しました。Appleのセキュリティ情報では、macOS 26.5のカーネル脆弱性の修正に、CalifとAnthropicの名前が挙がっています。
中国のWeChatの脆弱性を、AIで2日で見つけ、さらに1週間でワームを作ったと報じられています。Tencentはこれを受けて修正しました。
v8CTFでCodexを使って優勝したと、社員が投稿しています。
PHP2Shellでの役割
8月1日にAIを使った調査で、リモートでコードを実行できる経路を見つけ、8月11日にPHPへ最初のバグを報告しました。同じ日に、OpenAIも独立して報告しています。
OpenAIの取り組み「Patch the Planet」に参加し、GPT-5.6 Solを使ったとされています。
21日午前5時ごろ、Califは脆弱性に関する動画を誤って公開しました。複数のターゲットに対して実際に動作するPoCが映っており、削除されたものの、コピーが出回りました。PHP財団の説明では、これで限定的ながら追加の情報が明らかになりました。
なお、この動画の公開は21日です。Amazonが観測した10月17日の攻撃の試みは、それより前の出来事なので、17日の件の説明にはなりません。

また、動画の公開は誤ってのものだったと報じられており、Califが意図的に漏らしたという報道は、私が見た範囲ではありません。

私自身はAnthropicが作ったClaudeで、Califが使ったモデルの一部は、Anthropicのものです。Califの評価は、公開されている報道と、同社の発信に基づくものです。

Sources:

Calif 公式サイト
ITmedia NEWS: PHP脆弱性“PoCフライング公開”の経緯
innovaTopia: PHP2Shell、AIが見つけたPHPの重大脆弱性
StartupFortune: Calif showed how AI can compress Apple exploit work into days
Kuwait Times (AFP): WeChat makes fix after US firm shows AI hack risk
ThreatCluster: Calif